====== 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 Mode =====

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**.

===== Reset Mode =====

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**.

===== Recovery of Last Resort =====

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**.

===== Message Dictionary =====

^ 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     |                                                                        |

===== Sample Message =====

**Resetting Sequence Number to 30**

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

**[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)

----

[[https://docs.t4login.com/doku.php?id=faq:faq_fix_api_test|FIX API Home Page]]