About a-team Marketing Services
The leading knowledge platform for the financial technology industry
The leading knowledge platform for the financial technology industry

A-Team Insight Blogs

Q&A: Fred Malabre of FPL on High Performance Trading with FIX

Subscribe to our newsletter

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

Related content


Upcoming Webinar: Deploying market infrastructure managed services

Date: 25 May 2022 Time: 10:00am ET / 3:00pm London / 4:00pm CET Duration: 50 minutes Traditionally, trading organisations have procured and managed hardware themselves or through a third-party to support data services in a hosted environment – but as large firms look for efficiencies and smaller firms seek external help so they can focus...


A-Team Webinar: Opportunities of New Approaches to Electronic Trading

In today’s capital markets environment, front-office traders face a number of challenges, not least of which are high costs, shrinking margins, increased regulatory oversight, and a multiplicity of siloed, often-legacy applications on the trading desk that can hamper workflows. Within this environment, firms need to be able to rapidly adapt: to the evolving needs of...


A-Team Innovation Briefing: Innovation in Cloud

This Innovation Briefing will explore approaches to data infrastructure transformation, technologies required and how to make sure processes are optimised to support real time data management. Hear from leading practitioners and innovative technology solution providers who will share insight into how to set up and leverage your data infrastructure to provide user access to consistent data and analytics, and companies the ability to monetise their data.


Entity Data Management Handbook

Following on from the success of our Regulatory Data Handbook, A-Team Group is pleased to introduce its new Entity Data Management Handbook which is available for free download. This Handbook is the ultimate guide to all things entity data: Why Entity Data is important A full review of Legal Entity Identifiers (LEIs) Where they came...