The Sequence Reset (4) message is used by the sending application to reset the incoming sequence number on the opposing side. This message has two modes: "Sequence Reset-Gap Fill" when GapFillFlag (123) is 'Y' and "Sequence Reset-Reset" when GapFillFlag (123) is N or not present. The "Sequence Reset-Reset" mode should ONLY be used to recover from a disaster situation which cannot be otherwise recovered via "Gap Fill" mode. The Sequence Reset (4) message can be used in the following situations:
The sending application will initiate the Sequence Reset (4) . The message in all situations specifies NewSeqNo (36) to reset as the value of the next sequence number immediately following the messages and/or sequence numbers being skipped.
If the GapFillFlag (123) field is not present (or set to N), it can be assumed that the purpose of the Sequence Reset (4) message is to recover from an out-of-sequence condition. The MsgSeqNum (34) in the header should be ignored (i.e. the receipt of a Sequence Reset - Reset (4) message with an out of sequence MsgSeqNum (34) should not generate resend requests). Sequence Reset - Reset (4) should NOT be used as a normal response to a Resend Request (2) (use Sequence Reset - Gap Fill (4) ). The Sequence Reset - Reset (4) should ONLY be used to recover from a disaster situation which cannot be recovered via the use of Sequence Reset - Gap Fill (4) . Note that the use of Sequence Reset - Reset (4) may result in the possibility of lost messages
If the GapFillFlag (123) field is present (and equal to Y), the MsgSeqNum (34) should conform to standard message sequencing rules (i.e. the MsgSeqNum (34) of the Sequence Reset-GapFill (4) message should represent the beginning MsgSeqNum (34) in the GapFill range because the remote side is expecting that next message).
The Sequence Reset (4) can only increase the sequence number. If a Sequence Reset (4) is received attempting to decrease the next expected sequence number the message should be rejected and treated as a serious error. It is possible to have multiple Resend Requests (2) issued in a row (i.e. 5 to 10 followed by 5 to 11). If sequence number 8, 10, and 11 represent application messages while the 5-7 and 9 represent administrative messages, the series of messages as result of the Resend Request (2) may appear as SeqReset-GapFill (4) with NewSeqNo (36) of 8, message 8, SeqReset-GapFill with NewSeqNo of 10, and message 10. This could then followed by SeqReset-GapFill (4) with NewSeqNo (36) of 8, message 8, SeqReset-GapFill (4) with NewSeqNo (36) of 10, message 10, and message 11. One must be careful to ignore the duplicate SeqReset-GapFill (4) which is attempting to lower the next expected sequence number. This can be detected by checking to see if its MsgSeqNum (34) is less than expected. If so, the SeqReset-GapFill (4) is a duplicate and should be discarded.
| Tag | Field Name | FIXML | Req'd | Comments | |||
|---|---|---|---|---|---|---|---|
| <Standard Message Header> | Y | MsgType = 4 | |||||
| 123 | GapFillFlag | N | |||||
| 36 | NewSeqNo | Y | |||||
| <Standard Message Trailer> | Y | ||||||
© 2026.
EPAM Systems. All Rights Reserved.
All material contained within the website is copyright of EPAM Systems, Inc. No material contained herein can be copied or otherwise used without the express permission of the copyright holder.