The Financial Information eXchange (FIX) protocol is ubiquitous within the world of finance technology and has been in widespread use since its inception in 1992. FIX defines a standard for communicating financial transaction information between the various players in the financial industry: banks, brokers, hedge funds etc. Importantly, FIX is platform and technology independent.
So, what exactly is FIX and more importantly how do I use it?
At a high level the FIX protocol can be split into 2 areas, namely a specification for a messaging workflow and a message format:
Workflow: FIX defines exactly which messages are sent and received and in which order. For example, I submit an order request, you reply with an order received acknowledgement, then you send a partial order filled message and so on.
Message Formats: Each message exchanged is of a particular type. FIX specifies the exact message structure for all the various message types.
FIX defines various messaging workflows covering a wide range of financial transaction use cases. For example below is the workflow for submitting and executing a new order (courtesy of Integral):
Here we can see a New Order message being sent, followed by an Execution Report response (New), and finally a further Execution Report response (Partial Fill or Filled).
There are many of these workflows defined for scenarios such as Quote Request, Order Cancel, Position Reports etc.
FIX messages are grouped into two categories:
Admin messages: concerned with general admin functions such as creating the connection (logon/logoff), sending/receiving a heartbeat etc. No financial data is sent via these message type.
Application messages: these handle the actual transmission of the financial data/ transactions such as new orders, execution reports etc.
A FIX message is simply a sequence of field/value pairs separated by a | (SOH) character.
For example: 55=EUR/USD is interpreted as the instrument symbol (field 55) having the value EUR/USD
Here is an example of a complete single message:
Every message starts with a header which includes the version of FIX, in this case 4.3, followed by the length of the message (9=247 bytes) then the message type (35=D which is a new order).
Next is the main message body which contains session and/or application specific data.
And finally there is the message trailer which contains the message checksum (10=212 in the example above).
For a full reference of all the available fields for the various versions of FIX check out this website where you can search/order by field name or tag.
Implementing and handling all the various workflows, message types and fields is tedious therefore there are several libraries available called FIX Engines which greatly simplify implementation.
A FIX Engine implements the FIX session level protocol and handles various tasks such as logon, logout, sequence numbering, message resend requests etc.
I have used QuickFIX/n Engine recently for a client project and highly recommend it.
I hope this article has provided a useful overview of the FIX protocol.
Coderun Technologies has experience in integrating FIX with an automated trading system; please contact us to discuss your development/consultancy requirements.
- FIX Dictionary: https://www.onixs.biz/fix-dictionary/
- FIX Parser: https://fixparser.targetcompid.com/
- FIX Trading Community: https://www.fixtrading.org/
- QuickFIX: http://www.quickfixengine.org/