FIX Sessions and Recovery
Maintain FIX sessions, restart market data from fresh state, and recover order-entry sequence gaps.
Market data and order entry use separate FIX sessions. Both use FIXT 1.1 session messages with FIX 5.0 SP2 application messages. Each session has its own sequence numbers and recovery state.
This page explains session behavior. The Header and Trailer and Session Messages references define the fields. See FIX Message Layouts for field presence and repeating-group rules.
Establish a Session
Complete the Logon(A) exchange before sending application messages. Use a heartbeat interval of at least 30 seconds, such as HeartBtInt(108)=30.
If your Logon(A) requests a shorter heartbeat interval, the exchange answers with Logout(5) and closes the connection.
For market data, start fresh on every connection using the procedure in Reconnect to Market Data. You do not need to preserve sequence numbers across connections.
An order-entry FIX session can continue across network connections. Keep that session’s sequence state when reconnecting; opening a new connection is not a reason to start its sequence numbers over. Sequence recovery and an explicit reset have different consequences for order entry, described below.
Maintain a Session
Send Heartbeat(0) when no other outgoing traffic has been sent during the heartbeat interval. Ordinary traffic also keeps the session active.
Answer each TestRequest(1) with Heartbeat(0) carrying the same TestReqID(112). An unrelated heartbeat does not answer that test request. Handle these messages even while processing a busy application stream.
The exchange tests a session that stops responding and disconnects it if it remains unresponsive. Market-data sessions may also be disconnected when a subscriber falls too far behind. A lag-related disconnection can close the connection without completing a Logout(5) exchange. Follow Reconnect to Market Data to restore subscriptions; the exchange does not replay a market-data backlog.
Track Sequence Numbers
Maintain the next outgoing and expected incoming MsgSeqNum(34) independently. Session and application messages share the sequence in each direction. A retransmitted message retains its original sequence number.
| Incoming sequence | Action |
|---|---|
| Matches the expected number | Process the message and advance the expected number. |
| Higher than expected | Hold later messages until the gap is resolved. For market data, reconnect and rebuild state. For order entry, recover the missing messages. |
| Lower than expected | Treat it as a possible retransmission only when it is marked as a duplicate. An unmarked lower sequence number can end the session. |
Reconnect to Market Data
After a lag-related disconnection, wait at least 60 seconds before reconnecting; earlier Logon(A) attempts are rejected.
On every market-data connection, send Logon(A) with ResetSeqNumFlag(141)=Y and MsgSeqNum(34)=1. The exchange confirms the reset in its Logon(A). Sequence numbers then increase for the duration of that connection.
After logout or connection loss, the session’s book, catalog, and trading-status subscriptions are removed. After completing the fresh logon:
- Reissue the subscriptions you still need.
- Rebuild each book from its initial MarketDataSnapshotFullRefresh(W).
- Apply subsequent updates according to that subscription’s refresh mode.
Missed market-data messages, including trades, are not replayed. A fresh book snapshot restores the current book; it does not recover missed trades. If a sequence gap occurs during a connection, reconnect and rebuild state before applying further incremental updates.
Recover Order Entry
Order entry can replay retained application messages. Retention is bounded, so a requested range may contain messages that are no longer available. The exchange gap-fills those numbers and session messages instead of returning their original payloads.
Use ResendRequest(2) to request a missing range. BeginSeqNo(7) identifies the first missing number and EndSeqNo(16) the last requested number. EndSeqNo(16)=0 requests the range through the most recently sent message.
The exchange may answer with retransmitted application messages, SequenceReset(4) gap fills, or both. A gap fill advances the expected number to NewSeqNo(36), which is the next expected number, not the last skipped number. It supplies no application payload for the skipped range.
Retransmissions carry PossDupFlag(43)=Y, retain the original MsgSeqNum(34), and identify the original transmission time in OrigSendingTime(122). SendingTime(52) reflects the retransmission. Apply duplicate detection before applying a retransmitted application’s effects again. When the exchange requests messages from your session, let your FIX engine resend retained application messages and gap-fill skipped session traffic.
Distinguish retransmission from the first delivery of a report held during downtime:
| Delivery | Sequence and duplicate handling |
|---|---|
| Retransmission | A previously sent message returned during recovery. Retains its original MsgSeqNum(34) and carries PossDupFlag(43)=Y and OrigSendingTime(122). |
| Held report | First delivery of an execution or RFQ report held while the session was disconnected. Sent after logon as a new message with a newly assigned MsgSeqNum(34), without PossDupFlag(43)=Y. Held reports are delivered oldest first, ahead of newer reports. |
A connection loss does not establish that an order or RFQ action failed. Recover and reconcile the resulting reports before deciding whether to send another action. Creating another order to replace an uncertain request can create a second order.
A gap fill is not an order-status report and does not prove that no trade occurred. If recovery leaves an order or execution unresolved, contact support to reconcile it before retrying.
Reset an Order-Entry Session
An explicit reset starts a new sequence history. Logon(A) with ResetSeqNumFlag(141)=Y resets both sequence counters to 1 and clears retained messages from the old replay history. Logon(A) itself uses the first sequence number; subsequent messages continue from there. A reset is not a substitute for recovering missing execution reports.
Coordinate an order-entry reset with support when the two sides cannot reconcile sequence state. Do not reset an order-entry session merely because a connection dropped. Routine market-data reconnects use the reset-on-logon procedure above and do not require a coordinated reset.
Reports held for an order-entry session that have not yet been sent are separate from its retained replay history. A sequence reset does not discard those held reports; they are delivered as new messages after logon.
End a Session
Use Logout(5) to end a session cleanly and allow the logout exchange to complete before closing the connection. A clean logout and an unexpected connection loss both remove market-data subscriptions.
Order-entry cancel-on-disconnect is off by default. When enabled for the session, it requests cancellation of that session’s resting orders after either clean logout or connection loss. Do not treat disconnection as confirmation of cancellation: cancellation can fail or remain incomplete, including during a service interruption. Reconcile the resulting order reports after reconnecting.