<Standard Message Header>

Each administrative or application message is preceded by a standard header. The header identifies the message type, length, destination, sequence number, origination point and time.

Two fields help with resending messages. The PossDupFlag (43) is set to Y when resending a message as the result of a session level event (i.e. the retransmission of a message reusing a sequence number). The PossResend (97) is set to Y when reissuing a message with a new sequence number (i.e. when resending a n order). The receiving application should process these messages as follows:

PossDupFlag - if a message with this sequence number has been previously received, ignore message, if not, process normally.

PossResend - forward message to application and determine if previously received (i.e. verify order id and parameters).

Message Routing Details - One Firm-to-One Firm (point-to-point)

The following table provides examples regarding the use of SenderCompID, TargetCompID, DeliverToCompID, and OnBehalfOfCompID (115) when using a single point-to-point FIX session between two firms. Assumption (A=sellside, B =buyside):

SenderCompID (49) OnBehalfOfCompID (115) TargetCompID (56) DeliverToCompID (128)
A to B directly A B
B to A directly B A

Message Routing Details - Third Party Message Routing

The FIX Session Protocol supports the ability for a single FIX session to represent multiple counterpaties. This can be in a 1-to-many, many-to-1, or 1-to-1 fashion. In addition, some third parties may be connected to other third parties effectively forming a "chain" of "hops" between the original message initiator and the final message receiver. The SenderCompID, OnBehalfOfCompID, TargetCompID, and DeliverToCompID (128) fields are used for routing purposes.

When a third party sends a message on behalf of another firm (using OnBehalfOfCompID), that third party may optionally add their details to the NoHops (627) repeating group. This repeating group builds a "history" of third parties through which the original message was re-transmitted. The NoHops (627) repeating group is NOT used to facilitate routing, rather it provides an audit trail of third party involvement to the receiver of a message. An audit trail of intermediary involvement may be a requirement of some regulatory bodies or counterparties. When a third party forwards a message on to the next hop (may be the end point or another third party), that third party can add its hop details to the NoHops (627) repeating group (i.e. its SenderCompID (49) as HopCompID, its SendingTime (52) as HopSendingTime, and the received messages MsgSeqNum (34) or some other reference as HopRefID).

Note that if OnBehalfOfCompID (115) or DeliverToCompID (128) message source identification/routing is used for a FIX session, then it must be used on all Application messages transmitted via that session accordingly (Reject the message if not).

The following table provides examples regarding the use of SenderCompID, TargetCompID, DeliverToCompID, and OnBehalfOfCompID (115) when using a single FIX session to represent multiple firms. Assumption (A=sellside, B and C=buyside, Q=third party):

SenderCompID (49) OnBehalfOfCompID (115) TargetCompID (56) DeliverToCompID (128) HopCompID (628) HopSendingTime (629)
Send from A to B via Q
1) A sends to Q A Q B
2) Q sends to B Q A B Q A's SendingTime
B responds to A via Q
1) B sends to Q B Q A
2) Q sends to A Q B A Q B's SendingTime
Send from A to B *AND* C via Q
1) A sends to Q A Q B
2) Q sends to B Q A B Q A's SendingTime
3) A sends to Q A Q C
4) Q sends to C Q A C Q A's SendingTime
B *AND* C send to A via Q
1) B sends to Q B Q A
2) Q sends to A Q B A Q B's SendingTime
3) C sends to Q C Q A
4) Q sends to A Q C A Q C's SendingTime

Note that some fields (e.g. ClOrdID on a New Order Single) must be unique for all orders on a given FIX session. Thus when using OnBehalfOfCompID (115) (or DeliverToCompID) addressing, a recommended approach is to prepend OnBehalfOfCompID (115) (or DeliverToCompID) to the original value. Thus if A sends Q ClOrdID value of "123", then Q could specify ClOrdID of "A-123" when sending the message to C to ensure uniqueness.

Used in all messages

Tag Field Name FIXML Req'd Comments
8 BeginString Y FIXT.1.1 (Always unencrypted, must be first field in message)
9 BodyLength Y (Always unencrypted, must be second field in message)
35 MsgType @MsgTyp Y (Always unencrypted, must be third field in message)
1128 ApplVerID @ApplVerID N Indicates application version using a service pack identifier. The ApplVerID (1128) applies to a specific message occurrence.
1156 ApplExtID N
1129 CstmApplVerID N Used to support bilaterally agreed custom functionality
49 SenderCompID @SID Y (Always unencrypted)
56 TargetCompID @TID Y (Always unencrypted)
115 OnBehalfOfCompID @OBID N Trading partner company ID used when sending messages via a third party (Can be embedded within encrypted data section.)
128 DeliverToCompID @D2ID N Trading partner company ID used when sending messages via a third party (Can be embedded within encrypted data section.)
90 SecureDataLen C Required to identify length of encrypted section of message. (Always unencrypted)
91 SecureData C Required when message body is encrypted. Always immediately follows SecureDataLen (90) field.
34 MsgSeqNum @SeqNum Y (Can be embedded within encrypted data section.)
50 SenderSubID @SSub N (Can be embedded within encrypted data section.)
142 SenderLocationID @SLoc N Sender's LocationID (i.e. geographic location and/or desk) (Can be embedded within encrypted data section.)
57 TargetSubID @TSub N "ADMIN" reserved for administrative messages not intended for a specific user. (Can be embedded within encrypted data section.)
143 TargetLocationID @TLoc N Trading partner LocationID (i.e. geographic location and/or desk) (Can be embedded within encrypted data section.)
116 OnBehalfOfSubID @OBSub N Trading partner SubID used when delivering messages via a third party. (Can be embedded within encrypted data section.)
144 OnBehalfOfLocationID @OBLoc N Trading partner LocationID (i.e. geographic location and/or desk) used when delivering messages via a third party. (Can be embedded within encrypted data section.)
129 DeliverToSubID @D2Sub N Trading partner SubID used when delivering messages via a third party. (Can be embedded within encrypted data section.)
145 DeliverToLocationID @D2Loc N Trading partner LocationID (i.e. geographic location and/or desk) used when delivering messages via a third party. (Can be embedded within encrypted data section.)
43 PossDupFlag @PosDup N Always required for retransmitted messages, whether prompted by the sending system or as the result of a resend request. (Can be embedded within encrypted data section.)
97 PossResend @PosRsnd N Required when message may be duplicate of another message sent under a different sequence number. (Can be embedded within encrypted data section.)
52 SendingTime @Snt Y (Can be embedded within encrypted data section.)
122 OrigSendingTime @OrigSnt N Required for message resent as a result of a ResendRequest. If data is not available set to same value as SendingTime (52) (Can be embedded within encrypted data section.)
212 XmlDataLen C Required when specifying XmlData (213) to identify the length of a XmlData (213) message block. (Can be embedded within encrypted data section.)
213 XmlData C Can contain a XML formatted message block (e.g. FIXML). Always immediately follows XmlDataLen (212) field. (Can be embedded within encrypted data section.) See Volume 1: FIXML Support
347 MessageEncoding @MsgEncd N Type of message encoding (non-ASCII characters) used in a message's "Encoded" fields. Required if any "Encoding" fields are used.
369 LastMsgSeqNumProcessed N The last MsgSeqNum (34) value received by the FIX engine and processed by downstream application, such as trading system or order routing system. Can be specified on every message sent. Useful for detecting a backlog with a counterparty.
627 NoHops Hop N
=> 628 HopCompID @ID C
=> 629 HopSendingTime @Snt N
=> 630 HopRefID @Ref N