|
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):
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):
Note that some fields (e.g. ClOrdID <11> on a New Order Single) 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.3 (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.
|
| 370 |
OnBehalfOfSendingTime(Deprecated) |
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 |
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> (49) of the third party.
|
| => |
629 |
HopSendingTime |
N |
Time that HopCompID <628> (628) sent the message. It is recommended that this value be the SendingTime <52> (52) of the message sent by the third party.
|
| => |
630 |
HopRefID |
N |
Reference identifier assigned by HopCompID <628> (628) associated with the message sent. It is recommended that this value be the MsgSeqNum <34> (34) of the message sent by the third party.
|
|
Used In |
