Financial Information eXchange protocol is a message layout used to exchange financial information.
It was designed for real-time exchange of information related to securities transactions and markets.
When it was initially developed, it was intended to automate a communication that was done via phone. The first ever communication via FIX was between Fidelity Investments and Salomon Brothers. One of the reasons for using machine-readable communication was to reduce the amount of errors caused by human factors.
Nowadays, it is used intensively by all the parties in the financial world, from brokerage companies to exchanges and institutional sales.
There are two main types of FIX messages:
admin messages - used to transfer basic administrative information such as logins, heartbeats and requests to send missing messages.
The FIX protocol is a list of predefined messages with a set of fields.
In order to understand a FIX message, a receiving party must have a dictionary to decode it.
Each FIX message is composed of a list of fields delimited by character SOH (ASCII 01). Each field is composed of a tag (an unsigned integer) and a value.
A FIX message contains three main parts:
Header: contains information on the version of the FIX protocol, the length and the type of the message. In the latest versions, it also provides information about the sender and the receiver along with other optional information.
Body contains the actual message information, presented as a set of fields and their values. The number of fields varies. Each message type has mandatory and optional fields - this information is a part of the dictionary.
Let's look at the following example. In this example, " | " is used instead of SOH, for better readability.
8=FIX.4.2 | 9=178 | 35=8 | 49=PHLX | 56=PERS | 52=20071123-05:30:00.000 | 11=ATOMNOCCC9990900 | 20=3 | 150=E | 39=E | 55=MSFT | 167=CS | 54=1 | 38=15 | 40=2 | 44=15 | 58=PHLX EQUITY TESTING | 59=0 | 47=C | 32=0 | 31=0 | 151=15 | 14=0 | 6=0 | 10=128 |
Here, 8=FIX.4.2 is the first field of both the message and the header. It is composed of the tag 8, which corresponds to BeginString and the value - FIX.4.2, which is the FIX version of this message.
There are several online tools that help to parse a FIX message. I use Fix Parser here to analyze this message:
The header is composed of the first 5 fields. This is a message sent by a sender with compID PHLX to a receiver with compID PERS.
This message is an execution report to confirm changes to an existing order between the sender and the receiver. In this case, PENDING REPLACE is the status of the order.
The message also contains some other information, and it is clearly easier to read the parsed version than the FIX message itself.
Such a message can be translated with a data dictionary. This dictionary can be an XML file that describes the format of the messages.
Here is an extract from a dictionary used by QuickFix (open source implementation of the FIX Engine):
<fix type=”FIX” major=”4” minor=”2” servicepack=”0”>
<header>
<field name=”BeginString” required=”Y”/>
<field name=”BodyLength” required=”Y”/>
<field name=”MsgType” required=”Y”/>
<field name=”SenderCompID” required=”Y”/>
<field name=”TargetCompID” required=”Y”/>
</header>
….
<message name=”ExecutionReport” msgtype=”8” msgcat=”app”>
<field name=”OrderID” required=”Y”/>
<field name=”SecondaryOrderID” required=”N”/>
<field name=”ExecID” required=”Y”/>
<field name=”ExecTransType” required=”Y”/>
……
<field name=”ExecRefID” required=”N”/>
<field name=”ExecType” required=”Y”/>
<field name=”OrdStatus” required=”Y”/>
</message>
<trailer>
<field name=”SignatureLength” required=”N”/>
<field name=”Signature” required=”N”/>
<field name=”CheckSum” required=”Y”/>
</trailer>
<fields>
<field number=”1” name=”Account” type=”STRING”/>
<field number=”17” name=”ExecID” type=”STRING”/>
<field number=”20” name=”ExecTransType” type=”CHAR”>
<value enum=”0” description=”NEW”/>
<value enum=”1” description=”CANCEL”/>
<value enum=”2” description=”CORRECT”/>
<value enum=”3” description=”STATUS”/>
</field>
……
</fields>
</fix>This dictionary describes the content of each FIX 4.2 message. The header applies to all messages, as well as the trailer. The message description contains all the fields that could be used for that message type. At the end of the dictionary, there is a list of fields, with their description and possible values for the enum types.
Using a dictionary lets any entity add a custom set of fields to meet their own requirements.
The first steps in getting where we are today with the standardization of communication in the financial world through the FIX protocol were made 25 years ago, when communication between Fidelity Investments and Salomon Brothers was moved to this machine-readable data.
Every new version of the protocol presented new types of messages and fields, to suit the needs of a wider range of users.
Version 5.0 presented a big change. It introduced a Transport independence framework that separates the FIX Session Protocol from the Application Protocol.
Using this framework, application messages can be sent over any suitable transport technology, and the FIX Session Protocol is one of them.
Initially named FIX Protocol Ltd, Fix Trading Community was created in 1998 to help standardize the FIX Protocol. Besides that, it aimed to help develop the protocol to fulfil a wider list of needs and promote this protocol as a unified language for the financial markets.
Now FIX Trading Community is an independent and neutral organization that deals with promotion and continuous development of the FIX family of standards, which includes the FIX Protocol. It explores other non-proprietary free and open standards, and this is why it changed its name to Trading Community.
It is a world-wide organization with members from six continents, including buy and sell side firms, trading venues, regulators, vendors and other industry associations. It is a community, bringing together people from the financial world, a world characterized by competition.
by Dan Dragu
by Mihai Varga , Raul Deac
