A FIX connection can recover its expected message sequence while an order still needs investigation. The FIX Trading Community’s session standard describes resend requests, duplicate indicators and sequence resets. Those mechanisms govern message delivery and recovery; they do not replace a broker’s separate need to determine which business events were received, processed and reflected in the order record. FIX Trading Community: FIX Session Layer technical standard, June 2020
Follow the evidence
Trace how the event could reach markets, then inspect a competing explanation.
Compare explanations
Switch lenses to see what each account explains—and what remains uncertain.
WFN analysis: suppose a broker sends an order, loses its connection and reconnects before its local system has recorded the response. Several states are possible: the counterparty never received the order, accepted it, rejected it or executed some quantity. Restoring the session alone does not identify which state occurred. That requires evidence tied to the order and the counterparty’s business records. Blindly submitting the same business instruction as a new order can create a different problem from a missing message. A recovery design needs a way to recognise whether an instruction or execution was already processed, using the relevant identifiers and agreed workflow. Sequence numbers help explain transport history; they should not be treated as a universal substitute for business identity. Replayed execution reports require similar care. The receiving application should distinguish a message being seen again from a genuinely new fill. A dashboard that simply counts every recovered message as a new event could inflate activity or distort positions even though the FIX engine has restored its sequence correctly.
WFN analysis: suppose a broker sends an order, loses its connection and reconnects before its local system has recorded the response. Several states are possible: the counterparty never received the order, accepted it, rejected it or executed some quantity. Restoring the session alone does not identify which state occurred. That requires evidence tied to the order and the counterparty’s business records. Blindly submitting the same business instruction as a new order can create a different problem from a missing message. A recovery design needs a way to recognise whether an instruction or execution was already processed, using the relevant identifiers and agreed workflow. Sequence numbers help explain transport history; they should not be treated as a universal substitute for business identity. Replayed execution reports require similar care. The receiving application should distinguish a message being seen again from a genuinely new fill. A dashboard that simply counts every recovered message as a new event could inflate activity or distort positions even though the FIX engine has restored its sequence correctly.
A useful incident review records the sequence gap, resend range, replay and gap-fill messages, then connects them to order identifiers, execution identifiers and cumulative quantities. Where the evidence remains incomplete, the unresolved business state should remain visible. Declaring an incident closed because the socket is connected can conceal the question that actually matters to customer exposure. Test recovery against realistic scenarios such as a partial fill before a disconnect, an unavailable replay message or an application restart after receipt. The objective is to establish the final order state once, with an explainable history. This article offers a review framework, not a prescription to reset live sessions; operational changes depend on the agreed FIX version and counterparty procedures.
What session recovery is designed to do
FIX messages carry sequence numbers. A resend request asks for messages within a specified sequence range. Replayed messages use duplicate indicators, and a sequence-reset message in gap-fill mode can cover messages that will not be resent. The standard distinguishes that recovery use from resetting a sequence after an unrecoverable condition. FIX Trading Community: FIX Session Layer technical standard, June 2020
A gap fill is therefore not a replacement execution report. It advances the session’s sequence understanding over a range, without recreating an omitted business event. This distinction is central when a recovered connection is being assessed: successful sequence recovery and a complete application-level order history are different questions. FIX Trading Community: FIX Session Layer technical standard, June 2020
A hypothetical disconnect exposes the boundary
WFN analysis: suppose a broker sends an order, loses its connection and reconnects before its local system has recorded the response. Several states are possible: the counterparty never received the order, accepted it, rejected it or executed some quantity. Restoring the session alone does not identify which state occurred. That requires evidence tied to the order and the counterparty’s business records.
Blindly submitting the same business instruction as a new order can create a different problem from a missing message. A recovery design needs a way to recognise whether an instruction or execution was already processed, using the relevant identifiers and agreed workflow. Sequence numbers help explain transport history; they should not be treated as a universal substitute for business identity.
Replayed execution reports require similar care. The receiving application should distinguish a message being seen again from a genuinely new fill. A dashboard that simply counts every recovered message as a new event could inflate activity or distort positions even though the FIX engine has restored its sequence correctly.
Review the recovery outcome at both layers
A useful incident review records the sequence gap, resend range, replay and gap-fill messages, then connects them to order identifiers, execution identifiers and cumulative quantities. Where the evidence remains incomplete, the unresolved business state should remain visible. Declaring an incident closed because the socket is connected can conceal the question that actually matters to customer exposure.
Test recovery against realistic scenarios such as a partial fill before a disconnect, an unavailable replay message or an application restart after receipt. The objective is to establish the final order state once, with an explainable history. This article offers a review framework, not a prescription to reset live sessions; operational changes depend on the agreed FIX version and counterparty procedures.