FIX SBE, Proprietary Exchange Protocols, and HFT Trade-Offs
Summary
The document discusses whether FIX Simple Binary Encoding can reduce the development effort or bandwidth costs of high-frequency trading connections compared with proprietary exchange protocols. One response stresses that firms generally must use the protocol chosen by each exchange. It distinguishes SBE use for market data from order entry, citing CME’s planned SBE market-data feed as an example rather than evidence of SBE order routing.
Another response notes that nested repeating groups can make FIX parsing costly, while FIX’s verbosity can increase bandwidth use. It describes FAST as a compression approach used mainly for exchange market data, and identifies intuitive APIs, low latency, and low garbage production in Java as engine design goals. These comments offer practical considerations, not a measured comparison: the document supplies no benchmark figures or comprehensive engine list, and one response includes a vendor-related disclosure.
Key ideas
- Exchange connectivity generally requires using the protocol selected by the exchange.
- The discussion distinguishes SBE market-data use from order-entry protocols.
- Nested FIX repeating groups may add parsing work, and verbose messages may consume more bandwidth.
- FAST is described as a compressed FIX format used mainly for market data.
- The responses provide design considerations but no quantitative protocol benchmarks.
Tags
Full text
# HFT enhancements for FIX (Simple Binary Encoding) vs proprietary protocols performance and cost # HFT enhancements for FIX (Simple Binary Encoding) vs proprietary protocols performance and cost I would like to know from those that have used FIX (with Simple Binary Encoding) for HFT compares with the current (proprietary) protocols in use that often vary per counterparty. Interested in bandwidth utilization and development time differences. For example, do the various FIX engines (is there a list?) that support FIX SBE allow a software team to get to market quicker with their models than having to learn each proprietary trade protocol? ## Answer by chrisaycock (score 2) https://quant.stackexchange.com/a/9875 This is a really confused question and the OP clearly doesn't work in this industry. Any connection to an exchange requires using the format the exchange has chosen. I.e., you don't get a choice. That said, I don't know of a single exchange that allows order entry via SBE. CME Group will use SBE for their new market-data feed (replacing FAST compression), but that's it. ## Answer by rdalmeida (score 1) https://quant.stackexchange.com/a/14944 FIX has some known deficiencies. Repeating groups is one of them. It can be costly in terms of latency to parse repeating groups inside repeating groups, requiring recursive calls. I prefer protocols that send a first message signaling that N messages will follow with the group info. FIX is also too verbose consuming too much bandwidth. For that they have come up with FAST which compresses FIX by a great amount but it is mainly used by the exchanges for market data, not order routing. When we developed our FIX and FAST engine (CoralFIX), we focused on three things: - It must have a very intuitive and easy-to-use API for fast turnaround when coding the connections to the exchanges. - It must be low latency, designed from the ground up for speed. - If it is a Java one it must leave zero garbage behind otherwise the GC will add unacceptable latencies and variance. Disclaimer: I am one of the developers of CoralFIX.
Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.