Taker FIX 4.4
Rules of Engagement
PrimeXM endeavours to ensure that the data and other material in this publication are correct and complete but does not accept liability for any error herein or omissions. The development of PrimeXM’s products and services is continuous and published information may not be up to date.
Change Log
FIX API 1.6.0
Version: 1.6.0
XCore: 6.01.73
Changes:
- Added ResendRequest max count limit is 30.
Notes:
- When the limit is exceeded, the taker is automatically disabled.
- To re-enable it, the taker must be manually disabled and enabled again.
FIX API 1.5.9
Version: 1.5.9
Connector: PrimeXM_FIX44_V2
Changes:
- Added support for MDUpdateType = FULL_REFRESH (tag 265=0)
- Added support for SecurityListRequest and SecurityList
Note:
- With PrimeXM_FIX44_V2, FULL_REFRESH support is introduced
FIX API 1.5.8
Version: 1.5.8
Changes:
- Added Tag 59 (Time In Force) to support pending orders
- Updated TTL logic: client TTL takes precedence over XCore Connector Account Settings
- Added Tag 7533 (Stream Name) in 35=W message for multi-stream connectors
- Added Tag 541 (FixingDate) in Execution Report for NDFs
FIX API 1.5.7
Version: 1.5.7
Changes:
- Removed SubscriptionRequestType Snapshot option (tag 263=0) from MarketDataRequest
- Added Market Data - Snapshot/Full Refresh message type (35=W)
- Added Tag 106 (Issuer) to Market Data - Snapshot/Full Refresh (35=W) and Mass Quote messages
FIX API 1.5.6
Version: 1.5.6
Changes:
- Removed support for GTC orders (tag 10000 can no longer be set to -1)
- Superseded in 1.5.8: GTC is available through Tag 59 (Time In Force), and ttl -1 is accepted (see New Order Single)
FIX API 1.5.5
Version: 1.5.5
Changes:
- Added examples for all message types
FIX API 1.5.4
Version: 1.5.4
Changes:
- Added new application message type: Order Status Request
FIX API 1.5.3
Version: 1.5.3
Changes:
- Added TTL field (tag 10000) support for pending orders by extending allowed TTL values
- Added Stop order type (tag 40=3) to New Order Single and Execution Report
- Added new application message type: Order Cancel Request
FIX API 1.5.2
Version: 1.5.2
Changes:
- Added OrderQty field (tag 38) to Market Data Request message
Introduction
- Scope of this document
This document is intended to serve software developers as an implementation guide for the PrimeXM FIX API.
- FIX version
PrimeXM supports FIX version 4.4. For further information about this version please refer to the specifications published by the FIX Protocol Organization under http://www.fixprotocol.org/specifications/FIX.4.4
- FIX sessions
For better separation of pricing and trading data, clients need to establish two separate FIX connections (with two separate login credentials) to the PrimeXM FIX Server, one for pricing and one for trading data.
Connectivity
- Connection type
Connection to PrimeXM’s FIX engine is available over the Internet, VPN tunnel or cross-connect to our data center facilities in UK (London), US (New York), and JP (Tokyo). Please contact us for further details.
- Hours of operations
Connectivity to PrimeXM’s FIX engine is available from FRI 17:05:30 till FRI 17:05:00 (America/New_York).
- Sequence number reset
There is a weekly sequence reset window on FRI 17:05:00 - 17:05:30 (America/New_York) on all connections (pricing and trading). Trading connections have to be configured to persist sequence numbers on logon (141=N). Pricing connections have to be configured to reset sequence numbers on logon (141=Y).
- Security and authentication
PrimeXM uses SSL to secure the FIX trading sessions. SSL is turned on if you set one particular flag to ON. As a result of SSL, a self-signed certificate should be used, there is no need to use a dedicated SSL certificate. The applications handle this among themselves. The following SSL versions are supported: TLS 1.2 and TLS 1.3.
Pricing sessions are not SSL encrypted in general. Once the connection to the PrimeXM FIX server is established the client has to authenticate against the server with a username and password added to the logon (MsgType=A) message.
Messages
-
As defined in the FIX protocol, the PrimeXM FIX server is using two different data levels: Session and Application. The Session level handles the delivery of data and the Application level defines the business-related data content. The following session and application messages are supported by the PrimeXM FIX Engine: Session messages:
- Heartbeat (Client ↔ PrimeXM)
- Test Request (Client ↔ PrimeXM)
- Logon (Client → PrimeXM)
- Logout (Client ↔ PrimeXM)
- Resend Request (Client ↔ PrimeXM)
- Reject (Client ↔ PrimeXM)
- Sequence Reset (Client ↔ PrimeXM)
Application messages:
- Market Data Request (Client → PrimeXM)
- Market Data Request Reject (Client ← PrimeXM)
- Mass Quote (Client ← PrimeXM)
- Mass Quote Acknowledgement (Client → PrimeXM)
- Market Data-Snapshot/Full Refresh (Client ← PrimeXM)
- Security List Request (Client → PrimeXM)
- Security List (Client ← PrimeXM)
- New Order Single (Client → PrimeXM)
- Order Cancel Request (Client → PrimeXM)
- Order Cancel Reject (Client ← PrimeXM)
- Order Status Request (Client → PrimeXM)
- Execution Report (Client ← PrimeXM)
- Position Report (Client ↔ PrimeXM)
Standard messages
Standard header
| Tag | Field name | Req’d | Comments |
|---|---|---|---|
| 8 | BeginString | Y | Identifies beginning of new message and protocol version (always first field in message) |
| 9 | BodyLength | Y | Message length (in bytes) forward to the CheckSum field (always second field in message) |
| 35 | MsgType | Y | Defines message type (always 3rd tag in message) |
| 49 | SenderCompID | Y | Assigned value used to identify the client sending messages (will be provided by PrimeXM) |
| 56 | TargetCompID | Y | Assigned value used to identify receiving party (will be provided by PrimeXM) |
| 34 | MsgSeqNum | Y | Integer message sequence number |
| 50 | SenderSubID | N | Optional. Assigned value used to identify specific message originator (desk, trader, etc.) (will be provided by PrimeXM if necessary) |
| 52 | SendingTime | Y | Message transmission time in UTC/GMT |
Standard trailer
| Tag | Field name | Req’d | Comments |
|---|---|---|---|
| 10 | Checksum | Y | Three digit character representing the checksum value of the message |
Session Messages
Heartbeat
| Tag | Field name | Req’d | Comments |
|---|---|---|---|
| Standard Header | Y | MsgType=0 | |
| 112 | TestReqID | N | Req’d when the heartbeat is the result of a Test Request message |
| Standard Trailer | Y |
Heartbeat Example
8=FIX.4.4 9=80 35=0 49=T01 56=XCxxx 34=23667 52=20151105-12:26:48.467 10=252
Test Request
| Tag | Field name | Req’d | Comments |
|---|---|---|---|
| Standard Header | Y | MsgType=1 | |
| 112 | TestReqID | Y | A unique identifier for this test message |
| Standard Trailer | Y |
Test Request Example
8=FIX.4.4 9=103 35=1 49=T01 56=XCxxx 34=23675 52=20151105-12:30:53.466 112=500041853466910000 10=132
Logon
| Tag | Field name | Req’d | Comments |
|---|---|---|---|
| Standard Header | Y | MsgType=A | |
| 98 | EncryptMethod | Y | Use of Encryption, set to “0” |
| 108 | HeartBtInt | Y | Heartbeat interval in seconds |
| 141 | ResetSeqNumFlag | N | Indicates both sides of a FIX session should reset sequence numbers |
| 553 | Username | Y | Username (provided by PrimeXM) |
| 554 | Password | Y | Password (provided by PrimeXM) |
| Standard Trailer | Y |
Logon Example
Request (Client → PrimeXM): 8=FIX.4.4 9=101 35=A 34=1 49=Q0XX 52=20150513-09:13:42.342 56=XCxxx 98=0 108=30 141=Y 553=name_q 554=password 10=108 Reply (Client ← PrimeXM): 8=FIX.4.4 9=91 35=A 34=3 49=Q0XX 52=20150513-09:13:42.343 56=XCxxx 98=0 108=30 10=117
Logon checks
- Username (553) and password (554) are checked against the
LoginUsernameandLoginPasswordsettings of the connector configuration. - After 10 rejected logon attempts, XCore disables the affected ConnectorConfig connection. Set that connection’s
activefield to1to reconnect.
Logout
| Tag | Field name | Req’d | Comments |
|---|---|---|---|
| Standard Header | Y | MsgType=5 | |
| 58 | Text | N | Reason for logout |
| Standard Trailer | Y |
Logout Example
Request (Client → PrimeXM): 8=FIX.4.4 9=51 35=5 34=148 49=Q0XX 52=20150513-09:13:42.343 56=XCxxx 10=224 Reply (Client ← PrimeXM): 8=FIX.4.4 9=50 35=5 34=53 49=Q0XX 52=20150513-09:13:42.344 56=XCxxx 10=170
Resend Request
| Tag | Field name | Req’d | Comments |
|---|---|---|---|
| Standard Header | Y | MsgType=2 | |
| 7 | BeginSeqNo | Y | |
| 16 | EndSeqNo | Y | |
| Standard Trailer | Y |
Resend Request Example
8=FIX.4.4 9=68 35=2 34=89279 49=T01 52=20151102-09:11:56.650 56=XCxxx 7=93784 16=0 10=002
Resend Request Limits
After receiving 30 Resend Requests in one FIX session, XCore disables the affected ConnectorConfig connection. Set that connection’s active field to 1 to reconnect. The counter resets at logon.
Reject
| Tag | Field name | Req’d | Comments |
|---|---|---|---|
| Standard Header | Y | MsgType=3 | |
| 45 | RefSeqNum | Y | MsgSeqNum of rejected message |
| 371 | RefTagID | N | The tag number of the FIX field being referenced |
| 372 | RefMsgType | N | The MsgType of the FIX message being referenced |
| 373 | SessionRejectReason | N | Code to identify reason for a session-level |
| Standard Trailer | Y |
Reject Request Example
in : 8=FIX.4.4 9=56 35=2 49=T01 56=XCxxx 34=11 52=20260923-09:31:55.036 7=1 10=112
out: 8=FIX.4.4 9=101 35=3 34=17 49=XCxxx 52=20260923-09:31:55.041 56=T01 45=11 58=Required tag missing 371=16 372=2 373=1 10=183
Sequence Reset
| Tag | Field name | Req’d | Comments |
|---|---|---|---|
| Standard Header | Y | MsgType=4 | |
| 123 | GapFillFlag | N | |
| 36 | NewSeqNo | Y | |
| Standard Trailer | Y |
Sequence Reset Example
8=FIX.4.4 9=97 35=4 34=93784 43=Y 49=XCxxx 52=20151102-09:11:50.760 56=T01 122=20151102-09:11:50 36=93786 123=Y 10=184
Sequence Reset Example Full
in : 8=FIX.4.4 9=113 35=A 34=89278 49=T01 52=20151102-09:11:56.588 56=XCxxx 98=0 108=10 141=N 553=primexm_client_t 554=Gpf8oep7FAKb 10=129
————————evt: Received logon
————————evt: Responding to Logon request
out: 8=FIX.4.4 9=67 35=A 34=93785 49=XCxxx 52=20151102-09:11:50.679 56=T01 98=0 108=10 10=208
in : 8=FIX.4.4 9=68 35=2 34=89279 49=T01 52=20151102-09:11:56.650 56=XCxxx 7=93784 16=0 10=002
————————evt: Received ResendRequest FROM: 93784 TO: infinity
out: 8=FIX.4.4 9=97 35=4 34=93784 43=Y 49=XCxxx 52=20151102-09:11:50.760 56=T01 122=20151102-09:11:50 36=93786 123=Y 10=184
————————evt: Sent SequenceReset TO: 93786
out: 8=FIX.4.4 9=55 35=0 34=93786 49=XCxxx 52=20151102-09:12:00.902 56=T01 10=151
in : 8=FIX.4.4 9=55 35=0 34=89280 49=T01 52=20151102-09:12:06.806 56=XCxxx 10=154
Application Messages
Market Data Request
| Tag | Field name | Req’d | Comments | |
|---|---|---|---|---|
| Standard header | Y | MsgType = V | ||
| 262 | MDReqID | Y | Unique request ID. This value will be reflected in tag 302 of the MassQuote message. | |
| 263 | SubscriptionRequestType | Y | 1 = Subscribe (Snapshot plus updates) 2 = Unsubscribe 0 is accepted but handled as 2 (Unsubscribe); any other value is rejected. |
|
| 265 | MDUpdateType | N | 0 = Full Refresh: In this mode, the system will stream MarketDataSnapshotFullRefresh messages (35=W). 1 = Incremental Refresh: In this mode, the system will stream MassQuote messages (35=i). The default setting is Incremental Refresh. When set to Full Refresh, the streamed depth is limited to 5. |
|
| 264 | MarketDepth | Y | Specifies the number of layers requested. The request is rejected when the tag is missing. 0 = full book >0 = number of layers The effective depth never exceeds the depth configured on the connector stream (at most 32) and is limited to 5 for MDUpdateType = Full Refresh. Connector-type limits can be lower; the lowest applicable limit governs. |
|
| 38 | OrderQty | N | Accepted but not used: XCore does not read this tag when processing the request. The number of layers streamed is controlled by MarketDepth (tag 264) together with the configured stream and connector-type caps. | |
| 7533 | StreamName | N | Used as a unique identifier for each stream when uniqueness cannot be determined by the instrument name (Tag 55). The value of Tag 7533 corresponds to the name of the connection stream. Example: Stream 1: 55=EUR/USD 7533=stream_test Stream 2: 55=EUR/USD 7533=stream_test2 Note: If Tag 7533 is omitted, the system finds the stream from the value of Tag 55; if the instrument is enabled on more than one active stream, the request is rejected. |
|
| 146 | NoRelatedSym | Y | Always set to 1; other values are rejected | |
| → | 55 | Symbol | Y | Name of the symbol |
| Standard Trailer | Y |
Market Data Request Example
Single Stream: 8=FIX.4.4 9=86 35=V 34=4 49=Q047 52=20150415-06:56:14.952 56=XCxxx 262=3 263=1 264=0 146=1 55=EUR/USD 10=008
Multiple Streams: 8=FIX.4.4 9=114 35=V 34=2 49=Q006 52=20151204-21:05:44.224 56=XCxxx 7533=stream_1 146=1 55=AUD/CAD 262=0 263=1 264=1 267=2 269=0 269=1 10=071 8=FIX.4.4 9=114 35=V 34=2 49=Q006 52=20151204-21:05:44.224 56=XCxxx 7533=stream_2 146=1 55=AUD/CAD 262=1 263=1 264=1 267=2 269=0 269=1 10=072
Market Data Request Reject
| Tag | Field name | Req’d | Comments |
|---|---|---|---|
| Standard Header | Y | MsgType=Y | |
| 262 | MDReqID | Y | ID of the market data request |
| 58 | Text | N | Reason for market data request being rejected |
| Standard Trailer | Y |
Market Data Request Reject Example
8=FIX.4.4 9=105 35=Y 34=1567 49=T01 52=20151105-13:08:06.797 56=XCxxx 58=invalid symbol: name=EURUSDX 262=0 10=081
Rejection reasons
The reason in tag 58 is one of tag 262 not set, tag 263 not set, tag 263 invalid, tag 264 not set, tag 264 invalid, tag 265 invalid, tag 146 not set, tag 146 invalid, tag 55 not set, invalid symbol: name=<symbol>, stream.setting not found: stream=<stream> symbol=<symbol>, getStream: ambiguous instrument: symbol=<symbol> instrument=<instrument> streams=<stream>/<stream> (tag 7533 omitted and the instrument is enabled on more than one active stream), getStream: stream not found: stream=<stream> symbol=<symbol> instrument=<instrument> or conflicting symbol: reqID=<id> symbol=<symbol> vs <symbol> (the MDReqID is already in use for another symbol).
Mass Quote
Sent to the client if MarketDataRequest.MDUpdateType is omitted or set to Incremental_Refresh.
| Tag | Field name | Req’d | Comments | ||
|---|---|---|---|---|---|
| Standard Header | Y | MsgType=i | |||
| 117 | QuoteID | N | If QuoteID is set the client has to respond immediately with a MassQuoteAcknowledgement reflecting this value in tag 117. While sending pricing updates, XCore requests acknowledgement at the configured Ping interval (1000 to 5000 milliseconds, default 5000); if the previous QuoteID has not been acknowledged when the next one is due, the quote stream of the session is paused until the acknowledgement arrives. |
||
| 296 | NoQuoteSets | Y | Number of Quote sets following | ||
| → | 302 | QuoteSetID | The MDReqID (tag 262 of the MarketDataRequest). Use this value to identify the symbol to which the data in this specific QuoteSet refers to. | ||
| → | 295 | NoQuoteEntries | Number of quote entries | ||
| → | → | 299 | QuoteEntryID | Y | Unique Market Data Identifier (0 <= x < depth). The current QuoteSet data replaces prior QuoteSet data received under the same QuoteEntryID Note: Tag 299 is only a key denoting the individual stream and is used to replace the most up-to-date information in that stream. It does not denote the position of the price update in the book. |
| → | → | 106 | Issuer | N | Name/ID of security issuer Note: This tag is populated only when the connector configuration setting ProviderID is Y and the pricing/streaming mode on the connector stream settings is set to aggregate.Tag 106 updated accordingly only when bid (188) or ask (190) price are updated. The tag 106 represents always Ask provider and will represent the Bid provider in case only the Bid price is updated. The volumes tags (134/135) do not affect any update on the tag 106. Examples of how specific tags updates affect tag 106 result In case bid price (188) updated only then tag 106 is populated with update bid provider. In case ask price (190) updated only then tag 106 is populated with update ask provider. In case both bid price (188) and ask price (190) are updated then the tag 106 is populated with update ask provider. In case bid size (134) updated only then tag 106 remains same and it’s not updated. In case ask size (135) updated only then tag 106 remains same and it’s not updated. In case both bid size (134) and ask size (135) are updated only then tag 106 remains same and it’s not updated. In case bid size (134) and bid price (188) updated only then the tag 106 is populated with update bid provider. In case ask size (135) and ask price (190) updated only then the tag 106 is populated with update ask provider. In case both bid size (134) and ask size (135) as well both bid price (188) and ask price (190) are updated the tag 106 is populated with updated ask provider. |
| → | → | 134 | BidSize | N | Maximum bid size. Not set = no changes. -1 = quote cancel |
| → | → | 135 | OfferSize | N | Maximum offer size. Not set= no changes. -1 = quote cancel |
| → | → | 188 | BidSpotRate | N | Spot bid rate. Not set = no changes |
| → | → | 190 | OfferSpotRate | N | Spot ask rate. Not set = no changes |
| Standard Trailer | Y |
Mass Quote Example
8=FIX.4.4 9=266 35=i 34=1113826 49=XCT 52=20171106-14:57:08.528 56=Q001 296=5 302=32 295=1 299=0 106=1 134=1250000 188=1.80699 190=1.80709 302=35 295=1 299=0 106=1 190=148.051 302=40 295=1 299=0 106=1 190=1.30712 302=37 295=1 299=0 106=1 190=1.95713 302=34 295=1 299=0 135=500000 10=245
Mass Quote Acknowledgement
| Tag | Field name | Req’d | Comments |
|---|---|---|---|
| Standard Header | Y | MsgType=b | |
| 117 | QuoteID | Y | QuoteID copy from MassQuote/FullRefresh message |
| Standard Trailer | Y |
Mass Quote Acknowledgement Example
Acknowledgement Request (Client ← PrimeXM): 8=FIX.4.4 9=116 35=i 34=2 49=PXMD 52=20150415-06:56:07.387 56=Q047 117=1 296=1 302=1 295=1 299=0 106=1 134=0 135=0 188=0.76036 190=0.7605 10=004
Acknowledgement Reply (Client → PrimeXM): 8=FIX.4.4 9=58 35=b 34=10 49=Q047 52=20150415-06:56:15.001 56=PXMD 117=1 10=098
Acknowledgement Request (Client ← PrimeXM): 8=FIX.4.4 9=159 35=W 34=2691 49=PXMD 52=20251229-15:25:52.231 56=Q047 55=EUR/USD 117=1 262=EUR/USD_0 268=2 269=0 270=0.99988 271=1000000.0 269=1 270=0.9999 271=1000000.0 10=217
Acknowledgement Reply (Client → PrimeXM): 8=FIX.4.4 9=64 35=b 34=499 49=Q047 52=20251229-15:25:52.485 56=PXMD 117=1 10=203
Market Data-Snapshot/Full Refresh
The behavior of this message varies based on the value set for MarketDataRequest.MDUpdateType:
- Full Refresh: The MarketDataSnapshotFullRefresh message provides market data to the client.
- Incremental Refresh: Roughly every five minutes, following the release of a Massquote message for a given symbol, a FullRefresh message is sent out. This message provides an accurate snapshot of the client’s book after the previous Massquote has been processed. It aids in verifying the client’s adherence to the Massquote protocol. Moreover, the FullRefresh message serves as a practical point for reconstructing the entire book from the FIX logs, eliminating the need to sift through all Massquote messages since the last subscription. However, unless for these specific purposes, the FullRefresh can be safely disregarded by the client’s FIX engine.
| Tag | Field name | Req’d | Comments | |
|---|---|---|---|---|
| Standard Header | Y | MsgType=W | ||
| 55 | Symbol | Y | Subscribed symbol | |
| 262 | MDReqID | Y | ID of the market data request | |
| 117 | QuoteID | N | If QuoteID is set the client has to respond immediately with a MassQuoteAcknowledgement reflecting this value in tag 117 | |
| 7533 | StreamName | N | The name of the Connector Stream Note: Populated on the Full Refresh messages of an Incremental Refresh subscription when the Market Data Request carried tag 7533, echoing that value. It is not populated on the messages of a Full Refresh subscription. |
|
| 268 | NoMDEntries | Y | Specifies the number of entries in the Market Data message. A value of NoMDEntries = 0 indicates that there are no entries, i.e., the book is empty. | |
| → | 269 | MDEntryType | Y | Type of market data entry 0 = Bid 1 = Ask |
| → | 270 | MDEntryPx | Y | Price of the market data entry |
| → | 271 | MDEntrySize | Y | Quantity of the market data entry |
| → | 299 | QuoteEntryID | C | Mandatory if MarketDataRequest.MDUpdateType = Incremental Refresh. Unique Market Data Identifier (0 <= x < depth). Note: Tag 299 is only a key denoting the individual stream and is used to replace the most up-to-date information in that stream. It does not denote the position of the price update in the book. |
| → | 106 | Issuer | N | Provider ID; populated only when the connector configuration setting ProviderID is Y |
| Standard Trailer | Y |
Market Data-Snapshot/Full Refresh Example
8=FIX.4.4 9=173 35=W 34=136232 49=XCT1 52=20200603-12:00:00.106 56=Q004 55=EUR/USD 262=10 7533=stream1 268=2 269=0 270=1.11941 271=1000000 299=0 106=7 269=1 270=1.11944 271=1000000 299=0 106=7 10=060
Note: For Incremental Refresh subscriptions, XCore sends periodic Full Refresh snapshots at five-minute intervals while processing pricing updates, unless NoFullRefresh is Y. This setting does not suppress responses to Full Refresh subscriptions.
Pricing Session Example FULL
in : 8=FIX.4.4 9=125 35=A 34=1 49=Q01 52=20151109-20:20:33.208 56=XCxxx 98=0 108=20 141=Y 553=client 554=password 10=244
out: 8=FIX.4.4 9=94 35=A 34=1 49=XCxxx 52=20151109-20:20:33.219 56=Q01 98=0 108=20 141=Y 10=178
in : 8=FIX.4.4 9=118 35=V 34=2 49=Q01 52=20151109-20:20:33.231 56=XCxxx 262=3 263=1 264=0 146=1 55=GBP/USD 15=GBP 10=236
in : 8=FIX.4.4 9=118 35=V 34=3 49=Q01 52=20151109-20:20:33.232 56=XCxxx 262=5 263=1 264=0 146=1 55=EUR/USD 15=EUR 10=022
in : 8=FIX.4.4 9=118 35=V 34=4 49=Q01 52=20151109-20:20:33.232 56=XCxxx 262=7 263=1 264=0 146=1 55=USD/SGD 15=USD 10=011
in : 8=FIX.4.4 9=119 35=V 34=5 49=Q01 52=20151109-20:20:33.232 56=XCxxx 262=10 263=1 264=0 146=1 55=USD/TRY 15=USD 10=088
out: 8=FIX.4.4 9=264 35=i 34=2 49=XCxxx 52=20151109-20:20:33.240 56=Q01 117=1 296=1 302=3 295=4 299=0 106=1 134=1000000 135=1000000 188=1.51218 190=1.51223 299=1 134=500000 135=50000 188=1.51218 190=1.51223 299=2 135=500000 190=1.51225 299=3 135=2000000 190=1.51226 10=203
in : 8=FIX.4.4 9=83 35=b 34=27 49=Q01 52=20151109-20:20:33.244 56=XCxxx 117=1 10=202
in : 8=FIX.4.4 9=120 35=V 34=13 49=Q01 52=20151109-20:20:33.253 56=XCxxx 262=121 263=1 263=1 264=0 146=1 55=AED/USD 15=AED 10=099
out: 8=FIX.4.4 9=104 35=Y 34=6 49=XCxxx 52=20151109-20:20:33.253 56=Q01 58=invalid symbol: name=EURUSDX 262=121 10=010
out: 8=FIX.4.4 9=436 35=i 34=7 49=XCxxx 52=20151109-20:20:33.253 56=Q01 296=2 302=43 295=4 299=0 106=1 134=1000000 135=50000 188=186.129 190=186.14 299=1 106=1 134=500000 135=1000000 188=186.127 190=186.141 299=2 135=500000 190=186.141 299=3 135=3000000 190=186.143 302=47 295=4 299=0 106=1 134=500000 135=1000000 188=0.70516 190=0.70517 299=1 106=1 134=1000000 135=2000000 188=0.70514 190=0.70518 299=2 106=1 134=50000 188=0.70514 299=3 106=1 134=2000000 188=0.70513 10=109
Security List Request
| Tag | Field name | Req’d | Comments |
|---|---|---|---|
| Standard Header | Y | MsgType=x | |
| 320 | SecurityReqID | Y | Unique request ID, echoed in tags 320 and 322 of the Security List |
| Standard Trailer | Y |
Security List
| Tag | Field name | Req’d | Comments | |
|---|---|---|---|---|
| Standard Header | Y | MsgType=y | ||
| 320 | SecurityReqID | Y | ID of the request | |
| 322 | SecurityResponseID | Y | Same value as tag 320 | |
| 560 | SecurityRequestResult | Y | Always 0 (valid request) | |
| 146 | NoRelatedSym | Y | Number of instruments | |
| → | 55 | Symbol | Y | Instrument name of every symbol enabled on the connector streams |
| Standard Trailer | Y |
New Order Single
| Tag | Field name | Req’d | Comments |
|---|---|---|---|
| Standard Header | Y | MsgType=D | |
| 11 | ClOrdID | Y | Must be a unique identifier sent by the client. Used for response Note: The special character colon : is not accepted by the system |
| 1 | Account | N | Specifies the trading account (connector_account.name) for execution. It is required only when the connector is configured with multiple trading accounts. For connectors configured with a single trading account, execution automatically defaults to that account, irrespective of the value provided in tag 1. If ConnectorRoute rules are configured, a matching route selects the account first and overrides tag 1. |
| 55 | Symbol | Y | Symbol to trade on |
| 15 | Currency | N | The system currently supports trading exclusively in the base currency of a symbol, meaning both the side and size of trades refer to the base currency. The specified tag is intended as a safety feature, ensuring trades are rejected if there is an attempt to trade on the quote currency instead. Consequently, if Currency is set to the quote currency for symbols in securities of type FX and NDF, the NewOrderSingle message will be rejected. It is generally recommended to omit this tag to avoid unintended trade rejections. |
| 54 | Side | Y | Side of order in reference to tag 15: 1 = Buy 2 = Sell |
| 38 | OrderQty | Y | The order amount in reference to tag 15 |
| 40 | OrdType | Y | Type of order: 1 = Market 2 = Limit 3 = Stop |
| 44 | Price | C | Conditional if tag 40=1, required if tag 40=2 or tag 40=3 |
| 60 | TransactTime | Y | Timestamp of the order request in the format yyyyMMdd-HH:mm:ss.SSS (UTC). Orders whose TransactTime is more than 5 seconds in the past are rejected with the text tag 60: time difference exceeds 5000ms. |
| 43 | PossDupFlag | N | Orders flagged as possible duplicates (43=Y) are rejected with the text rejecting possible resend. |
| 110 | MinQty | N | Minimum accepted fill size. Defaults to 0.0 0.0 <= x <= OrderQty If MinQty = OrderQty (tag #38) then the trade will either be fully filled or rejected. If MinQty is set to x, with 0.0 < x < OrderQty, then the trade can be partially filled in multiple deals, each deal not smaller than x. Note: if 59 = FOK then MinQty = OrderQty |
| 10000 | ttl | N | Time in milliseconds available for new execution attempts. After the deadline, XCore stops initiating new requests; outstanding maker responses can still arrive. The valid values for ttl are: >= 0 : ttl value in ms -1 : ttl set to 2,147,483,647 ms (about 24.85 days); an earlier XCore restart also cancels the order Note: if 59 = GTC then ttl = -1 Note: Where Tag 10000 is not specified, ttl will be taken as the ttl defined in the Connector Account Setting |
| 10001 | deviation | N | Double value: a price difference, not points. A negative value is read as its absolute value (-1 becomes a deviation of 1.0, not unlimited). For Limit orders (40=2): the permissible deviation from the price in tag 44; 0.0 when the tag is omitted. For Market orders (40=1): the permissible deviation at execution from the current top of book (ToB) price in the liquidity_pool; unlimited when the tag is omitted. If no quote is within the deviation, the order expires at the end of its ttl. For Stop orders (40=3): the value is stored with the order but does not limit the execution. |
| 59 | TimeInForce | N | Valid values: 1 = Good Till Cancel (GTC) 3 = Immediate Or Cancel (IOC): accepted but has no effect of its own; the execution window comes from tag 10000 or, when omitted, from the Connector Account ttl. 4 = Fill Or Kill (FOK) Note: For FIX connectors GTC orders will be automatically cancelled at XCore restart. Note: Values 1 and 4 take precedence over tags 10000 and 110. |
| 115 | OnBehalfOfCompID | N | String value. This attribute can be used to pass on additional information which will be stored in the order.subID1. |
| 116 | OnBehalfOfSubID | N | String value. This attribute can be used to pass on additional information which will be stored in the order.subID2. |
| 526 | SecondaryClOrdID | N | String value. This attribute can be used to pass on additional information which will be stored in the order.subID3. |
| 527 | SecondaryExecID | N | String value. This attribute can be used to pass on additional information which will be stored in the order.subID4. |
| Standard Trailer | Y |
New Order Single Example
8=FIX.4.4 9=148 35=D 34=11 49=T014 56=XCT1 52=20200602-13:29:25.255 11=1 1=test 55=EUR/USD 54=1 38=1000 40=2 44=1.0 60=20200602-13:29:25.000 59=3 10000=100 110=500 10=024
Order Cancel Request
| Tag | Field name | Req’d | Comments |
|---|---|---|---|
| Standard Header | Y | MsgType=F | |
| 41 | OrigClOrdID | N | ClOrdID of the New Order Single to cancel. When present it takes precedence over tag 11. |
| 11 | ClOrdID | C | ClOrdID of the New Order Single to cancel, used when tag 41 is absent. Requests with neither tag are answered with an Order Cancel Reject (MsgType=9) carrying the reason in tag 58. |
Order Cancel Request Example
8=FIX.4.4 9=67 35=F 34=10987 49=T003 52=20151029-11:16:50.014 56=XCxxx 11=2025301 10=233
Order Status Request
| Tag | Field name | Req’d | Comments |
|---|---|---|---|
| Standard Header | Y | MsgType=H | |
| 11 | ClOrdID | Y | Must be unique identifier sent by the client, the same as the value of tag 11 in the New Order Single message originally sent by the client |
Order Status Request Trade Scenario
1) A client sends an NewOrderSingle with ClOrdID=xyz to the XCore.
2) Connectivity of the clients FIX engine to the XCore is lost before receiving any ExecutionReports with ClOrdID=xyz
3) The clients FIX engine re-establishes connectivity to the XCore.
4) The XCore (re) sends any outgoing messages which the client did not receive yet.
5) The client is now fully connected and synchronized but did still not receive any ExecutionReports with ClOrdID=xyz
6) The client sends an OrderStatusRequest with ClOrdID=xyz
7) The XCore responds to the OrderStatusRequest with ClOrdID=xyz and
- a) OrderStatus=NEW: The order is currently open in the XCore.
- b) OrderStatus=REJECT: The order is currently not open in the XCore.
Order Status Request Example
in : 8=FIX.4.4 9=64 35=H 49=T01 56=XCxxx 34=13 52=20260923-09:27:52.693 11=ORD-1004 10=099
out: 8=FIX.4.4 9=85 35=8 34=21 49=XCxxx 52=20260923-09:27:52.695 56=T01 11=ORD-1004 17=0 37=0 39=0 150=I 10=252
Execution Report
| Tag | Field name | Req’d | Comments |
|---|---|---|---|
| Standard Header | Y | MsgType=8 | |
| 11 | ClOrdID | Y | Must be unique identifier sent by the client. Used for response |
| 17 | ExecID | C | Unique identifier of execution message. Note: If ExecType in tag 150 = F and OrdStatus in tag 39 = 1 or 2, this tag will be populated. For fills the value is the XCore deal reference (order, leg and deal IDs separated by underscores); when the connector configuration setting ProviderID is Y, the name of the Liquidity Provider is appended after a | separator. With the connector setting NO_DEALS (or FOK_NO_DEALS for FOK orders) set to Y, one fill report per order is sent and ExecID is the XCore order ID. Other reports carry 17=0. |
| 150 | ExecType | Y | The execution report’s type. 0 = New 4 = Canceled 8 = Rejected F = Trade I = Order Status |
| 55 | Symbol | C | Name of the Symbol. Note: If ExecType in tag 150 = I, this tag will not be populated |
| 54 | Side | C | Side of order. 1 = Buy 2 = Sell Note: If ExecType in tag 150 = I, this tag will not be populated |
| 38 | OrderQty | C | Quantity ordered. Note: If ExecType in tag 150 = I, this tag will not be populated |
| 110 | MinQty | C | Minimum quantity ordered. Note: If ExecType in tag 150 = F, this tag will be populated |
| 40 | OrdType | C | Type of the Order. 1 = Market 2 = Limit 3 = Stop Note: If ExecType in tag 150 = I, this tag will not be populated |
| 15 | Currency | C | Dealt currency Note: Populated on New, Trade and Canceled reports; not on Order Status replies (150=I), nor on rejects of orders sent without tag 15. |
| 44 | Price | C | Requested price Note: If ExecType in tag 150 = F, this tag will be populated (in case it was provided by the client in the order request) Market orders sent without a price carry 44=0. |
| 37 | OrderID | C | PrimeXM XCore order ID Note: If ExecType in tag 150 = F, this tag will be populated |
| 39 | OrdStatus | Y | Current order state. 0 = New 1 = Partially filled 2 = Filled 4 = Canceled 8 = Rejected In the case of replies to New Order Single messages, an Execution Report message with OrdStatus “New” (39 = 0) will always be followed by another order state. OrdStatus “Partially filled” will be followed by either “Filled” or “Canceled”. “Filled”, “Canceled” and “Rejected” are final order states. In the case of replies to Order Status Request messages, the Execution Report message (will have type ExecType = I) will reply with OrdStatus “New” (39 = 0) if the requested order is currently being processed. If the order is not currently being processed by the system, the Execution Report message will reply with OrdStatus “Rejected” (39 = 8). |
| 32 | LastQty | C | Quantity of this fill. Note: If ExecType in tag 150 = F and OrdStatus in tag 39 = 1 or 2, this tag will be populated |
| 31 | LastPx | C | Price of this fill. Note: If ExecType in tag 150 = F and OrdStatus in tag 39 = 1 or 2, this tag will be populated |
| 151 | LeavesQty | C | Remaining quantity open for execution Note: If ExecType in tag 150 = I, this tag will not be populated |
| 14 | CumQty | C | Cumulative quantity executed Note: If ExecType in tag 150 = I, this tag will not be populated |
| 6 | AvgPx | C | Average price of executed quantity Note: If ExecType in tag 150 = F and OrdStatus in tag 39 = 1 or 2, this tag will be populated |
| 64 | SettlDate | C | ValueDate of execution. Note: If ExecType in tag 150 = F and OrdStatus in tag 39 = 1 or 2, this tag will be populated |
| 58 | Text | N | Free format text string |
| 60 | TransactTime | C | Time the transaction represented by this ExecutionReport occurred Note: If ExecType in tag 150 = F, this tag will be populated |
| 541 | FixingDate | N | Fixing Date for NDFs. Format: YYYYMMDD. |
| Standard Trailer | Y |
Execution Report Example
8=FIX.4.4 9=222 35=8 34=15 49=XCxxx 52=20260923-09:31:49.686 56=T01 6=1.1 11=ORD-1001 14=1000.0 15=EUR 17=183_0_0 31=1.1 32=1000.0 37=183 38=1000.0 39=2 40=2 44=1.1004 54=1 55=EURUSD 60=20260923-09:31:49.686 64=20260925 110=0 150=F 151=0 10=083
Full Order Execution Example
Filled order:
in : 8=FIX.4.4 9=133 35=D 49=T01 56=XCxxx 34=8 52=20260923-09:31:49.684 11=ORD-1001 1=DEMO 55=EURUSD 54=1 38=1000 40=2 44=1.1004 60=20260923-09:31:49.000 10=039
out: 8=FIX.4.4 9=183 35=8 34=14 49=XCxxx 52=20260923-09:31:49.685 56=T01 11=ORD-1001 14=0.0 15=EUR 17=0 37=183 38=1000.0 39=0 40=2 44=1.1004 54=1 55=EURUSD 60=20260923-09:31:49.684 110=0 150=0 151=1000.0 10=215
out: 8=FIX.4.4 9=222 35=8 34=15 49=XCxxx 52=20260923-09:31:49.686 56=T01 6=1.1 11=ORD-1001 14=1000.0 15=EUR 17=183_0_0 31=1.1 32=1000.0 37=183 38=1000.0 39=2 40=2 44=1.1004 54=1 55=EURUSD 60=20260923-09:31:49.686 64=20260925 110=0 150=F 151=0 10=083
Rejected order:
in : 8=FIX.4.4 9=125 35=D 49=T01 56=XCxxx 34=10 52=20260923-09:31:53.370 11=ORD-1002 1=DEMO 55=EURUSDX 54=1 38=1000 40=1 60=20260923-09:31:53.000 10=205
out: 8=FIX.4.4 9=177 35=8 34=16 49=XCxxx 52=20260923-09:31:53.371 56=T01 11=ORD-1002 14=0.0 17=0 37=0 38=1000 39=8 40=1 54=1 55=EURUSDX 58=REJECT: symbol not found: instrument=EURUSDX 150=8 151=0.0 10=192
Partial fill:
in : 8=FIX.4.4 9=135 35=D 49=T01 56=XCxxx 34=2 52=20260923-09:32:17.787 11=ORD-1003 1=DEMO 55=EURUSD 54=2 38=800000 40=2 44=1.0999 60=20260923-09:32:17.000 10=159
out: 8=FIX.4.4 9=186 35=8 34=4 49=XCxxx 52=20260923-09:32:17.788 56=T01 11=ORD-1003 14=0.0 15=EUR 17=0 37=186 38=800000.0 39=0 40=2 44=1.0999 54=2 55=EURUSD 60=20260923-09:32:17.788 110=0 150=0 151=800000.0 10=148
out: 8=FIX.4.4 9=234 35=8 34=5 49=XCxxx 52=20260923-09:32:17.788 56=T01 6=1.1 11=ORD-1003 14=500000.0 15=EUR 17=186_0_0 31=1.1 32=500000.0 37=186 38=800000.0 39=1 40=2 44=1.0999 54=2 55=EURUSD 60=20260923-09:32:17.788 64=20260925 110=0 150=F 151=300000.0 10=193
out: 8=FIX.4.4 9=234 35=8 34=6 49=XCxxx 52=20260923-09:32:17.788 56=T01 6=1.09996 11=ORD-1003 14=800000.0 15=EUR 17=186_1_0 31=1.0999 32=300000.0 37=186 38=800000.0 39=2 40=2 44=1.0999 54=2 55=EURUSD 60=20260923-09:32:17.788 64=20260925 110=0 150=F 151=0 10=254
Position Report (request)
| Tag | Field name | Req’d | Comments |
|---|---|---|---|
| Standard Header | Y | MsgType=AP | |
| 710 | PosReqID | Y | Unique identifier for the Request for Positions associated with this report. |
| 1 | Account | Y | The account. |
| 263 | SubscriptionRequestType | N | 0 = Snapshot 1 = Subscribe (Snapshot plus updates) 2 = Unsubscribe Defaults to 0 (Snapshot) when omitted. |
| 9001 | AccountNotificationType | N | 0 = Real-time updates on deposits and withdrawals. 1 = In addition to the above, periodic updates every 5 seconds if calculated values, such as free margin, change. The default value is 0. |
| 9002 | PositionNotificationType | N | 0 = Real-time updates on position changes. 1 = In addition to the above, periodic updates every 5 seconds if calculated values, such as open P&L, change. The default value is 0. |
| Standard Trailer | Y |
Position Report Request Example
8=FIX.4.4 9=85 35=AP 34=2 49=taker_t 52=20250707-10:02:38.475 56=taker 1=account_margin 263=0 710=1 10=138
Position Report (response)
| Tag | Field name | Req’d | Comments | |
|---|---|---|---|---|
| Standard Header | Y | MsgType=AP | ||
| 710 | PosReqID | Y | Identical to tag 710 provided in the Position Report request | |
| 1 | Account | Y | Identical to tag 1 provided in the Position Report request | |
| 721 | PosMaintRptID | Y | Combination of account name and the account’s latest sequence ID. | |
| 5001 | Balance | Y | This represents the accumulated operations conducted on the account including deposits, withdrawals, settlements, commissions, swaps and so on | |
| 5002 | Equity | Y | The current equity of the account which includes the unrealized PnL Equity = Balance + running PnL |
|
| 5003 | Exposure | Y | The total, live exposure of all open positions on the XCore account converted to the account currency. Current Exposure = Σ (Base of account position * spot conversion rate) |
|
| 5004 | Margin Used | Y | The Sum of Margins reserved by open trades. | |
| 5005 | Margin Limit | Y | The account group's margin reference: the Balance when the group's EXPOSURE is BALANCE, the Equity when EQUITY; -1 when no margin check applies. | |
| 702 | NoPositions | Y | Number of position entries that follow; tags 5010–5015 repeat for each entry. | |
| → | 5010 | Position Sequence | Unique position record identifier. | |
| → | 5011 | Symbol | Symbol name in XCore. | |
| → | 5012 | Base | The position's base amount. | |
| → | 5013 | Quote | Volume exposure in quote currency. | |
| → | 5014 | Total PnL | Net profit or loss from both realized (closed) and unrealized (open) positions. Expressed in Quote currency. | |
| → | 5015 | Closed PnL | Net profit or loss from closed (realized) position, following FIFO principle. Expressed in Quote currency. | |
| Standard Trailer | Y |
Position Report Response Example
8=FIX.4.4 9=301 35=AP 34=2 49=taker 52=20250707-10:02:38.346 56=taker_t 1=account_margin 710=1 721=account_margin_59 5001=0 5002=-844.3503167999952 5003=40240.954020000005 5004=40240.954020000005 5005=-1 702=1 5010=59 5011=EURUSD 5012=39402.12 5013=-40240.954020000005 5014=-844.3503167999952 5015=-631.2509600000001 10=082
Position Report (reject)
| Tag | Field name | Req’d | Comments |
|---|---|---|---|
| Standard Header | Y | MsgType=AP | |
| 710 | PosReqID | Y | Identical to tag 710 provided in the Position Report request |
| 728 | PosReqResult | Y | Result code: 1 = tag 710 missing or tag 263 invalid, 2 = tag 1 (account) missing, 3 = request refused by the account manager (for example access denied: account=<name>), 99 = invalid tag 9001 or 9002, or a processing error. |
| 58 | Text | Y | Reject reason. |
| Standard Trailer | Y |
Data Dictionary
- Download the data dictionary from here.
Support and FAQs
- For support or questions about the PrimeXM FIX Engine, please contact us via email to support@primexm.com. Please always visit our website primexm.com, for the most up to date contact information.
PrimeXM Taker - Test and Conformance Process
In order to be able to connect to PrimeXM as a Taker in the system, it’s required to proceed with a conformance test in order to check and verify accordingly that all the messages are correct for the connectivity, pricing and order process.
Below you can find a spreadsheet with simple conformance test to be carried by Taker and PrimeXM.