FIX Protocol 101

What is FIX protocol?

from www.fixprotocol.org >>
" The Financial Information eXchange (FIX) Protocol is a messaging standard developed specifically for the real-time electronic exchange of securities transactions. FIX is a public-domain specification owned and maintained by FIX Protocol, Ltd.

The FIX Protocol specification is maintained by the FIX Technical Committee, which receives its direction from the international Steering Committees, the Global Steering Committee, and the various Working Groups comprised of industry participants such as fund managers, brokers, exchanges, and vendors. "

That explanation probably may not mean a lot to a novice programmer who has been thrust upon the job of developing a trade application to communicate with FIX. I will try to make it a little more understandable from the perspective of that audience or people in a similar situation.

FIX is a simple ASCII text based messaging protocol that is used to communicate over your regular TCP/IP socket connection. Here are basic facts about FIX message/FIX engines/FIX based trading systems.

FIX Message
A FIX message is a simple ASCII text containing information in following format:

tag=valueDELIMITERtag2=valueDELIMITERtag3=valueDELIMITER...

FIX protocol mandates that on a FIX message you must use:

• "=" as the delimiter between the tag and the value.
• SOH chacrater as the delimiter between each tag=value pair. No other character can be used instead of SOH. SOH is a non-printing control character, which shows up on Linux/Unix/Solaris platforms as "^A"
  

This means there must be some set of rules defined somewhere so as to allow validation of these messages and tags. Such a set of rule is known as a data dictionary and the application that uses this data dictionary to facilitate validation and parsing of the FIX messages, is known as a FIX Engine. 

FIX has evolved over past few years and every iteration of this evolution has resulted in a FIX version, current version being FIX 5.0.

Now what does it really mean when you say you are following FIX m.n version.
It means that you are following the FIX specification for that FIX m.n version as laid out by the technical committee of fixprotocol.org. So there you have it, these FIX specs are then translated into your FIX Engine/App specific data dictionary, which can then be used to validate your FIX messages/tags.
Its not necessary that everyone has to follow the latest version of FIX, the most popular versions in the industry still are FIX.4.2 and FIX.4.4. You can choose any specific or multiple versions to follow based on the availability of the tags in that version's specs, that suit your requirements/needs.

So basically your data dictionary will cater to a specific version of FIX.


A FIX message (across all versions so far) consists of 3 parts:

1. Header --> This section consists of a series of tags that need to be a part of ALL the FIX messages in order to allow FIX Engines ability to parse that message correctly.
2. Body --> This is where every different message type can have its own set of tags.
3. Trailer --> This is again the mandatory set of tags required for all the messages. It usually contains the last tag for any FIX message "Checksum" (tag 10) which contains just that, a checksum of the contents of the ASCII FIX message minus the "CheckSum" tag.

That's the basic information about a FIX message. Details later. 



FIX Architecture
It involves a FIX Host/Server and a FIX listener or Client


A FIX application is usually known as a FIX engine (coz there is a rule based validation for the messages and tags etc). The primary job of a FIX engine is to receive and send valid FIX messages from and to a FIX server or a client, depending on where the FIX engine is located. This receiving and sending usually involves couple of things:

1. Validating the FIX message composition (whether valid tags have been sent for the given message type or not).
2. Validating the FIX tags (whether valid values have been sent for a given tag, based on datatype or allowed values etc).
   
3. Maintaining FIX session, also known as session management.
1. Monitoring session message sequences
2. Heartbeats 
3. Session timeouts
4. Out of sequence messages.

FIX Engines

There are lots of FIX engines (paid products/services) in the market these days and I'll leave it to reader's discretion to find out more about the same.
Many small firms decide to develop in-house FIX engines. Thats an excellent low cost option given you have an expert FIX developer handy, then too it takes quite some time to get everything right. Another alternative to speed things up is to download QuickFIX from QuickFIX engine or from Quickfixj(java implementation).
QuickFIX is an excellent bare bones open source FIX engine which gives you a pretty good customizable FIX engine that does the basic FIX engine stuff right out of the box. Usually I have seen people requiring some or the other customization to the distribution so as to "adapt" the software to their specific needs. It provides a good starting point for your in-house development efforts.

Ending this post here. I'll try to cover topics like data dictionary, message types etc later. Let me know if anyone has a specific request and I'll try to incorporate that as well ...


Comments welcome ...