<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 (e.g. resending an 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 (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) ( OnBehalfOfSendingTime (370) )
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 (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.

Used in all messages

Tag		Field Name	FIXML	Req'd	Comments
8		BeginString		Y	FIX.4.3 (Always unencrypted, must be first field in message)
9		BodyLength		Y	(Always unencrypted, must be second field in message)
35		MsgType	ApplicationMessage	Y	(Always unencrypted, must be third field in message)
49		SenderCompID	CompID	Y	(Always unencrypted)
56		TargetCompID	CompID	Y	(Always unencrypted)
115		OnBehalfOfCompID	CompID	N	Trading partner company ID used when sending messages via a third party (Can be embedded within encrypted data section.)
128		DeliverToCompID	CompID	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		Y	(Can be embedded within encrypted data section.)
50		SenderSubID	SubID	N	(Can be embedded within encrypted data section.)
142		SenderLocationID	LocationID	N	Sender's LocationID (i.e. geographic location and/or desk) (Can be embedded within encrypted data section.)
57		TargetSubID	SubID	N	"ADMIN" reserved for administrative messages not intended for a specific user. (Can be embedded within encrypted data section.)
143		TargetLocationID	LocationID	N	Trading partner LocationID (i.e. geographic location and/or desk) (Can be embedded within encrypted data section.)
116		OnBehalfOfSubID	SubID	N	Trading partner SubID used when delivering messages via a third party. (Can be embedded within encrypted data section.)
144		OnBehalfOfLocationID	LocationID	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	SubID	N	Trading partner SubID used when delivering messages via a third party. (Can be embedded within encrypted data section.)
145		DeliverToLocationID	LocationID	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	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	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	SendingTime	Y	(Can be embedded within encrypted data section.)
122		OrigSendingTime		N	Required for message resent as a result of a Resend Request (2) . 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 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.)
347		MessageEncoding	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.
370		OnBehalfOfSendingTime		N	(deprecated) Used when a message is sent via a "hub" or "service bureau". If A sends to Q (the hub) who then sends to B via a separate FIX session, then when Q sends to B the value of this field should represent the SendingTime (52) on the message A sent to Q. (always expressed in UTC (Universal Time Coordinated, also known as "GMT")
627		NoHops	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	HopCompID	C	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	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	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.

All material contained within the website is copyright of EPAM Systems, Inc. No material contained herein can be copied or otherwise used without the express permission of the copyright holder.