| ID | 1024 |
| Pedigree | Added FIX.2.7, Updated FIX.4.1-errata1 |
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 helps with resending messages. The PossDupFlag 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 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).
The following table provides examples regarding the use of SenderCompID, TargetCompID, DeliverToCompID, and OnBehalfOfCompID when using a single point-to-point FIX session between two firms. Assumption (A=sellside, B =buyside):
| SenderCompID | OnBehalfOfCompID | TargetCompID | DeliverToCompID | |
|---|---|---|---|---|
| A to B directly | A | B | ||
| B to A directly | B | A |
The following table provides examples regarding the use of SenderCompID, TargetCompID, DeliverToCompID, and OnBehalfOfCompID when using a single FIX session to represent multiple firms. Assumption (A=sellside, B and C=buyside, Q=third party):
| SenderCompID | OnBehalfOfCompID | TargetCompID | DeliverToCompID | ||
|---|---|---|---|---|---|
| Send from A to B via Q | |||||
| 1) | A sends to Q | A | Q | B | |
| 2) | Q sends to B | Q | A | B | |
| B responds to A via Q | |||||
| 1) | B sends to Q | B | Q | A | |
| 2) | Q sends to A | Q | B | A | |
| 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 | |
| 3) | A sends to Q | A | Q | C | |
| 4) | Q sends to C | Q | A | C | |
| B *AND* C send to A via Q | |||||
| 1) | B sends to Q | B | Q | A | |
| 2) | Q sends to A | Q | B | A | |
| 3) | C sends to Q | C | Q | A | |
| 4) | Q sends to A | Q | C | A |
Field | Name | Type | Req'd | Comments | Pedigree |
|---|---|---|---|---|---|
8 | Y | FIX.4.1 (Always unencrypted, must be first field in message) | Added FIX.2.7 Updated FIX.4.1 | ||
9 | Y | (Always unencrypted, must be second field in message) | Added FIX.2.7 Updated FIX.4.0 | ||
35 | Y | (Always unencrypted, must be third field in message) | Added FIX.2.7 Updated FIX.4.0 | ||
49 | Y | (Always unencrypted) | Added FIX.2.7 | ||
56 | Y | (Always unencrypted) | Added FIX.2.7 | ||
115 | Trading partner company ID used when sending messages via a third party (Can be embedded within encrypted data section.) | Added FIX.4.0 | |||
128 | Trading partner company ID used when sending messages via a third party (Can be embedded within encrypted data section.) | Added FIX.4.0 | |||
90 | Required to identify length of encrypted section of message. (Always unencrypted) | Added FIX.2.7 | |||
91 | Required when message body is encrypted. Always immediately follows SecureDataLen field. | Added FIX.2.7 | |||
34 | Y | (Can be embedded within encrypted data section.) | Added FIX.2.7 | ||
50 | (Can be embedded within encrypted data section.) | Added FIX.2.7 Updated FIX.3.0 | |||
142 | Trading partner LocationID (i.e. geographic location and/or desk) (Can be embedded within encrypted data section.) | Added FIX.4.1 | |||
57 | “ADMIN” reserved for administrative messages not intended for a specific user. (Can be embedded within encrypted data section.) | Added FIX.2.7 Updated FIX.3.0 | |||
143 | Trading partner LocationID (i.e. geographic location and/or desk) (Can be embedded within encrypted data section.) | Added FIX.4.1 | |||
116 | Trading partner SubID used when delivering messages via a third party. (Can be embedded within encrypted data section.) | Added FIX.4.0 | |||
144 | 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.) | Added FIX.4.1 | |||
129 | Trading partner SubID used when delivering messages via a third party. (Can be embedded within encrypted data section.) | Added FIX.4.0 | |||
145 | 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.) | Added FIX.4.1 | |||
43 | 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.) | Added FIX.2.7 Updated FIX.4.1 | |||
97 | Required when message may be duplicate of another message sent under a different sequence number. (Can be embedded within encrypted data section.) | Added FIX.2.7 | |||
52 | Y | (Can be embedded within encrypted data section.) | Added FIX.2.7 | ||
51 | Y | (Can be embedded within encrypted data section.) | Added FIX.2.7 Deprecated FIX.4.0 | ||
122 | Required for message resends. If data is not available set to same value as SendingTime (Can be embedded within encrypted data section.) | Added FIX.4.0 |
- Advertisement
- Allocation
- AllocationAck
- DontKnowTrade
- ExecutionReport
- Heartbeat
- IOI
- ListCancelRequest
- ListExecute
- ListStatus
- ListStatusRequest
- Logon
- Logout
- NewOrderList
- NewOrderSingle
- News
- OrderCancelReject
- OrderCancelReplaceRequest
- OrderCancelRequest
- OrderStatusRequest
- Quote
- QuoteRequest
- Reject
- ResendRequest
- SequenceReset
- SettlementInstructions
- TestRequest
Orchimate Copyright 2026 Atomic Wire Technology Limited
Orchestra Copyright 2026 FIX Protocol Ltd
Terms of Service|Privacy Policy