FIX Protocol: Admin Messages

Heartbeat [ tag 35 =0]

Both FIX session initiator and FIX session acceptor generate heartbeat messages at a regular interval (tag 108 =HeartBtInt) when the FIX session remains inactive in between which monitor the status of communication links and detects the incoming sequence number gaps. Heart beat interval (tag 108) is in seconds and minimum is 30 seconds and recommended value is 300 secs. Heartbeat messages are displayed on FIX session logs on regular timeout events and also as a result of Test Request Message having TestReqID (tag 112). Once a FIX session becomes inactive, heartbeat messages are sent and after some time if sending of Heartbeat messages get stopped, test request message is sent by either of the FIX server or FIX client. If still there is no Heartbeat message is received after few seconds, the communication link of FIX session is considered terminated and corrective measure is taken.

Logout [ tag 35 = 5]

Logout message gives the confirmation of the termination of FIX session. When a FIX session gets disconnected without a Logout message in it, it is treated as an abnormal termination. When the session initiator sends a logout message, it waits for the session acceptor to respond with a confirming logout message. This method of exchange of logout message before actual termination of session gives a scope for the session acceptor to perform any gap fill operation or sequence reset if required. Session acceptor can also send logout message if it receives sequence number lower than the expected. All active orders will continue to be eligible for execution after logout. Exchange or acceptor application which has cancel on logout feature enabled will cancel all the active orders in queue in case of there is any abnormal termination of the link.

PossDupFlag [tag 43] and PossResendFlag [tag 97]

Possible duplicate message is generated as a result of FIX engine not getting confirmation of if message was successfully delivered at another end or while responding to a resend request. This type of PossDup message will be retransmitted with same sequence number and with 43=Y. Receiving application might accept it as a new message or reject based on merit. Whereas Possible Resend message is generated as a result of if any order message that remains unacknowledged and client suspect it was not sent. This same order can be sent twice with same client order id (ClOrdID, tag 11) and with different sequence number and the second time sent order will have tag 97=Y. The receiving application when sees the same client order id for second time but with tag 97=Y in it, it won’t treat this message as an error and process it normally.

Sequence Reset [tag 35=4]

When messages between FIX client and server goes out of sync, sequence reset messages are used to change the client’s expected sequence number. Sequence reset when reset the sequence number to less than expected sequence number, it will create a resend request or will reject the order message.

There are 2 modes of sequence reset:

• Sequence reset-gap fill
• Sequence reset-reset

Gap fill sequence reset mode (tag 123=Y) tries to fill the sequence number gap by indicating the expected sequence number of the message just after the skipped message gap. There are 2 ways of doing gap fill sequence reset, either request all messages subsequent to the last message received or request for any specific message missed while maintaining an ordered list of all newer messages. For e.g., if the session acceptor misses 13^th of the 15 messages, the acceptor application could reject 14^th and 15^th messages and generate a resend request for messages 13^th thru 15^th or 13^th thru zero where zero represents infinity. Second option is to save message 14^th and 15^th and request for resend of only message 13^th and process the messages 14^th,15^th only after receiving and processing of 13^th message.

Sequence reset-reset mode (tag 123=N or not present) is used to recover from a disaster recovery scenario which can’t be recovered with gap fill mode. This sequence reset-reset mode does not follow the sequencing rules. There are 2 scenarios when Sequence Reset message will have a PossDupFlag set to Y:

• Tag 123=Y, tag 43=Y – message replaces the retransmission of administrative and application messages and here MsgSeqNum is ignored
• Tag 123=N or not present, tag 43=Y – forces sequence number synchronization and here MsgSeqNum is subjected to follow sequencing rule

When sequence reset method does not help on doing message recovery, drop the physical connection to terminate FIX session and reset the sequence numbers for the next FIX session. On reconnection the new FIX session will have sequence number starting from 1. Message stuck in queue might get lost in this process. So this has to be the last mode of recovery.