faq:sequence_reset

Sequence Reset

Resetting Sequence Numbers

The Sequence Reset message requests the counterparty to change the requestor's expected sequence number. The new sequence number is indicated by the mandatory field NewSeqNo (Tag 36).

Under out-of-sequence conditions, Sequence Reset messages are important as they provide a mechanism to skip message gaps that are not to be honored by a Resend Request. Sequence Resets also provide a mechanism of recovery from disaster conditions.

Sequence number resets can only increase the sequence number. Sequence Resets attempting to reset to a sequence number less than expected can generate a Resend Request or a Reject condition.

Sequence Resets are encountered in two modes:

Mode Tag# GapFillFlag
Gap Fill 123 Y
Reset 123 N or absent

Gap-Fill Sequence Resets attempt to fill the sequence number gap by indicating (with NewSeqNo - Tag 36) the sequence number of the message that shall be expected immediately following the skipped message gap.

Gap-Fill Sequence Resets are generated as a response to the Resend Request message to indicate that messages are to be skipped from the requested resend range.

Messages may be ignored in a resend sequence if:

  • They are administrative (e.g. heartbeats, test requests).
  • The resending party chooses not to send certain messages due to risk and/or age considerations.

Message gaps where multiple messages are to be ignored should be serviced by a single Sequence Reset, not one per message. For example, for a continuous gap from sequence numbers 89 to 95, a single Sequence Reset with NewSeqNo (Tag 36) = 96 should be sent.

The Gap-Fill mode Sequence Reset must conform to the protocol sequencing rules. The sequence number of the Gap-Fill message (Tag 34) must reflect the next sequence number expected by the counterparty (i.e., the first message in the gap).

Failure to do so will result in a Resend Request.

The Reset mode Sequence Reset is used for application failures where the Gap-Fill mode is not sufficient to regain normal sequencing.

Use of Reset mode should be limited to disaster recovery situations.

Reset mode messages:

  • Are not required to follow sequence number protocol (Tag 34).
  • Will not trigger Resend Requests, even with incorrect sequence numbers.
  • Carry the risk of message loss.

If recovery is not possible with Sequence Resets, dropping the physical connection will terminate the current FIX session.

Upon reconnection:

  • A new T4 FIX API session starts.
  • Sequence numbers will reset to 1.
  • Message loss may occur.
Tag Field Name Req'd Comments
- Standard Header Y MsgType = 4
123 GapFillFlag N Indicates message is replacing admin or application messages.
36 NewSeqNo Y New sequence number
- Standard Trailer Y

Resetting Sequence Number to 30

34=2|49=T4Example|56=T4|50=TraderName|52=20120906-14:14:16.424|36=30|123=Y|

[FIXSEQUENCERESET]

  • [MsgSeqNum] 34 = 2
  • [SenderCompID] 49 = T4Example
  • [TargetCompID] 56 = T4
  • [SenderSubID] 50 = TraderName
  • [SendingTime] 52 = 20120906-14:14:16.424
  • [NewSeqNo] 36 = 30
  • [GapFillFlag] 123 = Y (YES)

FIX API Home Page

  • faq/sequence_reset.txt
  • Last modified: 2025/07/25 14:00
  • by rob