Came across this on CME's site: http://www.cmegroup.com/tools-information/lookups/advisories/electronic-trading/20121105.html#OPR "The life cycle of the FIX/FAST protocol, including streamlined FIX/FAST, is rapidly approaching its end as an industry standard in the United States. â The OPRA connected exchanges are eliminating FIX/FAST entirely by the end of this year. Given the increased availability of bandwidth as well as high speed connections such as co-location, compression has become less critical." Is the shift going to ITCH/OUCH binary protocols?
Can anyone else speak to the accuracy of CME's claim that FIX/FAST "is rapidly approaching its end as an industry standard"? I for one certainly hope it's not the case. Standardization and efficiently compressed feeds are liberating and yield cost savings to virtually everyone but the trading venues themselves, so it would hardly surprise me if venues used FUD ("fear, undertainty, and doubt") in an attempt to lock in customers with proprietary protocols and a required (and very expensive) colo. But then again, it could be it just never caught on for other reasons, even if only due to inertia. If not FIX/FAST, is there any other non-proprietary standard that people are gravitating towards?
It's true that standardization is good. But ITCH is kind of standard and breathtakingly easy to implement. Haven't used FAST myself, but it seems kind of more complicated to implement. So maybe you need more bandwidth, but it's cheaper and cheaper. Don't really see why FAST yields cost savings.
After reading various other articles from CME Group's site as well as fixprotocol.org, I think that if FIX/FAST are being replaced, it will be on the 'back end' of CME's infrastructure. Connection by institutions & retail to their data feeds are still offered via FIX; CME simply has a translator between old & new in there somewhere...at least this is my hunch of what's going on.
The assumption in my previous post is null...called & spoke to a CME rep today, and they are indeed phasing out FAST, and most of FIX...rep indicated that they are undecided on the new standard protocol for their servers.
Here is the main problem with FIX/FAST, it doesn't lend itself well to either a "fast" hardware implementation and parallelization as most of the processing is sequential. There are ways to speed up FIX/FAST parsing (by essentially guess-timating some lengths, and parallelizing that way), but it is done in a pretty "kludge" manner. I have done certainly plenty of that in my own implementation. For instance, let's take the DATE field in a standard FAST template, it is a 8 byte 64 bit unsigned integer, encoded in 7 bits (with 1 stop bit). Now if the previous messages "Date" field have all been encoded as say "2012122013050517", then it is likely the next field would have the same bytes, therefore you can parallelize the parsing. So it is "kludge", but works. But compare this to say something that uses the 8 byte (so no reduction using the stop-bit), and you can just do a Mask out the date field, say. This would be fewer instructions with a much cleaner hw or vector implementation.