MESSAGE DELIVERY

The following section summarizes general specifications for transmitting FIX messages.

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.

Heartbeats:

During periods of message inactivity, FIX applications will generate Heartbeat<0> messages at regular time intervals. The heartbeat monitors the status of the communication link and identifies incoming sequence number gaps. The Heartbeat Interval is declared by the session initiator using the HeartBtInt(108) field in the Logon<A> message. The heartbeat interval timer should be reset after every message is transmitted (not just heartbeats). The HeartBtInt(108) value should be agreed upon by the two firms and specified by the Logon initiator and echoed back by the Logon acceptor. Note that the same HeartBtInt(108) value is used by both sides, the Logon “initiator” and Logon “acceptor”.

Ordered Message Processing

The FIX protocol assumes complete ordered delivery of messages between parties. Implementers should consider this when designing message gap fill processes. Two options exist for dealing with gaps, either request all messages subsequent to the last message received or ask for the specific message missed while maintaining an ordered list of all newer messages. For example, if the receiver misses the second of five messages, the application could ignore messages 3 through 5 and generate a resend request for messages 2 through 5, or, preferably 2 through 0 (where 0 represents infinity). Another option would involve saving messages 3 through 5 and resending only message 2. In both cases, messages 3 through 5 should not be processed before message 2.

Possible Duplicates

When a FIX engine is unsure if a message was successfully received at its intended destination or when responding to a resend request, a possible duplicate message is generated. The message will be a retransmission (with the same sequence number) of the application data in question with the PossDupFlag(43) included and set to "Y" in the header. It is the receiving application's responsibility to handle the message (i.e. treat as a new message or discard as appropriate). All messages created as the result of a resend request will contain the PossDupFlag field set to “Y”. Messages lacking the PossDupFlag(43) field or with the PossDupFlag(43) field set to “N” should be treated as original transmissions.

Note: When retransmitting a message with the PossDupFlag(43) set to “Y”, it is always necessary to recalculate the CheckSum(10) value. The only fields that can change in a possible duplicate message are the CheckSum(10), OrigSendingTime(122), SendingTime(52), BodyLength(9) and PossDupFlag(43). Fields related to encryption (SecureDataLen(90) and SecureData(91)) may also require recasting.

Possible Resends

Ambiguous application level messages may be resent with the PossResend(97) flag set. This is useful when an order remains unacknowledged for an inordinate length of time and the end-user suspects it had never been sent. The receiving application must recognize this flag and interrogate internal fields (order number, etc.) to determine if this order has been previously received.

Note: The possible resend message will contain exactly the same body data but will have the PossResend(97) flag and will have a new sequence number. In addition the CheckSum(10) field will require recalculation and fields related to encryption (SecureDataLen(90) and SecureData(91)) may also require recasting.

Data Integrity

The integrity of message data content can be verified in two ways: verification of message length and a simple checksum of characters. The message length is indicated in the BodyLength(9) field and is verified by counting the number of characters in the message following the BodyLength<9> field up to, and including, the delimiter immediately preceding the CheckSum(10) tag (“10=”). The CheckSum(10) integrity check is calculated by summing the binary value of each character from the “8” of “8=“ up to and including the <SOH> character immediately preceding the CheckSum<10> tag field and comparing the least significant eight bits of the calculated value to the CheckSum(10) value (see “CheckSum Calculation” for a complete description).

Message Acknowledgment

The FIX session protocol is based on an optimistic model; normal delivery of data is assumed (i.e. no acknowledgment of individual messages) with errors in delivery identified by message sequence number gaps. Each message is identified by a unique sequence number. It is the receiving application's responsibility to monitor incoming sequence numbers to identify message gaps for response with resend request messages.

The FIX protocol does not support individual message acknowledgment. However, a number of application messages require explicit application level acceptance or rejection. See FIX Protocol specification for more details on FIX application messaging behavior.

Encryption

The use of SecureData(91) to encrypt FIX message has been deprecated in FIXT.1.1 The use of custom encryption is no longer recommended. Refer to the Information Security White Paper from the FIX Information Security Subcommittee.