As some exchanges have adopted proprietary binary protocols for HFT and other latency sensitive trading, the FIX Protocol organisation has been hard at work bringing FIX messaging into the world of high performance trading. IntelligentTradingTechnology.com found out what’s been happening from Fred Malabre, co-chair of the FPL High Performance Working Group (and senior director at CME Group).
Q: Why is there a need to adapt FIX for high speed trading?
A: FIX is supporting multiple encodings. The focus was on the tag=value encoding for lower latency systems and the XML encoding for less latency sensitive systems. In addition, in 2006, FPL introduced the FAST encoding designed for market data streaming with lower bandwidth requirements.
These last few years the industry evolved with faster processing hardware and better quality and cheaper network links in addition to the expansion of co-location access to major exchanges, which put strains on the protocol itself.
Exchanges replied with providing a proprietary binary interface in addition to the regular FIX tag=value ASCII based encoding to reduce bandwidth utilisation and processing time.
FIX didn’t have an encoding to address the market needs covered by proprietary binary feeds. FIX needed to evolve to provide a solution to industry needs. FPL launched the High Performance Working Group to adapt FIX for high speed trading.
Q: What is the FPL High Performance Working Group, and what is it doing? Is it focusing on trading interfaces or on market data dissemination?
A: FPL created the High Performance Working Group in 2012 with the goal to adapt FIX for high performance systems.
A few different aspects of FIX are being looked at:
· The first aspect is related to the encoding of messages. The goal is to improve on the baseline tag=value ASCII encoding. A Few encodings were looked at, the first one being the Simple Binary Encoding which provides a raw binary encoding of data for very low latency encoding/decoding, it is created and maintained within FPL. Two other encodings, the Google Protocol Buffer and ASN are also used in the industry but not maintained by FPL and thus have their own life cycle independent from FIX. The work was to define best practices for using FIX over these encodings in order to achieve systems interoperability.
· The second aspect is an optimisation of application messages. The goal is to improve on the data content reducing the verbosity and increasing batching of market actions with fewer messages. These proposals are then going in the regular FPL process for application layer updates.
· The third aspect is an optimisation of the session layer. The session layer in FIX is still based on unreliable transports with heavy recovery methods and various checks on data content (such as checksum). We are looking at a thin session layer fit for purpose for current market needs.
All these aspects of optimisation can be used independently although most of the value resides in combining the usage at all layers. The work is mostly focused on trading interfaces but nothing prevents using some of these optimisations for market data as well.
Q: What is meant by ‘Simple Binary Encoding’? Can you give an example?
A: Simple Binary Encoding is simply a way to send raw binary data content on the wire. It encourages the usage of constant size data fields which allows consumers to extract only the content needed without having to read each single piece of data. Each data type defined in FIX has a default binary equivalent data type but binary data types can be overwritten to match specific business needs if needed.
The wire content contains only data (the “value” content of tag=value). It is supplemented with a message layout for each binary message. This message layout can be customised for different business needs using the SBE template file which is XML file standardised by FPL describing the message layout. There can be multiple binary message layouts for a single FIX message which allow specialisation of content for overloaded FIX messages such as the Execution Report (35=8). Constant values can be predefined in the message layout so the compatibility with existing FIX engine can be kept while minimising the data content on the wire.
For example, a message can be created to report only execution time, price and quantity on the wire and predefined set of values in the layout for destination and contract identification.
The layout and content could be something like:
Field: destination, constant value “trader A”
Field: contract ID, constant value “15284”
Field: execution time, unix epoch, nanosecond precision, uint64
Field: execution quantity, unit16
Field: execution price, exponent constant value “-7”, mantissa uint32
On the wire only the content for execution time on 64 bits, execution quantity on 16 bits and execution price mantissa on 32 bits are present. We end up with 14 bytes to represent this message. This message could then be converted to be processed by an existing FIX engine assuming the content is valid in an expended form (which is not the case in this simple example).
A proper usage of Simple Binary Encoding properties allows backward compatibility with existing FIX engines for low operational cost and wide functionality support using FIX semantics which gives it an edge over proprietary solutions. In addition processing can be optimised with code generation (mapped to a structure in memory).
Q: How does SBE relate to other encoding models, such as Google Protocol Buffer and ASN?
A: SBE (Simple Binary Encoding) is maintained within FPL. It means that it can evolve in parallel with FIX standards.
GPB and ASN.1 are maintained outside of FPL standards and thus have their own life cycle and evolution not related to FIX.
In addition, tradeoffs made between these binary encodings are different. SBE is mostly focusing on direct access and might not be as efficient for more complex message structures with inner repeating groups. It is also probably consuming more bandwidth than GBP for instance if multiple optional fields are used. ASN.1 itself supports multiple encodings with different tradeoffs and can be optimised differently depending on business needs.
There are a few options being looked at to extend SBE to answer specific needs in the financial industry. One of them is potential optimisations for more complex message structures which are necessary in some trade reporting use cases. Specific use cases and testing will give us metrics to see if performance gains warrant an extension of SBE. Another one is to look at self-describing messages pre-pending wire messages with an encoded message layout and break the dependency on the XML message template. This will answer some business needs related to long term storage of data where message size is not such a concern while maintaining the high performance aspect with limiting the processing to the concatenation of two pieces of data.
Q: And does SBE have any relation to protocols such as ITCH and OUCH?
A: SBE doesn’t have any relation to ITCH and OUCH which are proprietary protocols optimised specifically for Nasdaq and the cash market in general. However, the encoded format on the wire ends up being very similar.
It would actually be completely possible to use the standard SBE XML message template to create ITCH and OUCH messages.
This is where the FIX semantic comes into play and allows support for many asset classes and more complex functionality while maintaining optimised content on the wire.
Q: What is the plan for implementation/live use of SBE?
A: So far SBE reached the public with the release candidate 1. It was confined to the FPL High Performance Working Group since the effort started a little bit less than a year ago.
We expect that public specifications will allow people to implement some solutions and fine tune the specifications.
The next stage will be to go into a release candidate 2 and when the community is comfortable with SBE, it will be integrated in the standard FIX specifications.
Meanwhile, CME Group announced that Globex market data interfaces will use SBE as a replacement of their current FAST encoded implementation by the beginning of next year. We expect that this will validate the SBE specifications with an early adopter of SBE. SBE responds to CME Group business needs with low latency and direct access.
Q: Is this work meant to supersede FAST, or be an alternative to it?
A: The work on SBE is an alternative to FAST with different tradeoffs. FAST is designed for minimal bandwidth utilisation. SBE is designed for low latency and direct access. It’s a complementary approach and I expect that both encodings will evolve in parallel in the future based on market needs. Both low latency and low bandwidth needs are here to stay.
Financial industry needs have been evolving with technical advancements in network access and hardware performance and SBE is an answer to address constraints within existing FIX encodings.
Subscribe to our newsletter
