Sequence Numbers, Gap Fill And Resend Requests

Every message sent within a FIX session — Logon, Heartbeat, New Order, Execution Report, everything — carries a tag called MsgSeqNum, an integer that increases by exactly one with each message a side sends. Both sides track their own outgoing counter and the counter they expect next from the other side. This turns "did we lose a message?" from a question you'd otherwise have no way to answer into something that's checked automatically on every single message.

What happens when a number is missing

If a firm receives a message with sequence number 108 when it was expecting 105, it knows immediately that messages 105, 106, and 107 either arrived out of order or never arrived at all. Rather than guessing, it sends a Resend Request asking the counterparty to retransmit everything from 105 onward. The counterparty replies with a gap fill — either the original messages resent verbatim, or, for messages that no longer matter (an old heartbeat, say), a special "sequence reset - gap fill" message that just advances the counter administratively without resending content that's no longer meaningful to replay.

Crucially, the receiving side won't process any new application messages while it knows it's missing earlier ones — a new order sitting behind the gap is queued, not skipped, because processing it out of order could mean acting on stale or incomplete information. This is what makes FIX sessions strict about ordering: a firm can be confident that if it received message 112, everything up to 111 was also received and processed, in order, with nothing silently dropped.

Where this bites in practice

At the start of a new trading day, both sides typically reset sequence numbers to 1 in the Logon message, and mismatches here are one of the most common connectivity problems desks see — a firm that reconnects mid-day using the previous day's counter, for instance, will trigger a resend cascade or an outright session reject until the numbering is reconciled. Because the check is exact-integer, there's no ambiguity or tolerance to configure: either the next number is what's expected, or the gap machinery kicks in.