FIX Protocol Session or Admin messages tutorial
I have been working in FIX protocol for almost 5 years when I started working on FIX protocol I looked upon internet for some good tutorial which could supplement or complement lengthy FIX protocol specification there was nothing at that time so when I started my blog I thought to write about my own experience in FIX protocol as short, clear and concise tutorial format. Since I like question answer type of knowledge sharing too I have written some blog post on FIX protocol Interview questions you may find it interesting.
In today’s FIX tutorial we are going to have a look on FIX protocol session level messages. As you guys may know all FIX messages can be broadly classified in two categories Admin messages also called session level messages and Application messages which include Trade, pre trade and post trades messages. Understanding of how FIX session works is very important because until you know the fundamental of FIX Sequence number, how does FIX session gets connected , what are the sequence of messages that flows between Sender Fix Engine and receiver FIX engine you won’t be able to quickly identify any problem related to FIX protocol. FIX specification is very clear about what should FIX engine do on various FIX session connection / disconnection scenario.
Just to revise as per FIX protocol first Sender FIX Engine and receiver FIX engine connects to each other on TCP/IP protocol on specified IP and Port via leased line , Radianz link , Virtual Private network(VPN) or via internet. Once TCP Socket level connectivity established Sender application sends Logon (fix tag 35=A MsgType=A) with agreed SenderCompID (fix tag 49) and TargetCompID (fix tag 56). Receiver FIX engine receives this message and authenticate Sender FIX Engine client based upon SenderCompID (fix tag 49) and TargetCompID (fix tag 56) ,if client is authenticated successfully then receiver fix engine replies with same sends Logon (fix tag 35=A) message and connection is successfully established and then both FIX engine will send Heartbeat messages (fix tag 35=0) at specified heartbeat interval to keep connection alive. In case receiver FIX engine is not able to authenticate client it will send a Logout message (fix tag 35=5) and connection will be terminated though socket connection will still be there. Receiver FIX engine can also send Logout message (fix tag 35=5) if it receives fix message with sequence number lower than it is expecting.
Now let’s see each of session level or Admin messages in little detail. You can always refer FIX protocol specification document and that is recommended also to get complete description of each of these messages.
Some important Session level or Administrative messages specified in FIX specification are following:
Heartbeat:
Heartbeat messages are denoted by MsgType=0 in financial information exchange (FIX) Protocol. Both FIX Session Initiator and FIX Session Acceptor sends each other Heartbeat messages to keep FIX session alive on a interval defined by Heartbeat Interval which is usually 30 or 60 seconds. If you see Heartbeat message (FIX tag 35=0) in your FIX Engine log file means your FIX session is up and connected.
Heartbeat messages are denoted by MsgType=0 in financial information exchange (FIX) Protocol. Both FIX Session Initiator and FIX Session Acceptor sends each other Heartbeat messages to keep FIX session alive on a interval defined by Heartbeat Interval which is usually 30 or 60 seconds. If you see Heartbeat message (FIX tag 35=0) in your FIX Engine log file means your FIX session is up and connected.
Logon:
Logon message is denoted by FIX tag 35=A and it is used to send login message from FIX initiator. As per FIX Protocol once TCP connection between FIX Initiator and FIX Acceptor got established, FIX initiator sends Logon message (tag 35=A) with pre agreed SenderCompID (tag 49) and TargetCompID (tag 56) and with Sequence No (FIX tag 34) expecting by FIX Acceptor. When FIX Acceptor receives Logon request (MsgType=A) it authenticate FIX session based on CompID specified in FIX Message and Sequence No and reply back with either Logout (tag 35=5) message or Logon(tag 35=A) message based upon result of authentication.
Logon message is denoted by FIX tag 35=A and it is used to send login message from FIX initiator. As per FIX Protocol once TCP connection between FIX Initiator and FIX Acceptor got established, FIX initiator sends Logon message (tag 35=A) with pre agreed SenderCompID (tag 49) and TargetCompID (tag 56) and with Sequence No (FIX tag 34) expecting by FIX Acceptor. When FIX Acceptor receives Logon request (MsgType=A) it authenticate FIX session based on CompID specified in FIX Message and Sequence No and reply back with either Logout (tag 35=5) message or Logon(tag 35=A) message based upon result of authentication.
Resend Request
Resend Request (FIX tag 35=2 or MsgType=2) is used for asking of retransmission or replay of lost messages during transmission or due to incorrect sequence number. It’s normally sent by the FIX Engine which is receiving message to initiate the retransmission of messages. FIX Engine uses Resend Request (tag 35=2) if a sequence number gap is detected or if FIX Engine of receiving application lost a message or as a part of initialization process to make sequence number in sync.
Resend Request (FIX tag 35=2 or MsgType=2) is used for asking of retransmission or replay of lost messages during transmission or due to incorrect sequence number. It’s normally sent by the FIX Engine which is receiving message to initiate the retransmission of messages. FIX Engine uses Resend Request (tag 35=2) if a sequence number gap is detected or if FIX Engine of receiving application lost a message or as a part of initialization process to make sequence number in sync.
Resend Request (FIX tag 35=2 or MsgType=2) can be used to request a single FIX message, a range of FIX messages or all FIX messages subsequent to a particular FIX message.
Its worth noting that sending FIX Engine may like to consider the message type when resending messages; e.g. if a new order is in the resend series and a significant time period has been passed since it was originally sent, the sender FIX Engine may not wish to retransmit the order since market dynamics an price etc might have been changed also this may result in stale order reject which is done by Order Management Systems (OMS). (The Sequence Reset (FIX tag 35=4 or MsgType=4) Also called as Gap Fill is used to skip FIX messages that a sender FIX Engine does not want to resend.)
It is mandatory that the receiving FIX Engine process messages in sequential order, e.g. if FIX message number 11 is missed and 12-13 received, the application should ignore 12 and 13 and ask for a resend of 11-13, or 11 -0 (0 denotes infinity). Second approach is strongly recommended to recover from out of sequence conditions as it allows for faster recovery in the presence of certain race conditions when both sides of FIX Engines are simultaneously attempting to recover a sequence number gap.
Test Request
In financial information exchange also called FIX Protocol Test Request is denoted by FIX tag 35=1 or MsgType=1. Test Request FIX Message is used by FIX Engine to forces a heartbeat from the opposing FIX Engine. The Test Request (FIX tag 35=1) message checks sequence numbers or verifies communication line status. The opposite FIX Engine responds to the Test Request Test Request (FIX tag 35=1) with a Heartbeat (FIX tag 35=0) containing the TestReqID (FIX tag 112).
The TestReqID FIX tag 112) verifies that the counterparty FIX Engine is generating the Heartbeat (FIX tag 35=0) as the result of Test Request (FIX tag 35=1) and not a normal timeout. The opposite FIX Engine includes the TestReqID (FIX tag 112) in the resulting Heartbeat (FIX tag 35=0). Any string can be used as the Heartbeat (FIX tag 35=0) (Some fix engine generally uses a timestamp string).
Session Level Reject
In financial information exchange (FIX) protocol Session level Reject or Reject message is denoted by FIX tag 35=3 or MsgType=3. Session level Reject is used by FIX engine when a fix message is received but cannot be properly processed due to a session-level rule violation as specified in FIX Protocol specification document. As an example FIX Engine will use Session level Reject or a reject it receives a FIX message with invalid basic data (e.g. MsgType 35 =$) which successfully passes de-encryption, Checksum (FIX tag 10) and BodyLength (FIX tag 9) checks. As a rule FIX messages should be forwarded to the trading application for business level rejections whenever possible.
In financial information exchange (FIX) protocol Session level Reject or Reject message is denoted by FIX tag 35=3 or MsgType=3. Session level Reject is used by FIX engine when a fix message is received but cannot be properly processed due to a session-level rule violation as specified in FIX Protocol specification document. As an example FIX Engine will use Session level Reject or a reject it receives a FIX message with invalid basic data (e.g. MsgType 35 =$) which successfully passes de-encryption, Checksum (FIX tag 10) and BodyLength (FIX tag 9) checks. As a rule FIX messages should be forwarded to the trading application for business level rejections whenever possible.
Rejected messages should be logged into log file and the incoming sequence number must be incremented by FIX Engine.
Its worth noting that receiving FIX Engine should disregard any FIX message which is incorrect , cannot be parsed or fails a data integrity check. Processing of the next valid FIX message will cause detection of a sequence number mismatch and a Resend Request (FIX tag 35=2 or MsgType=2) will be generated and passed to counter-party FIX Engine.
Generation and receipt of a Reject (FIX tag 3) message indicates a serious error that may be the result of faulty logic in either the sending or receiving FIX Engine.
If the sending FIX Engine chooses to retransmit the rejected message, it should be assigned a new sequence number (FIX tag 34) and sent with PossResend (FIX tag 97) =Y.
Its recommended to describe the cause of reject in the fix tag Text (FIX Tag 58) which then can be used by receiving FIX engine or developer to identify actual cause of Session level reject (e.g. Price tag is missing in Limit Order).
Below are some scenarios where session-level Reject (FIX Tag 3 or MsgType=3) can be used.
CompID problem: Either FIX Initiator or FIX Acceptor is sending incorrect SenderCompID (tag 49) and TargetCompID (tag 56).
Invalid MsgType: Either FIX initiator or FIX Acceptor is sending MsgType other than specified in FIX Specification for that particular FIX Version e.g. FIX4.2
Incorrect data format for value: If a FIX tag has a data type Timestamp and FIX engine is sending some other data type
Required tag missing: Either FIX Initiator or FIX Acceptor is not sending mandatory FIX tag in a particular FIX message e.g. Price (FIX tag 44) missing in a NewOrderSingle (MsgType=D) message with OrdType =2 i.e. Limit Order.
Invalid tag number: Either FIX initiator or FIX Acceptor is sending any tag other than specified in FIX Specification for that particular FIX Version e.g. FIX4.2
Tag not defined for this message type: Either FIX initiator or FIX Acceptor is sending any tag other than specified in FIX Specification for that particular message type e.g. Sending TestReqID in logout message.
Undefined Tag: In case any of sender FIX engine is sending custom tag and that is not configured or supported by Revenging fix engine.
Tag specified without a value: e.g. 35= and there is no value for that particular fix tag. Its not a valid fix message and so receiving fix engine will reject it.
Sequence Reset
Sequence Reset also called as Gap fill messages is denoted by FIX tag 35=4 or FIX MsgType 35=4. It is used in response to Resend Request (FIX tag 35=2 or MsgType=2) by sending FIX engine to reset the incoming sequence number on the opposing side FIX engine. Sequence Reset message (fix tag 35=4) operates in two different modes one in which GapFillFlag (FIX tag 123) is 'Y' also called Sequence Reset - Gap Fill and second mode on which GapFillFlag (FIX tag 123) is 'N' or not present also called Sequence Reset - Reset mode. As per FIX protocol specification the "Sequence Reset (fix tag 35=4)-Reset" mode should ONLY be used to recover from a disaster situation which cannot be otherwise recovered by "Gap Fill" mode.
Sequence Reset also called as Gap fill messages is denoted by FIX tag 35=4 or FIX MsgType 35=4. It is used in response to Resend Request (FIX tag 35=2 or MsgType=2) by sending FIX engine to reset the incoming sequence number on the opposing side FIX engine. Sequence Reset message (fix tag 35=4) operates in two different modes one in which GapFillFlag (FIX tag 123) is 'Y' also called Sequence Reset - Gap Fill and second mode on which GapFillFlag (FIX tag 123) is 'N' or not present also called Sequence Reset - Reset mode. As per FIX protocol specification the "Sequence Reset (fix tag 35=4)-Reset" mode should ONLY be used to recover from a disaster situation which cannot be otherwise recovered by "Gap Fill" mode.
The Sequence Reset or GapFill message (fix tag 35=4) can be useful in the following circumstances:
1. While processing Resend Request (FIX tag 35=2 or MsgType=2) sending FIX Engine may choose not to send a message (e.g. a stale order). The Sequence Reset (fix tag 35=4) - Gap Fill can be used to fill the place of that message.
2. While processing Resend Request (FIX tag 35=2 or MsgType=2) sending FIX Engine may choose not to send a message if all the messages are only administrative or session level messages, because there is no point on resending them in that case also Sequence Reset (fix tag 35=4) - Gap Fill is used to fill the message or sequence gap.
Logout
Logout message is denoted by FIX tag 35=5 or MsgType=5 in FIX protocol specification and it is used to terminate or close any FIX session. In case receiver FIX engine is not able to authenticate client it will send a Logout message (fix tag 35=5) and connection will be terminated though socket connection will still be there. Receiver FIX engine can also send Logout message (fix tag 35=5) if it receives fix message with sequence number lower than it is expecting. The Logout message (fix tag 35=5) is used to terminate a FIX session. Termination or disconnection without the exchange of Logout message (fix tag 35=5) messages is treated an abnormal condition.
Logout message is denoted by FIX tag 35=5 or MsgType=5 in FIX protocol specification and it is used to terminate or close any FIX session. In case receiver FIX engine is not able to authenticate client it will send a Logout message (fix tag 35=5) and connection will be terminated though socket connection will still be there. Receiver FIX engine can also send Logout message (fix tag 35=5) if it receives fix message with sequence number lower than it is expecting. The Logout message (fix tag 35=5) is used to terminate a FIX session. Termination or disconnection without the exchange of Logout message (fix tag 35=5) messages is treated an abnormal condition.
Exchange of Logout message (fix tag 35=5) before actually terminating or closing the session allows the initiator FIX engine to perform any kind of Sequence Reset (fix tag 35=4) or Gap fill operations that may be required or necessary. Logout initiator should also wait for the opposite FIX engine to respond with a confirming Logout message (fix tag 35=5) it can terminate the session in case the remote FIX Engine does not respond within a specified time period.
Related post:
FIX Protocol Tutorial 2: Basics of FIX Protocol and FIX Engine
