Quotes from FIX.4.2 specs
[Start quote from Section "FIX MESSAGE FORMAT AND DELIVERY > Sequence Numbers"]
All FIX messages are identified by a unique sequence number. Sequence numbers are initialized at the start of each FIX session (see Session Protocol section) starting at 1 (one) and increment throughout the session. Monitoring sequence numbers will enable parties to identify and react to missed messages and to gracefully synchronize applications when reconnecting during a FIX session.
Each session will establish an independent incoming and outgoing sequence series; participants will maintain a sequence series to assign to outgoing messages and a separate series to monitor for sequence gaps on incoming messages.
[End quote]
[Start Quote from section "Session Protocol > Message Recovery"]
During initialization, or in the middle of a FIX session, message gaps may occur which are detected via the tracking of incoming sequence numbers. The following section provides details on how to recover messages.
As previously stated, each FIX participant must maintain two sequence numbers for each FIX session, one each for incoming and outgoing messages which are initialized at ‘1’ at the beginning of the FIX session. Each message is assigned a unique (by connection) sequence number, which is incremented after each message. Likewise, every message received has a unique sequence number and the incoming sequence counter is incremented after each message.
When the incoming sequence number does not match the expected number corrective processing is required. Note that the SeqReset-Reset message (used only to recover from a disaster scenario vs. normal resend request processing) is an exception to this rule as it should be processed without regards to its MsgSeqNum. If the incoming message has a sequence number less than expected and the PossDupFlag is not set, it indicates a serious error. It is strongly recommended that the session be terminated and manual intervention be initiated. If the incoming sequence number is greater than expected, it indicates that messages were missed and retransmission of the messages is requested via the Resend Request (see the earlier section, Ordered Message Processing).
[End Quote]
If Sequence number(s) are changed on your side without following the above rules and and your counterparty does not abnormally change sequence numbers on their side, then the following situations would occur
1) Your side increases Outbound Sequence number - Your counterparty would send you a resend request
2) Your side decreases Outbound Sequence number - Your counterparty is expected to drop the Session
3) Your side increases next expected Inbound sequence number - receipt of the next message would cause your FIX engine to drop the session because the sequence number of the message received is less than the number your FIX engine is expecting.
4) Your side decreases next expected Inbound sequence number - receipt of next message would cause your FIX engine to send a resend request.
We have used this manually increasing / descreasing sequence numbers abnormally as part of certification tests to check that resend request processing and session disconnect are working properly at both ends.
