Network & Connectivity Sequence Numbers Logon Failures Fill Reconciliation Order Rejects Latency & Timing Duplicate Orders Gap Fill & Resend
SEQ 10 min read Troubleshooting

Sequence Number Issues

Diagnose and recover from FIX sequence number problems without disrupting live sessions.
Critical Warning
Never reset sequence numbers while orders are live
Quick Triage
  • 1 Check the error message — does it say MsgSeqNum too low or MsgSeqNum too high? The direction tells you which side is out of sync.
  • 2 Note the expected vs received sequence numbers from the reject message — Tag 45 (RefSeqNum) and Tag 58 (Text) contain the expected and received values.
  • 3 Check your outbound sequence counter — does it match what the counterparty expects? A stale or corrupted sequence store after a restart is the most common cause.
  • 4 Check your inbound sequence counter — are you missing messages from the counterparty? If your counter is behind theirs, you need to send a Resend Request.
  • 5 Determine if the gap occurred on your side, their side, or both — this determines whether you send a Resend Request, respond to theirs, or need a coordinated reset.
  • 6 Decide: Resend Request, Gap Fill, or Hard Reset — see Recovery Basics below. Use the least disruptive option first.
Common Problems
Symptom Likely Cause What to Check
MsgSeqNum too low Sequence not reset after previous session reset Your outbound counter vs counterparty's expected value
MsgSeqNum too high Missed inbound messages Send Resend Request (35=2) for the missing range
Sequence gap on reconnect Abrupt disconnect without Logout Reconnect without ResetSeqNumFlag, then send Resend Request (35=2)
Duplicate sequence numbers Counter reset mid-session Audit your sequence storage — file or database
Counterparty sends Resend Request (35=2) You missed their message Retransmit with PossDupFlag=Y
Both sides out of sync Crash or hard restart Coordinate reset with counterparty, confirm no open orders
Recovery Basics

Three tools to recover sequence numbers. Use the least disruptive option first.

Method When to Use Risk
Resend Request 35=2 Gap in inbound messages Low — no disruption to outbound
Sequence Reset 35=4, GapFillFlag (123) = Y Skip administrative messages during resend Low — standard FIX behavior
Hard Reset ResetSeqNumFlag=Y Both sides confirmed out of sync, no open orders High — must coordinate with counterparty

Example Resend Request — Tag 7 (BeginSeqNo) is the first missing message; Tag 16 (EndSeqNo) = 0 means through the last sent.

8=FIX.4.2|9=65|35=2|49=CLIENTA|56=BROKRB|34=8|52=20240315-09:35:00|7=5|16=0|10=000|
Reading the Logs
ERROR: Received MsgSeqNum 47, expected 43 INFO: Sending ResendRequest BeginSeqNo=43 EndSeqNo=0 INFO: Received Resend: MsgSeqNum=43 PossDupFlag=Y INFO: Received Resend: MsgSeqNum=44 PossDupFlag=Y INFO: Received GapFill: NewSeqNo=47 INFO: Session synchronized. Next expected: 47
  • • The gap was inbound — messages 43–46 were missed, likely due to a network blip. Your engine sent a Resend Request for the range automatically.
  • • PossDupFlag=Y on retransmitted messages — process them but check ExecID (17) for duplicates before applying any fills to your position.
  • • The Gap Fill skipped messages 45–46 — the counterparty is telling you those were administrative messages (heartbeats, test requests) that you do not need.
Before You Reset

Run through this before touching any sequence numbers. A 5-minute check here prevents hours of reconciliation later.

Sequence Numbers — Pre-Reset Checklist
5-Minute Diagnosis
Sequence Numbers — TL;DR
  1. Is the error MsgSeqNum too low or too high?
  2. What sequence numbers does each side expect?
  3. Is the gap on your inbound, your outbound, or both?
  4. Can Resend Request (35=2) or Gap Fill recover — or is a reset required?
  5. Reconcile open orders before changing any sequence state.