Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents


This article will describe the most common cases, best practices, and configuration properties for sequence number handing and possible related issues.


When idle, the FIX engine maintains the integrity of a connection by sending Heartbeat (0) and Test Request (1) messages.

Trading session or trading hours

A FIX endpoint (for example, exchange or venue) can specify the time when the FIX client connection becomes available. More info about trading sessions can be found here:


  • Messages from previous trading days can be recovered
  • At the SOD, a client should connect with sequence numbers 1/1
  • Counterparties should maintain incrementing sequences till the EOD
  • On disconnections or on receiving a Logout message, the application can reconnect and continue with sequences from the most recently connected session within the trading day
    • This is common practice and not a strict recommendation 
    • The way the client should behave with sequences upon reconnection is usually described in a specification document or connectivity specification and can vary across different venues
  • After EOD, it is recommended to stop reconnecting and schedule the connection at the next SOD
  • After EOD, sequence numbers can be reset because on the next trading day sequences will be reset to 1/1
  • Usually after EOD, users perform cleanup procedures such as moving FIX logs to an archive if they need to be saved for an audit

Trading session limited by incoming Logout

The EOD can be triggered by an incoming Logout (5) message from a counterparty. The FIX Engine should interpret it as the end of trading hours and start the EOD procedure, such as stop session and reconnection attempts, and resetting sequences because the next logon will be considered a new trading day.



The trading day (EOD and SOD times), and hence the time for the next reconnection for the session, is configured with FIXEdge schedule. Refer to the Cron-Like Session Schedule Properties article for details.

Reset sequences on each logon or logout

There are cases when trading sessions exist only while a session is established. That means that the session state can be recovered after disconnection, can be recovered only within a connection, or sequencing isn't needed for that message flow. For example, in market data scenarios, the session state should be recovered from a snapshot and all messages from the previous connection are obsolete or redundant.

Reset on Logon

Venues recommend resetting sequences on each Logon (A). Sometimes it's required to set ResetSeqNumFlag (141) = Y in the  Logon (A) message.    


  • "0" or "false" - Does not reset sequence numbers on Logon. Keeps session sequences from a previous connection.
  • "1" or "true" - Resets sequences at the first session initiation, i.e. when the FIX Engine hasn't detected logs from the previous run.
  • "2" - Resets sequences for every Logon.

Reset on Logout

In some scenarios, venues recommend resetting sequences on logout or disconnection. In these scenarios, if sequences are reset on logon, messages accumulated after disconnection and before logon will be lost due to the message flag ResetSeqNumFlag (141) being = Y. If the user wants to send the messages accumulated after the disconnection, resetting sequences on logout is preferred to resetting sequences on logon. In the next logon message, the ResetSeqNumFlag (141) should not be present in the Logon (A) message or set to = N.


FixLayer.FixEngine.Session.Session_Name.ForceSeqNumReset should be set to false to avoid sending ResetSeqNumFlag (141) = Y in the Logon (A) message.

Reset sequences every 24 hours

FIX Engine has an option for a session to reset sequence numbers every 24 hours and send ResetSeqNumFlag (141) = Y in the Logon (A) message.



Reset sequences once a week

Some exchanges (like CME Logon Scenarios) uses weekly sessions and resets sequences once a week, using the same sequence counter across multiple days.


FIX sessions with uninterrupted connections

Sometimes a session cannot be dropped and must be maintained forever. In other words, the session should be connected 24/7/365.


There is no option to enable this behavior in our products. The functionality for sequence reset should be implemented by the user or counterparty.

Sequence numbers recovery during Logon

The counterparty can notify the initiator about an expected incoming sequence number in the confirming Logon (A) message with the NextExpectedMsgSeqNum (789) tag.


In FIXEdge C++, users can enable this sequence numbers handing mechanism by setting the session parameter FixLayer.FixEngine.Session.Session_Name.HandleSeqNumAtLogon to true.

The sequence number is too low on Logon

FIX Engine will not accept the session if it detects that a counterparty connects with a sequence lower than expected and ResetSeqNumFlag (141) is not set.This behavior is recommended by the FIX Standard as a serious problem. For example, it identifies the issue that messages on both sides are inconsistent and this may lead to financial losses.


For manual requests, the user should compose the Resend Request (2) message with tags specifying the range for requested messages with tags BeginSeqNo (7) and EndSeqNo (16).

Requesting a single message

Requesting a range of messages

To request a range of messages should be equal to the first message of range, should be equal to the last message of the range.

Requesting all messages from a specific sequence number


This approach is recommended to recover from out of sequence conditions as it allows for faster recovery in the presence of certain race conditions when both sides are simultaneously attempting to recover a gap.

Setting EndSeqNo(16) to 0 has been the recommended approach since FIX.4.2.

Negative case: Resend request with a correct BeginSeqNo and wrong EndSeqNo

In cases when the counterparty sends EndSeqNo (16) greater than the current counter of outgoing sequence numbers, FIX Antenna sends all messages from BeginSeqNo (7) to the last known message with the current outgoing sequence number.


For example, there is a request is for 1-100 but FIX Engine has only 10 messages so FIX Engine will send messages with sequence from 1 to 10.

Negative case: Resend request with a wrong BeginSeqNo

In cases when the counterparty sends invalid or greater than expected BeginSeqNo (7), the FIX Engine treats it as unexpected and sends back a reject message.



out: 8=FIX.4.4|9=80|35=2|49=TEST001|56=FIXEDGE|34=97|52=20210809-14:28:55.787|7=2147483648|16=10000|10=017|
in: 8=FIX.4.4|9=108|35=3|49=FIXEDGE|56=TEST001|34=78|52=20210809-14:28:52.813|45=97|58=Invalid Resend Request: BeginSeqNo <= 0.|10=106|

QuickFIX Behavior

  • If BeginSeqNo is greater than expected, QuickFIX doesn’t reject it but sends a Sequence Reset (4) message with NewSeqNo(36) equal to the next expected sequence number expected by the counterparty and doesn’t resend messages. 
  • If BeginSeqNo is greater than int32, then QuickFIX treats it as a negative integer (-2147483648), sends Sequence Reset message with 34=-2147483648 and 36=2, and then resends all messages.

Modify Sequence Numbers Manually

FIX Antenna C++

Sequences can be modified via API methods Session::InSeqNum and Session::OutSeqNum


The way to modify sequences is described here: FIXEdge Java Administration

Limiting the number of messages in the resend request response from FIXEdge


This option is available starting with FIXEdge version 6.3.0.


If option is not disabled, FIXEdge will ignore the duplicates of resend requests.

Performance optimizations with the ResendMessagesBlockSize parameter

FIX Engine allows fine-tuning performance by splitting one big resend request in to multiple batches of ResendMessagesBlockSize messages. The best value can be found experimentally. The blocks should be fit in a single MFU.