FIX Protocol : Architecture and Message Structure

Table of contents

Reading Time: 3 minutes

In my last blog, we went through the basic aspect of FIX protocol PROS and Cons. In this blog, we will understand the anatomy of FIX protocol which will cover the basic architecture and building blocks of FIX.

FIX Protocol Architecture

FIX consists of 2 main layers :

Session layer : This layer aims to provide high performance. It deals with initialisation, maintenance and termination of connections. There is usually a bi-directional stream of ordered message transfer between two parties, thus, the handshaking between those parties, data integrity, message delivery and sequencing is handled by the Session layer.
Application Layer : This deals with business specific functions such as order creation, cancellation, replacement etc. The trades between multiple parties is handled via this layer.It thus, subscribes to market data, processes and parses the execution reports etc.

Building blocks of FIX API

Message Structure

All FIX messages are text only (ASCII text) and follow certain definitions.
Field definition – The contents of a FIX message are put together using fields and their associated value. Each field has a certain definition. The definition includes :
a) Name
b) Number
c) Data Type
d) Value

For example : For the begin string field, following are the values of the fields mentioned above:

Name : BeginString
Number : 8
Data Type : String
Value : FIX.4.4

Thus, “8=FIX.4.4” means that this is the first component of a FIX message in the standard header, indicating the recipient that the protocol version being used here is FIX 4.4.

Each FIX message is composed of a sequence of such pairs, tag being the field and value being the value associated with that field in the pair. Each tag-value pair is delimited by an ASCII control character i.e. 0X01. Each tag has its own meaning. For example :

8=FIX.4.4 | 9=176 | 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 |

Tags used in a FIX message must not appear more than once (except in case of Repeating Groups).

FIX Message components :

Any FIX message is composed of 3 main components. The order of these components must be maintained.

1. Standard header : The tags which are included in this layer are :

8 – BeginString
9 – BodyLength
35 – MsgType
49 – SenderCompID
56 – TargetCompID
34 – MsgSeqNum
52 – SendingTime

2. Message Body : It contains sequence of pair depending upon the the of message being sent by the application.

3. Standard Trailer : It includes one tag i.e. 10 – checksum value. The checksum of a FIX message is calculated by summing every byte of the message up to but not including the checksum field itself. This checksum is then transformed into a modulo 256 number for transmission and comparison.

In order to understand what these components represent, let us take an example of FIX message :

8=FIX.4.4|9=110|35=D|34=3|49=CLIENT|52=20190424-11:19:16.885|56=SERVER|11=ID|21=3|40=1|54=1|55=EUR/USD|60=20190424-11:19:16.885|10=054|

Here, the MsgType i.e. Tag 35 has value D which means this message is of Order Single. Similarly, each tag-value pair represents some meaning. As depicted in the above figure, you can have an idea about each tag and its value’s description used in our FIX message.

In my future blog, we will drill more into the FIX API.