Introduction
The use of FIX protocol has become the defacto standard for order
transmission within the financial services industry. FIX uses a simple
tag=value format that makes it relatively easy to read but imposes a
significant overhead in terms of message bandwidth. For order
transmission this has not been a significant problem but for wholesale
data dissemination the overhead results in excessive latency or
communication costs. As a result straight FIX protocol has found very
limited use in transmitting data.
The solution to this this is FAST (
Fix
Adapted
for
STreaming).
FAST protocol has been designed specifically for efficient high volume
data dissemination and has the support of major industry players
including ARCA, CME, ISE, LSE and Microsoft.
The FAST protocol project is now reaching maturity and reference source
code in C and C# format has been released under a free W3C
license.
(FAST
software)
Data Compression
The core of FAST comprises a compression algorithm. The algorithm is
designed specifically to work with the tag=value format of standard FIX
messages and provide high compression with low processing overhead and
low latency. The result is a 75-80% reduction in message size
with an additional processing latency of typically 1-2us per message.
However, the reduction in message bandwidth results in a significant
decrease in transmission latency so that overall, FAST protocol lives
up to its name and is actually fast. Hence, FAST protocol promises
to offer significant reductions in latency and/or reductions
in communication infrastructure costs.
Exponential Data Increases
FAST comes at a very important time when many financial service
providers are struggling with exponentially growing data volumes. This
has resulted from a huge rise in the use of algorithmic trading by the
sell-side but now increasingly by buy-side traders as well. This has
left many exchanges and data vendors struggling to keep the
infrastructure operating in the face of the growing electronic
onslaught. This problem was recently highlighted by
the failure of the Tokyo Stock Exchange due to a surge of
electronic orders.
Data volumes look set to continue rising for the foreseeable future.
The
NYSE, the CBOT grains complex, NYBOT and NYMEX all look set to
transition from pit to electronic trading with an inevitable increase
in market data output. Against this background, FAST looks like a very
attractive solution to data dissemination
without increasing communication infrastructure costs above
present levels.
FAST Protocol
The diagram below shows the fast protocol stack.
Session control is provided using session control protocol (SCP).
This allows session initialisation, termination and
alerts.
The first stage in message size reduction comes from the use of
templates.
Transmission of tags adds a significant overhead in standard FIX
messages so FAST uses implicit tagging. This is achieved with a
template that describes the tags and tag sequence for a given message.
Consequently it is no longer necessary to transmit the tags and message
size is
reduced by 30-50% compared to a standard FIX message.The template uses
standard XML format and can be sent out-of-band or hard coded
into
the receiver. The template can also be used to define information about
the type of each value and its behaviour from message to message.
Multiple templates are supported and the appropriate template to use
can be defined in a
byte sent at the start of the message.
The balance of the compression is achieved in two stages each of which
reduces the message size by about 30%. Field encoding makes the
protocol stateful between messages and uses the prior state to provide
compression. Transfer encoding provides compression by
efficiently
mapping the field data into binary format for transmission.
Field Encoding
Field encoding provides compression by making use of the last message
state. This provides the advantage that values that don't
change
or simply increment do not need to be sent in each message. The
protocol defines a set of behaviours that can be applied to each field.
- Constant
- value is fixed.
- Derived
- value can be derived by calculation.
- Copy
- if value is not sent copy last message value.
- Increment
- if value is not sent increment last value.
- Delta
- if value is sent change the last value by delta.
The protocol defines a set of types for each field value including
signed or unsigned integers, scaled numbers or strings.
Transfer Encoding
Transfer encoding efficiently codes the field values into a binary
format using stop bits. The actual message is composed of a sequence of
presence maps (PMAPS) which are used to indicate the presence or
absence of a field value in the message and also the actual field
values. The number of fields depends on the PMAP content.
| PMAP |
field |
field |
PMAP |
field |
PMAP |
PMAP |
The PMAPs and fields are all encoded into binary format using stop bits
so that each fits within a space of n*7 bits. The stop bit is the first
bit of each byte and if set to 1 indicates the end of the field.
Eliminating data integration costs
FIX has been very effective in reducing integration costs to
supporting brokers and one of the promises of FAST is that it might do
the same the data. Currently, data re-vendors all support proprietary
formats and connecting an automated trading system (ATS) can
be
time consuming and result in significant software development costs.
With FAST comes the possibility of the universal plug-and-trade ATS
platform. A hedge fund or bank might simply buy a platform, implement
its proprietary trading rules and plug in whichever data vendor and
brokers it chooses.
In practice, there are still some significant obstacles to achieving
pluggable data feeds. Firstly, the template and template handling still
leave significant scope for proprietary implementations. This provides
a lot of flexibility but means that simply plugging in another data
feed may not be possible. Secondly, symbol naming conventions vary
widely from vendor to vendor. The answer to the first is to add more
standardisation to the FAST specification to define preferred symbol
template implementations. The symbol naming problem is partly addressed
with ISIN codes but introducing some standardised symbol conversion
functionality into the FAST specification would also help. Whether any
of this will happen in future releases remains to be seen.
FIX over FAST
Whilst the FAST protocol specification was originally intended just for
data transmission it also has potential use in order routing
applications. Order traffic is also rising and FAST offers the
important benefit of being able to reduce order routing latency.
Since, FAST is a compression algorithm for FIX messages it can be
inserted at the lowest level between two FIX engines. The session
control between the two engines is implemented through FAST SCP.
Conclusion
The development of FAST protocol has the potential to reduce latency,
cost of connectivity and integration costs. The early success of trials
and the backing the standard has from major industry players means that
it is likely to see wide adoption and will hopefully bring some of the
benefits that FIX has bought to order routing to data.
However,
further development of the protocol will be required to simplify and
standardise data feed integration. FAST is also likely to see adoption
as FIX over FAST to reduce latency in order routing.
