Anatomy of FIX Protocol (Intro)

111bfa0a-3909-4c42-ac3e-68a6892cbf28.PNG (image/PNG)

Anatomy of FIX protocol

As you already learned, the advantage of FIX protocol is that is is agnostic to the transport layer. This makes this protocol unique, since it will contain its own layers. FIX contains 2 layers, being the first one the session layer and the second one the application layer.Since Secure Trading Hub is just a routing service, the most important layer for us is the session layer. The application layer is also important, but it means we need to be either the buy or the sell side to correct troubleshoot what is contained on it.Session layer is responsible for the connectivity of sessions, which means correctly handshaking  and maintaining data integrity. Later on this course, you will learn in depth how each session behaves and uses information to perform these functions.

Rubrica: : The layers of FIX Protocol

Building block of FIX

FIX protocol is a clear text protocol composed of field-value message specification. When establishing communication with a end point, there will be a message specification documents that outlines the fields and their properties. Most people use the protocol on their standard version that can be found at the http://www.fixtradingcommunity.org site. If a customer is using a customised version, it is usually called a a Rule Of Engagement document (ROE) and will contain information of the field name, number, if it is required or not and its data type.Field DefinitionAs establish by the standards, FIX protocol has a definition for very field in the message. This means that all fields have very well defined purposes that can be referenced at http://www.fixtradingcommunity.org/FIXimate/FIXimate3.0/

Field NumberingIt is customary to refer to information by the field name or the field number. Usually both name and number are remembered and used in conversations. Lets say that in a conversation, you want to refer to the financial instrument that is being traded. In FIX, it was defined at symbol and the is a tag55 field in the message. Later on, we will review the most used fields name and numbers in a trade message.Data TypeAs fields in a database, FIX also contains the infrastructure and data type for these tag. You will find field definition such as string, Boolean, text and many others. FIX definition for FIX 4.2 can be found at http://www.fixtradingcommunity.org/FIXimate/FIXimate3.0/en/FIX.4.2/fix_datatypes.html Note: for each FIX version there are a different set of FIX data type.

Building block of FIX

Tag Field Data It contains ASCII data only. It cannot contain <SOH> or be emptyComponentsA FIX message is composed of many related group fields (repeating groups) and is is divided into standard header + message boy  and a standard trailer.Message LayersThey can be divided into 2 major groups: Session and Applications.Session LayerAll message related to connectivity and are contained on this layer. Heatbeats, Logons and logouts are the usual messages here. 

Application LayerMessage with a business purposes are here. There a basic and most used message type. We will be discussing less of these messages, since they are business oriented and requires knowledge of financial instruments.

Construct of a FIX Message

FIX message are constructed into 3 layers within the fields: Standard Header Message body Standard Trailer All layer are very important to each part of the understanding and life of the message.Standard header contains the identification of the message type, message length, sender/destination sequence number, sending time, etc.Message bodies are used for session or application message content.

The standard trailer are used mainly at the software level only and contains an optional digital signature and a required checksum value.

FIX protocol Tag=Value Syntax

I want everybody to focus on this. As you become familiar with FIX protocol, this will become less of a concern. I usually like to compare this when you are learning how to drive: In the beginning you need to think about shifting gears, but as you become more experienced, gears are automatic and you are concentrating on other aspects of it.There are four part of the FIX message that you should always focus: The "tag"it identifies the field tag number, which has  a defined field name and meaning.The =  (equal)the = sign come at the end of the tag and the begining of the field content.

The ValueIt is the field data value, it can contains spaces and punctuation. The only restrictions are the delimiter and it cannot be empty.DelimiterThere is a delimiter between the tag within a message. This is a non-printing ASCII "Start of Header" or a 0x01 that can be displayed in applications as |, ^ or <SOH>.In the example below of a FIX message, you can see the tag, value and delimiter:TAG - Value - Delimiter8=FIX.4.2|9=251|35=D|49=AFUNDMGR|56=ABROKER|34=2|52=20030615-01:14:49|11=12345|1=111111|63=0|64=20030621|21=3|110=1000|111=50000|55=IBM|48=459200101|22=1|54=1|60=2003061501:14:49|38=5000|40=1|44=15.75|15=USD|59=0|10=127

Field Order Rules

There are very important rules on a FIX message:Field (tag) are uniqueThis means that each tag can only appear in the message once. The is an exception to this rule when fields are within a Repeating Group.Field OrdersField can be sent in any order within the message. Again, there are a couple of expection to this rule: Start of message  - field in the message are always ordered as 8,9,35  Standard Trailer - the last field in the message always need to be the Checksum (tag10). Repeating Groups - The order of tags inside the repeating groups always needs to be preserved.

The header fields are first, proceeded by message body fields and the trailer fields are last.NOTE: the checksum field is the module 256 of sum of every byte in the FIX message up to but not including the checksum field. 

Standard Header

The header contains valuable information for the connectivity layer of FIX. Each administrative or application message is preceded by a standard header. The header identifies the message type, length, destination, sequence number, origination point and time of a FIX Message.There are a couple of fields we need to highlight inside the header and plays a key role in the message: BeginString (88) BodyLength (9) MsgType (35) MsgSeqNum (34) PossDupFlag (43) FIX Communication is like reconciling your bank account: If you miss a message you may have more money than you think or less money that you earned. If a message is missed any circumstance,  you have the possibility of retrieving it and reconcile your flow.

Two fields help with resending messages:The PossDupFlag (43) is set to Y when resending a message as the result of a session level event (i.e. the retransmission of a message reusing a sequence number). The PossResend (97) is set to Y when reissuing a message with a new sequence number (e.g. resending an order). The receiving application should process these messages as follows: PossDupFlag - if a message with this sequence number has been previously received, ignore message, if not, process normally. PossResend - forward message to application and determine if previously received (i.e. verify order id and parameters).

Standard Header

BodyLength also play a hey role in the message. The message length is indicated in the BodyLength field and is verified by counting the number of characters in the message following the BodyLength field up to, and including, the delimiter immediately preceding the CheckSum tag (“10=”). The CheckSum integrity check is calculated by summing the binary value of each character from the “8” of “8=“ up to and including the <SOH> character immediately preceding the CheckSum tag field and comparing the least significant eight bits of the calculated value to the CheckSum value. From these two fields, all necessary validation of the message integrity is done in a simple way. If the message checksum is different in the message, the message will get rejected specifying a wrong checksum.

So, we discussed the resend of message and how the integrity is verified which are vital things done on the standard header. Now, If you would ask me what is one of the "key" fields that you use when looking/troubleshooting at FIX messages? I would say MsgType (35)! This tag defines the business purposes of the message and is ALWAYS THIRD FIELD IN MESSAGE (Always unencrypted). We are going to review the full order lifecycle later on and all flow is based primary based on the MsgType (35).