Evolution Of The Fix Engine

Global

Evolution of the

FIX Engine By John Cameron, CTO, Orc Software

The saying goes that a camel is a horse designed by a committee. Well, FIX has been designed by a long series of committees and it does have its shortcomings, but the great strength of FIX has always been its flexibility. At the simplest level, a FIX engine is software that implements the FIX standard. Other software, typically some kind of trading system, uses this engine to send and receive FIX messages. However the FIX engine of today bears little resemblance to its early predecessors and the evolution continues.

First Generation - In the Beginning The publication of the FIX standard in 1992 was followed by a number of products which can be categorized as first generation FIX engines. They were straightforward implementations of the FIX Protocol with their roots in traditional financial/accounting systems. They were typically built around a relational data base or on top of an application server. The most successful were Coppelia from Javelin, Financial Fusion from Sybase and Trinitech. As FIX became more popular, the performance of these first generation solutions started to become an issue. By 1997 the major users of FIX were starting to see that their FIX engines were limiting their trading capacity.

Second Generation – Step Change in Performance So was born the second generation of FIX engine. These had their roots in the world of high speed, real time transaction processing systems – such as the automated trading systems that were becoming more common in exchanges around the world. Second generation engines ran considerably faster than

earlier versions (approx 100 times), with CameronFIX arguably being the first to market (released in 1997) and subsequently achieving rapid commercial success. Another significant second generation FIX engine which appeared in 2002 was the open source implementation, QuickFIX. These FIX engines had raised the bar on performance but were still little more than straightforward implementations of the protocol. With the availability of good, standard, reasonably fast solutions for communicating using FIX, the focus shifted towards efficient processing and monitoring of the FIX message flow.

Third Generation – Message Processing and Management A third generation FIX engine naturally implements the FIX protocol but it also serves as a platform for the processing of FIX messages. The FIX engine itself can be the most efficient and appropriate place to process those messages. Customers can configure in their own business logic for manipulating the FIX messages. A special kind of message processing is ‘smart message routing’ – a system which decides where each FIX message should be forwarded. Often a third generation FIX engine will be used purely for routing from one FIX session to another, based on flexible business logic. Third generation engines typically provide facilities for monitoring and measuring the FIX message flow. They also

16

GLOBAL_pc.indd 12

8/28/2008 1:36:20 PM

usually provide extensive support for integrating the engine into an existing IT infrastructure. They started to appear around 2001. The first ‘third generation’ engines at this time included the CameronFIX Universal Server, Transact Tools’ TCM platform and Javelin’s Appia engine. Third generation engines have taken us through to today. However, increased automation on both the exchange side and the investor side has led to a boom in trading volumes which has placed unprecedented demands on performance. This provides a challenge not only to the FIX engine software itself but also to the infrastructure surrounding it, in particular network bandwidth.

“...increased automation on both the exchange side and the investor side has led to a boom in trading volumes...” Meeting that challenge will require fundamental architectural changes – as occurred in the move to second generation FIX engines. It will also require some change in FIX itself.

Fourth Generation – A New Format for Performance This progression is all about another step change in performance. Fourth generation FIX engines will be characterized by:

•

•

•

•

•

Compressed binary data formats (FAST), replacing the traditional text based FIX formats. Deep integration of binary data types into the core FIX engine code, so that it natively handles these more efficient formats; Predictable, consistent low latency performance achieved by strictly controlling factors which can introduce performance ‘spikes’ such as object creation and garbage collection; Smart use of low level networking to maximize performance on available network resources; Detection of counterparty capabilities in order to maximize performance between two FIX engine implementations.

FAST is a core enabling technology for fourth generation FIX engines. While it grew out of the world of market data, FAST is applicable to any kind of FIX message and offers flexibility in the way that FIX data is formatted for transmission. FAST finally gives us flexibility over the syntax, opening up the potential for increased performance, while retaining the all important FIX semantics. “Performance is key for the acceptance of a standard such as FIX in exchange environments and FAST has the potential to become the enabler for that,” says Hanno Klein at Deutsche Börse Systems, Co-Chair FPL Global Exchanges and Markets Committee. “Highly repetitive data coming out of or being sent to an exchange can benefitmost from FAST. Adherence to FIX semantics is more important than ever to achieve true standardization across marketplaces. Every mapping of messages has a negative impact on performance and should be avoided as much as possible.

GLOBAL_pc.indd 13

FIX over FAST messages no longer looks like FIX text messages but continue to carry the FIX semantics and can easily be mapped to the FIX syntax if the need arises.” Previously there was only one way to transmit a FIX message and this inflexibility was the reason that FIX was never widely used for transmitting market data, despite having the capability to do so. FAST was initially a response to this issue. Fourth generation engines will use the new FAST flexibility to increase performance for all kinds of FIX messages. “FIX has matured to the point where it can be viewed as a high performance, low-latency solution for order routing and market data alike,” says Matt Simpson, Associate Director of Electronic Trading Systems Architecture at CME, and Co-Chair of the FPL Global Technical Committee. “It no longer is just a means of providing out-of-the-box connectivity, instead providing the best of both worlds in terms of standardization and performance. Trading architectures properly tuned to FIX and leveraging the latest advancements, FAST among them, can compete on a level playing field with any low-latency proprietary protocol available today. This is especially true for exchanges and other central market places which are dealing with the demand of increasingly lower latency in the face of massive transaction loads.” As well as providing for very efficient data compression, FAST also introduces a flexible set of binary data types. In traditional FIX everything is text – including values such as quantities, prices and other numeric data. Fourth generation FIX engines, however, will natively use FAST data types so that FIX data can be stored and transmitted and processed in the same efficient format – eliminating the need for continual conversion to and from text. “FPL is currently developing recommendations and best practices for FIX over FAST that will support a new generation of high performance FAST-based FIX engines,” adds Rolf Andersson, Co-Chair of the FPL Market Data Optimization Working Group, and CEO of Pantor Engineering.

The Future of FIX Over the years FIX has shown an extraordinary ability to evolve and adapt to the demands of its users, which has been key to its success. Its popularity has driven the evolution of FIX engine software. In turn, better FIX engines help to make the FIX Protocol more attractive to the market place. The result is a symbiotic relationship between the standard, and implementations of that standard, which bodes well for both. FAST is an important milestone in the evolution of FIX because it directly addresses one key inflexibility in FIX. It frees up the standard to evolve to meet the demands of the future and will also play a key role in the future evolution of the FIX engine. Any thoughts on this or other articles? Please send any comments, refering to this article as Vol 2 Issue 7 GL6, direct to Edward at [email protected]

8/28/2008 1:36:20 PM