Global
Evolution of the
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 manipulating the FIX messages.
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
16
GLOBAL_pc.indd 12
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.
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
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
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 edward@fixglobal.com
8/28/2008 1:36:20 PM