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 13th of the 15 messages, the acceptor application could reject 14th and 15th messages and generate a resend request for messages 13th thru 15th or 13th thru zero where zero represents infinity. Second option is to save message 14th and 15th and request for resend of only message 13th and process the messages 14th,15th only after receiving and processing of 13th 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.
Case study of Order Requests
- Client side sends new single order(35=D) message to exchange -> Exchange response message will have acknowledgement in execution report (35=8,150=0) -> Exchange will again send response messages for partial fill (35=8,150=1), fill (35=8,150=2).
- Client side sends new single order(35=D) to exchange -> Exchange will respond with acknowledgement (35=8,150=0) -> Exchange response with partial fill message (35=8,150=1) -> client request for order cancellation for remaining quantity (35=F) -> Exchange will send ack to client side with order is pending for cancel (35=8,150=6) -> Exchange sends confirmation of cancellation of remaining order (35=8, 150=4)
- Client sends new order (35=D) -> Exchange gives ack (35=8,150=0) -> Exchanges sends partial fill message (35=8, 150=1 ,39=1) -> client sends cancellation request of remaining order (35=F) -> Exchange sends ack for pending cancel (35=8, 150=6, 39=6) -> Exchange sends another set of partial fill order status (35=8,150=1, 39=1) -> Exchange sends confirmation of cancellation of remaining orders (35=8, 150=4)
- Client sends new order (35=D) -> Exchanges ack (35=8, 150=0) -> Exchange sends partial fill message (35=8, 150=1, 39=1) -> client sends cancellation of remaining(35=F) -> Exchange responds with pending cancel (35=8,150=6,39=6) -> Exchange responds with remaining quantity getting filled (35=8,150=2, 39=2) -> Exchanges sends cancellation rejection (35=8,150=8, 39=2)
- Client sends new order (35=D) -> Exchange sends ack (35=8, 150=0) -> Exchange sends partial fills (35=8, 150=1) -> client sends order cancel/replace request on the existing open order to modify price/quantity of existing open orders (35=G) -> Exchange responds with ack for pending cancel/replace message (35=8, 150=E) -> Exchange send partial fill messages (35=8, 150=1 ,39=1) -> Exchange sends fill messages (35=8, 150=1 ,39=2)
OrdStatus (39) Vs ExecType (150)
Tag 39, order status will always contain the status of the order and if the order exists in more than one state, the status with the highest order of preference is stored in OrdStatus.
Tag 150, execution type checks the purpose of execution report.