Just want to double confirm that one really should not be doing any checking on tag 34 (MsgSeqNum) of a Sequence Reset- Reset message (i.e. message type - tag 35 =4 and tag 123 is not specified). By “checking on tag 34” I mean if the sequence number is too low/ duplicated / sent before.
Just that today at work, I encountered a FIX counter party where they are rejection and logging us out when they spotted that we re-used a tag 34 that we sent before. I realized that ideally we should always use an ever-increasing tag 34 but I just also want to know if they are correct or not. Thanks!
Welcome!
I would expect a logout to be sent in response to that because the session is in an unexpected state.
Sending a lower sequence number message than previously sent should only be done for app messages in response to a Resend Request.
Sending a lower sequence for an admin message indicates that you think the session has reset in the meantime at the start of a new window and implies they have missed earlier messages in that window (and any messages at the end of the old window).
If they ignore the sequence re-use then they can’t guarantee they aren’t missing messages.
The counter-party behaviour is correct in my view (and is the out of the box behaviour of widely used FIX engines).
I would expect this behaviour to be somewhere in the FIX spec.
Thanks for your response, I picked up this “no checking” from FIX 4.2 spec. Administrative Messages section under the "Sequence Reset (Gap Fill) " section where it says
“… If the GapFillFlag field is not present (or set to N), it can be assumed that the purpose of the sequence reset message is to recover from an out-of-sequence condition. The MsgSeqNum in the header should be ignored (i.e. the receipt of a Sequence Reset - Reset message with an out of sequence MsgSeqNum should not generate resend requests). …”
I am thinking it is not unreasonable to understand where it says “The MsgSeqNum in the header should be ignored”… could be interpreted as not checking its validity and thus my suggestion of not applying any check.
What will be your thoughts on this ? … or maybe somewhere else, the spec mentions sequence numbers must be checked all the time no matter what?
Hi,
In the FIX Session Protocol 1.1 specification, the section about sequence reset-reset says that:
The Sequence Reset can only increase the sequence number. If a sequence reset is received attempting to decrease the next expected sequence number the message should be rejected and treated as a serious error.
I believe this applies to FIX 4.2 also.
Hi Robert,
Thanks for your reply. My understanding of this section about Sequence Reset is talking about the value of tag 36 (NewSeqNo) in the message rather than tag 34 (MsgSeqNum) because this is the function of tag 36 and not tag 34’s function - namely to inform the other side what MsgSeqNum they would expect from our side for the next FIX message we are sending after the SequenceReset message. In our case, we set tag 36 to be a new number that we have never sent out yet.
So this section does not apply to tag 34 as I understand it.
An example is like our last sent is 30 (also last received on counter party side) and the SequenceReset we send out is somehow has tag 34 (MsgSeqNum) = 25 but tag 36 (NewSeqNo) = 40 and we are not specifying tag 123 (GapFillFlag) (namely it is a “Reset” type of a Sequence Reset message)
@wof352020 thank you for raising the issue in this forum.
The specification for the FIX Session Layer has recently been refactored into a single specification (https://www.fixtrading.org/standards/fix-session-layer-online/) with so-called session profiles to capture any differences between FIX versions reflected in the value of BeginString(8), e.g. “FIX.4.2” for FIX Version 4.2 and “FIXT.1.1” for FIX Version 5.0 and above. One of the objectives was to add clarity and remove ambiguities. This is a good opportunity to validate that 
The section on Sequence Reset states: A FIX session processor may send a SequenceReset(35=4) message with GapFillFlag(123) set to “N” (Reset) and PossDupFlag(43) set to “Y” to force sequence number synchronization in the peer.
Note the use of PossDupFlag(43) set to “Y” which alerts the counterparty to the fact that he may have received the same MsgSeqNum(34) before. In combination with the SequenceReset(35=4) message I believe it is equivalent to telling the counterparty to ignore the sequence number. The ambiguity may come from the question whether a MsgSeqNum(34) should be validated first and without taking the MsgType(35) value into consideration when deciding upon the action to take.
The refactored specification includes an extensive list of test cases (https://www.fixtrading.org/standards/fix-session-testcases-online/). The test cases for Sequence Reset (Reset), i.e. Scenario 11, state: Accept the SequenceReset(35=4) message without regard to its MsgSeqNum(34).
The publication of the refactored specification in this forum (TECHNICAL STANDARD - FIX Session Protocol) states: “The refactored specification therefore supersedes the aforementioned specifications as the normative reference for the FIX Session Protocol standard.”. Please only make references to or quote from the refactored specification going forward to avoid confusion. The FIX Global Technical Committee will issue errata versions to further clarify the specification. One issue has already been detected (see Confusing MaxMessageSize (383) in the FIXT Online Technical Standard – June 2020).