FIX sequence numbers help recover missing messages. Brokers still need application-level reconciliation to establish the final state of an order.

The verified record

The FIX Session Layer specification defines message-sequence handling and recovery behaviour. When an incoming sequence number is higher than expected, the receiving session processor requests retransmission according to the recovery rules. The specification also describes gap handling and the sequencing of resent messages. FIX Trading Community session-layer specification ↗

These mechanisms concern the message stream. A repaired session does not, by itself, demonstrate that every downstream business record has been reconciled.

Why it matters

Imagine a hypothetical disconnection after an order is submitted but before its execution report is processed by an internal ledger. Restoring communication answers whether messages can flow again. The broker still has to establish what happened to that order and whether the ledger records it once.

This is an architectural distinction, not a claim of a flaw in FIX. Transport recovery, business identifiers and ledger controls serve different purposes. Treating a green connection indicator as proof of a fully recovered trading operation collapses those purposes into one misleading status.

What to check next

A recovery exercise should test the agreed FIX version and counterparty rules, then compare orders, executions and internal postings after reconnection. Use a deliberately interrupted test flow and verify the outcome rather than only the session status. Counterparty-specific implementation details should be documented before assuming that one recovery procedure works across every connection.