FIX 4.4 : StandardHeader

Structure | Used In

Description

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 (e.g. resending an order). The receiving application should process these messages as follows:

  • PossDupFlag <43> — if a message with this sequence number has been previously received, ignore message, if not, process normally.
  • PossResend <97> — 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 <49>, TargetCompID <56>, DeliverToCompID <128>, 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 <49>, OnBehalfOfCompID <115>, TargetCompID <56>, and DeliverToCompID <128> fields are used for routing purposes.

When a third party sends a message on behalf of another firm (using OnBehalfOfCompID <115>), 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 (e.g. its SenderCompID <49> as HopCompID <628>, its SendingTime <52> as HopSendingTime <629> , and the received message's MsgSeqNum <34> or some other reference as HopRefID <630> ).

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 <3> message if not).

The following table provides examples regarding the use of SenderCompID <49>, TargetCompID <56>, DeliverToCompID <128>, 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 <52>
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 <52>
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 <52>
3) A sends to Q A Q C
4) Q sends to C Q A C Q A's SendingTime <52>
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 <52>
3) C sends to Q C Q A
4) Q sends to A Q C A Q C's SendingTime <52>

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

Structure

Tag Field Name Req'd Comments
8 BeginString Y

FIX.4.4 (Always unencrypted, must be first field in message)

9 BodyLength Y

(Always unencrypted, must be second field in message)

35 MsgType Y

(Always unencrypted, must be third field in message)

49 SenderCompID Y

(Always unencrypted)

56 TargetCompID Y

(Always unencrypted)

115 OnBehalfOfCompID N

Trading partner company ID used when sending messages via a third party (Can be embedded within encrypted data section.)

128 DeliverToCompID N

Trading partner company ID used when sending messages via a third party (Can be embedded within encrypted data section.)

90 SecureDataLen N

Required to identify length of encrypted section of message. (Always unencrypted)

91 SecureData N

Required when message body is encrypted. Always immediately follows SecureDataLen <90> field.

34 MsgSeqNum Y

(Can be embedded within encrypted data section.)

50 SenderSubID N

(Can be embedded within encrypted data section.)

142 SenderLocationID N

Sender's LocationID <283> (i.e. geographic location and/or desk) (Can be embedded within encrypted data section.)

57 TargetSubID N

'ADMIN' reserved for administrative messages not intended for a specific user. (Can be embedded within encrypted data section.)

143 TargetLocationID N

Trading partner LocationID <283> (i.e. geographic location and/or desk) (Can be embedded within encrypted data section.)

116 OnBehalfOfSubID N

Trading partner SubID used when delivering messages via a third party. (Can be embedded within encrypted data section.)

144 OnBehalfOfLocationID N

Trading partner LocationID <283> (i.e. geographic location and/or desk) used when delivering messages via a third party. (Can be embedded within encrypted data section.)

129 DeliverToSubID N

Trading partner SubID used when delivering messages via a third party. (Can be embedded within encrypted data section.)

145 DeliverToLocationID N

Trading partner LocationID <283> (i.e. geographic location and/or desk) used when delivering messages via a third party. (Can be embedded within encrypted data section.)

43 PossDupFlag 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 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 Y

(Can be embedded within encrypted data section.)

122 OrigSendingTime 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 N

Required when specifying XmlData <213> to identify the length of a XmlData <213> message block. (Can be embedded within encrypted data section.)

213 XmlData N

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 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 N

Number of repeating groups of historical 'hop' information. Only applicable if OnBehalfOfCompID <115> is used, however, its use is optional. Note that some market regulations or counterparties may require tracking of message hops.

=> 628 HopCompID N

Third party firm which delivered a specific message either from the firm which originated the message or from another third party (if multiple 'hops' are performed). It is recommended that this value be the SenderCompID <49> of the third party.

=> 629 HopSendingTime N

Time that HopCompID <628> sent the message. It is recommended that this value be the SendingTime <52> of the message sent by the third party.

=> 630 HopRefID N

Reference identifier assigned by HopCompID <628> associated with the message sent. It is recommended that this value be the MsgSeqNum <34> of the message sent by the third party.

Used In