This document describes the Integral FIX Maker RFS API, a FIX-based channel that allows makers to respond to customer requests with quotes and execute trades through Integral.
The following sections discuss the configuration of the API, and the trading workflows and messages that the API supports:
- FIX solution: FIX implementation, business rules, and overviews of messages and workflows
- Administrative messages: messages used to control the FIX session and manage message conversations
- Workflows: business workflows and message conversations described
- Application messages: trading message structure and data
- Examples: message examples
- Changes: corrections and enhancements made to the content of this document
The interface defined by the API conforms to the FIX 4.3 specifications. The FIX Protocol Organization provides a complete reference to the protocol at:
Each FIX Maker RFS API message is comprised of message fields defined in this document. Each field has its own set of attributes including:
- Tag: field number.
- Field name: human-readable name for reference.
- Req’d: indicates if the field must be sent on the FIX message:
- Y = required by the FIX protocol.
- Y(API) = required by the FIX Maker RFS API implementation.
- N = optional for both the FIX Maker RFS API and the FIX protocol.
- C = conditional. Refer to the field’s description to determine applicability.
- Valid values: specific values accepted for this field.
- Description: brief description of the field.
- Type(length): FIX data type of the field and the maximum length of the field value.
- →: arrow indicates a field in a repeating group.
The API supports the following FIX messages types:
Supported message types
| Message type | Message name | Inbound to Maker (I), Outbound from Maker (O), or Bidirectional (B) |
|---|---|---|
| Session management messages | ||
| A | Logon | B |
| 5 | Logout | B |
| 0 (zero) | Heartbeat | B |
| 1 | Test Request | B |
| 2 | Resend Request | B |
| 3 | Session-Level Reject | B |
| 4 | Sequence Reset | B |
| Trading messages | ||
| g | Trading Session Status Request | I |
| h | Trading Session Status | O |
| R | Quote Request | I |
| AG | Quote Request Reject | O |
| S | Quote | O |
| Z | Quote Cancel | O |
| D | New Order – Single | I |
| H | Order Status Request | I |
| F | Order Cancel Request | I |
| OT | Order Timeout | I |
| Q | Don’t Know Trade | I |
| 8 | Execution Report | O |
| j | Business Message Reject | B |
This document only describes the FIX workflows and fields necessary to access Integral. All fields not included in this document are unsupported and ignored by Integral.
Some fields are required conditionally based on the state of the message workflow or on the value of other fields in the message. These conditions and dependencies are clearly indicated in the field descriptions.
For many fields of type String, the FIX protocol defines all possible valid values. Therefore, the maximum string length of these fields is also defined. The maximum string length never exceeds the longest valid value.
The API does not impose a maximum length on undefined String fields, such as free-form text fields and ID fields.
The API does not impose a maximum length on FIX messages sent or received by Integral.
The API does not support FIX message encryption. Instead, the network transport mechanism (VPN, Radianz, or SSL) ensures message security.
FIX engines set a message’s header and footer fields automatically according to the message type and the application context as defined by the application’s configuration (Configuration). For these reasons, the standard header and footer as defined by the FIX protocol are not discussed in detail in this document beyond the expected value of the MsgType (#35) and the fields that identify message and business senders and targets, such as the SenderCompID (#49), and TargetCompID (#56) fields.
Standard message header fields
| Tag | Field name | Req’d | Value | Description | Type(length) |
|---|---|---|---|---|---|
| 8 | BeginString | Y | FIX.4.3 | The identifier at the beginning of a new message that also holds the protocol version. Always set to “FIX.4.3”. Always the first field in the message. | String(7) |
| 9 | BodyLength | Y | — | Indicates the message length in bytes. Always the second field in the message. | int(6) |
| 35 | MsgType | Y | — | Defines the message type. Always the third field in the message. See Supported message types for the complete list of supported message types. | String(2) |
| 34 | MsgSeqNum | Y | — | This value is an integer message sequence number. | SeqNum(9) |
| 43 | PossDupFlag | N | Y=Possible duplicate N=Original transmission | Indicates possible retransmission of message with this sequence number. | Boolean(1) |
| 49 | SenderCompID | Y | — | The message sender’s ID. See Organization identification. | String(20) |
| 56 | TargetCompID | Y | — | The message target’s ID. See Organization identification. | String(20) |
| 52 | SendingTime | Y | — | The time of message transmission (GMT). | UTCTimestamp(21) |
| 122 | OrigSendingTime | N | — | Original time of message transmission when transmitting orders as the result of a resend request. | UTCTimestamp(21) |
Standard message footer field
| Tag | Field name | Req’d | Value | Description | Type(length) |
|---|---|---|---|---|---|
| 10 | Checksum | Y | — | A three byte, simple checksum that is always the last field on the message. | String(3) |
The following sections describe the details involved in establishing a connection via the API.
Integral deploys an API FIX engine instance for each maker. The instance is called the FIX Maker RFS API adaptor. The adaptor handles all streams from the maker and submits orders to the maker.
The API uses TCP/IP sockets. FIX message encryption is not supported. Makers connect to Integral using one of the following options to ensure network reliability and security:
- Radianz
- IPSec VPN
- SSL
The values of the TargetCompId (#49) and SenderCompId (#56) fields in the message header are supplied by Integral for each maker connection. Integral does not allow multiple connections using the same TargetCompId (#49) and SenderCompId (#56) fields.
Integral is a trading facilitator. Trades are booked directly between your organization (maker) and the end customer. You must assign an account ID to each of the maker’s customer legal entities trading through Integral. The account ID is set on the Account (#1) field of New Order – Single message. The account ID value is agreed upon by your organization and Integral.
The ClientTag on a trade request, if any, is captured in the PartyID (#448) field. The ClientTag is a unique ID whose value is set by Integral. It is an optional field. See New Order – Single.
Your organization ID is expressed as a series of tokens separated by periods, much like an Internet domain name:
<sessionType>.<orgShortName>
price.yourOrg4Organization ID format
| Token | Example | Description |
|---|---|---|
| sessionType | price.yourOrg4 | For a description of the following session types, see Sessions:
|
| orgShortName | price.yourOrg4 | Your organization’s short name ID |
All messages that you send to Integral must include your ID in the SenderCompID (#49) field.
All messages that you receive from Integral include your ID in the TargetCompID (#56) field.
Like your organization ID, the Integral server ID looks like an Internet domain name:
<environment>.integral
demo.integralOrganization ID format
| Token | Example | Description |
|---|---|---|
| environment | demo.integral | The specific environment to which you are connected (for example, staging, staging, or production) |
| integral | demo.integral | The Integral server ID |
All messages that you send to Integral must include the server ID in the TargetCompID (#56) field.
All messages that you receive from Integral include your ID in the SenderCompID (#49) field.
The FIX Maker RFS API supports initiator and acceptor connection modes. Communication starts with a Logon message (Logon) and ends with a Logout message (Logout).
In the acceptor mode, your FIX engine initiates the FIX connection. The acceptor mode is the default, preferred connection mode for the API. The following parameters must be specified in the FIX configuration of your FIX engine:
Parameters for acceptor connection mode
ConnectionType=acceptor
SocketAcceptPort=<Integral’s Port>In the initiator mode, Integral initiates the FIX connection to the maker’s FIX engine. To configure your systems for initiator mode, please contact Integral Business Support. The following parameters must be specified in the FIX configuration of your FIX engine:
Parameters for initiator connection mode
ConnectionType=initiator
SocketConnectHost=<Maker’s IP>
SocketConnectPort=<Maker’s Port>
HeartBtInt=5The following business rules apply to all API workflows.
The API distinguishes between two session types to optimize your trading message flows: price and order. You must establish both sessions to initiate all trading workflows.
Every session has exactly one associated session of the other type. Orders in an order session can only be received from prices sourced from its associated price session.
- Price: Session for sending/receiving market data and quotes. Messages are time-sensitive and transient to enable the high message volume typically associated with prices and price streams. Integral does not resend price session messages in response to a resend request from the maker system. You must establish a price session to initiate all trading workflows. See Starting the trading session.
- Order: Session for order submission and trade execution. Messages are transactional and persistent with no lost messages allowed, reflecting their business criticality. Integral resends order session messages in response to a resend request from the maker system. You must establish an order session to initiate all trading workflows. See Starting the trading session. How you use an order session depends on the trading workflow you employ.
You must log on and establish each FIX session separately with Integral. You use the same credentials for each session type. You can have multiple FIX sessions under one server connection. You do not have to reconnect for each session.
The ID that you set for your organization ID on messages includes an indicator of the session type. See Maker organization ID.
The business day start and end time must be agreed upon by your organization and Integral. A typical daily configuration starts the day at 17:00:05 EST and ends at 17:00:00 EST.
Daily start/stop times
ResetOnLogout=N
ResetOnLogin=N
ResetOnDisconnect=N
StartTime=17:00:05
EndTime=17:00:00
TimeZone=America/New_YorkThe API allows you to set custom start and end times for every day of the week.
The following examples illustrate the capabilities of API start/stop times. Please contact Integral Business Support to configure custom start/stop times.
Custom start/stop times format
CustomScheduleTime=[*startDay0* *startTime0*]-[*endDay* *endTime*]~[*startDay1* *startTime1*]-[*endDay1* *endTime1*]~…Custom start/stop times example
CustomScheduleTime=[Sunday 08:30:00]-[Monday 06:35:00]~[Monday 06:40:00]-[Tuesday 04:00:00]~…Your servers initiating the FIX connection to Integral should be synchronized with the NTP pool. For more information about using the NTP pool, please use the following link:
http://www.pool.ntp.org/en/use.html
Your FIX engine must be configured to reset the sequence number MsgSeqNum (#34) only at the end of day and not on disconnect.
To reset sequence numbers once a day after the business day end, the following session-level FIX parameters need to be set on the acceptor and initiator side with the following values (assuming 17:00:05 EST and 17:00:00 EST are the start and end time). The initiator side may have a slightly larger down-time window to ensure that the acceptor is ready to handle the connection started by the initiator. See Connection mode for more information about initiator and acceptor connection modes.
Parameters for acceptor sequence number reset
ResetOnDisconnect=N
ResetOnLogout=N
StartTime=17:00:05
EndTime=17:00:00Parameters for initiator sequence number reset
ResetOnDisconnect=N
ResetOnLogout=N
StartTime=17:00:05
EndTime=17:00:00The API handles trading events from customers and makers on a first-come first-served basis.
The API currently supports dealing in the following deal types:
- RFS orders are always previously quoted (
OrdType(#40)=D) and FOK (TimeInForce(#59)=4)- FX spot
- FX outright
- FX swap (spot-forward and forward-forward)
- NDF (Non-Deliverable Forward)
- FSR (Fixed Spot Roll)
An FSR is a type of swap with a customer-specified start rate. Investors (CTAs, pension funds, investment managers, HFs) commonly request FSRs so they can roll out currency positions to forward dates at a specified rate. The rate on the near leg must match the rate on the original trade to avoid cash flow differences.
When quoting FSRs, you must quote back the same near rate value as requested by the customer in the Price (#44) field of the Quote Request message. This behavior is verified during conformance testing and is expected in production. See Price.
The API holds mid-mark information in the following fields:
| Tag | Field name | Req’d | Value | Description | Type(length) |
|---|---|---|---|---|---|
| 631 | MidPx | N | — | The near-leg all-in mid price. Only required when the receiving organization is required to receive Pre-Trade Mid-Market Mark. This decision is made by the maker. | Price(20) |
| 7631 | MidPxFl | N | — | The far-leg all-in mid price. Only required when the receiving organization is required to receive Pre-Trade Mid-Market Mark. This decision is made by the maker. | Price(20) |
The following messages are used to control the FIX session and manage message conversations:
(Bidirectional)
The Logon message is sent by the maker system to start a session with Integral and sent by Integral in response to a valid log-on request.
You should reset the FIX sequence number for the price session (ResetSeqNumFlag (#141)=Y) after 3 or 4 unsuccessful log-on attempts. Do not reset the sequence number of the order session.
If Integral receives a Logon message with invalid fields, it sends a Logout message in response. See Logout.
Logon message fields
| Tag | Name | Req’d | Value | Description | Type(length) |
|---|---|---|---|---|---|
| 35 | MsgType | Y | A | A=Logon | String(2) |
| 52 | SendingTime | Y | — | All messages sent from the maker to Integral must include millisecond precision: HH:MM:SS.sss | UTCTimestamp(21) |
| 98 | EncryptMethod | N | 0 | 0 (zero)=no encryption is used. This field may be omitted. Radianz or VPN is used for transport-level security. | int(1) |
| 108 | HeartBtInt | Y | 5 | Heartbeat interval in seconds. If HeartBtInt is set zero, then no heart beat message is required. The recommended heartbeat interval is 5 seconds. | int(3) |
| 141 | ResetSeqNumFlag | N | Y | Indicates that both sides of the FIX session should reset sequence numbers. You should reset the FIX sequence number for the price session after 3 or 4 unsuccessful log-on attempts. Do not reset the sequence number of the order session. Y=Yes, reset sequence numbers N=No, do not reset sequence numbers | Boolean(1) |
(Bidirectional)
The Logout message is sent by the maker system to end a session with Integral and sent by Integral in response.
If Integral receives a Logon message with invalid fields, it sends a Logout message in response with a description of the error in the Text (#58) field.
Logout message fields
| Tag | Name | Req’d | Value | Description | Type(length) |
|---|---|---|---|---|---|
| 35 | MsgType | Y | 5 | 5=Logout | String(2) |
| 52 | SendingTime | Y | — | All messages sent from the maker to Integral must include millisecond precision: HH:MM:SS.sss | UTCTimestamp(21) |
| 58 | Text | N | — | The reason for the Logon rejection. Only included for incoming Logout messages (Integral to maker) in response to a invalid Logon message. Not valid for outgoing Logout messages (maker to Integral). | String(150) |
(Bidirectional)
Both the maker system and Integral send the Heartbeat message to indicate that the connection is active.
The maker system generates a regular heartbeat at the interval defined by the HeartBtInt (#108) field in the Logon message from Integral or as a response to a Test Request message from Integral. The recommended heartbeat interval is 5 seconds.
Heartbeat message fields
| Tag | Name | Req’d | Value | Description | Type(length) |
|---|---|---|---|---|---|
| 35 | MsgType | Y | 0 | 0 (zero)=Heartbeat | String(2) |
| 52 | SendingTime | Y | — | All messages sent from the maker to Integral must include millisecond precision: HH:MM:SS.sss | UTCTimestamp(21) |
| 112 | TestReqID | N | — | Required when the heartbeat is the result of a Test Request message. See Test Request. | Strin(20) |
(Bidirectional)
Forces a heartbeat from the receiving system. The receiving system responds to a Test Request message with a Heartbeat message containing the TestReqID. See Heartbeat.
Test Request message fields
| Tag | Name | Req’d | Value | Description | Type(length) |
|---|---|---|---|---|---|
| 35 | MsgType | Y | 1 | 1=Test Request | String(2) |
| 52 | SendingTime | Y | — | All messages sent from the maker to Integral must include millisecond precision: HH:MM:SS.sss | UTCTimestamp(21) |
| 112 | TestReqID | Y | — | The resulting Heartbeat message contains this ID. The TestReqId should be incremental. | String(20) |
(Bidirectional)
The Integral accepts Resend Request messages only for order sessions (Sessions). Resend Requests sent on a price session are ignored. Both the maker system and Integral can send a Resend Request message when they detect a message gap to request either a single message or a range of messages.
Resend Request message fields
| Tag | Name | Req’d | Value | Description | Type(length) |
|---|---|---|---|---|---|
| 35 | MsgType | Y | 2 | 2=Resend Request | Stgring(2) |
| 52 | SendingTime | Y | — | All messages sent from the maker to Integral must include millisecond precision: HH:MM:SS.sss | UTCTimestamp(21) |
| 122 | OrigSendingTime | N | — | Original time of message transmission when transmitting orders as the result of a resend request | UTCTimestamp(21) |
| 7 | BeginSeqNo | Y | — | First message of range (inclusive) | SeqNum(9) |
| 16 | EndSeqNo | Y | — | Last message of range (inclusive). If the value of the EndSeqNo (#16) field is equal to the BeginSeqNo (#7) field, a single message is requested. To request all messages after the BeginSeqNo (#7) field, set the EndSeqNo (#16) field to 0 (zero). | SeqNum(9) |
(Bidirectional)
Both the maker system and Integral send this message when a message is received but cannot be processed for some reason, such as a missing field required by the FIX protocol.
Reject message fields
| Tag | Name | Req’d | Value | Description | Type(length) |
|---|---|---|---|---|---|
| 35 | MsgType | Y | 3 | 3=Reject | String(2) |
| 45 | RefSeqNum | Y | — | Value of the MsgSeqNum (#34) field of the rejected message. | SeqNum(9) |
| 52 | SendingTime | Y | — | All messages sent from the maker to Integral must include millisecond precision: HH:MM:SS.sss | UTCTimestamp(21) |
| 58 | Text | N | — | Free-form text explaining the reason for rejection. | String(150) |
| 371 | RefTagID | N | — | The tag number of the FIX field being referenced. | int(5) |
| 372 | RefMsgType | N | — | The value of the MsgType (#35) field in the FIX message being referenced. | String(2) |
| 373 | SessionRejectReason | N | — | The code that indicates the reason for rejection. 0=Invalid tag number 1=Required tag missing 2=Tag not defined for message type 3=Undefined Tag 4=Tag specified without a value 5=Value is incorrect (out of range) for this tag 6=Incorrect data format for value 7=Decryption problem 8=Signature problem 9=CompID problem 10=SendingTime accuracy problem 11=Invalid MsgType 12=XML Validation error 13=Tag appears more than once 14=Tag specified out of required order 15=Repeating group fields out of order 16=Incorrect NumInGroup count for repeating group 17=Non “data” value includes field delimiter (SOH character) 99=Other | int(2) |
(Bidirectional)
This message is sent by both the maker system and Integral to reassign the sequence number when a gap in messages is detected.
Sequence Reset message fields
| Tag | Name | Req’d | Value | Description | Type(length) |
|---|---|---|---|---|---|
| 35 | MsgType | Y | 4 | 4=Sequence Reset | String(2) |
| 52 | SendingTime | Y | — | All messages sent from the maker to Integral must include millisecond precision: HH:MM:SS.sss | UTCTimestamp(21) |
| 122 | OrigSendingTime | N | — | Original time of message transmission when transmitting orders as the result of a resend request | UTCTimestamp(21) |
| 36 | NewSeqNo | Y | — | The next sequence number to be transmitted. | SeqNum(9) |
| 123 | GapFillFlag | N | — | Indicates that the Sequence Reset message is replacing administrative or application messages that will not be resent. Y=Gap fill, the NewSeqNo (#36) field should conform to the FIX-standard message sequencing rules.N or not specified=Sequence reset, the NewSeqNo (#36) of the header of the Sequence Reset message should be ignored so that if it is not correct it does not generate resent requests. This value would be appropriate in a disaster recovery situation. | Boolean(1) |
All trading activity through the API begins with a query to establish the maker’s trading session status (Starting the trading session).
After the trading session has been established, the API implements the RFS pricing workflow (Request for stream (RFS) workflow 23).
For order submission and trade execution, see Orders workflow.
A trading session consists of one price session and its associated order session. For more information about sessions, see Sessions.
To start a trading session, the following FIX message conversation must complete successfully between Integral and the maker.
Integral can only start the business workflow if the trading session status is “Open” (TradSesStatus (#340)=2) for both the price and order sessions.
- Logon (#35=A) sent from maker on price session.
- Logon response (#35=A) on price session from Integral.
- Trading Session Status Request (#35=g) sent from Integral.
- Trading Session Status (#35=h) with
TradSesStatus(#340)=2 (Open) sent from maker on price session. - Logon (#35=A) sent from maker on order session.
- Logon response (#35=A) on order session from Integral.
- Trading Session Status Request (#35=g) sent from Integral.
- Trading Session Status (#35=h) with
TradSesStatus(#340)=2 (Open) sent from maker on order session.
Message conversation to start trading
To alert customers of a change in trading session status, the maker sends an unsolicited trading session status message. Typical reasons for unsolicited trading session status messages are:
- End-of-day close for daily sequence number reset
- End-of-week close for weekly maintenance
- Intra-day close due to errors
Asynchronous trading session status update
When the trading session is “Closed” (TradSesStatus (#340)=3) or “Halted” (TradSesStatus (#340)=1), Integral stops sending messages and cleans up the current trading session (both the FIX price session and the FIX order session). When the trading session is reopened, Integral re-initializes the business workflow.
Integral can only start the trading workflow if the trading session status is “Open” (TradSesStatus (#340)=2) for both the price and order sessions. See Starting the trading session.
The API currently supports the following trade types in the RFS workflow:
- FX spot
- FX outright
- FX swap (spot-forward and forward-forward)
- FSR (Fixed Spot Roll, see Supported Deal Types)
The RFS workflow involves the price and order sessions. For more information about sessions, see Sessions.
The client requests a quote on a price session and receives executable quotes the same price session. Then in an order session the customer sends orders that refer to a quote’s QuoteEntryID (#299).
Typical RFS trading workflow
The following trading messages are applicable to the RFS workflow:
RFS trading messages
| Message (Direction) | Session | Comments |
|---|---|---|
| Quote Request | Price | Customer through Integral requests streaming quotes from the maker |
| Quote Request Reject | Price | Maker rejects customer request for quotes |
| Quote | Price | Maker sends a price stream to Integral for the customer. Subsequent quotes override the previous quote. |
| Quote Cancel | Price | Maker sends message to Integral to cancel the price stream |
| Business Message Reject | Price | In the RFS workflow, this message is sent by the customer through Integral to cancel a quote request. |
| New Order – Single | Order |
|
| Order Status Request | Order | Customer through Integral sends this message to the maker to request an Execution Report be sent with the order’s current status. |
| Order Cancel Request | Order | Customer through Integral sends this message to the maker to request cancellation of a previously submitted order. |
| Execution Report | Order | Maker sends the current order status to Integral. An Execution Report with ExecType (#150) value 0 (New) is optional and may be skipped. See Order state transition for details. |
The RFS workflow supports outrights and swaps. For future dates, you can specify either a broken date in the format of YYYYMMDD or a standard tenor.
The tenors supported by a maker are determined when the API solution is deployed. Integral rejects messages from customers with unsupported dates or tenors.
Tenors or broken dates are specified in the MaturityDate (#541) field of Market Data Request, and Market Data Snapshot/Full Refresh messages and in the SettlDate (#64) field of New Order – Single and Execution Report messages.
The API supports the following tenors:
Supported tenors
| Tenor | Definition |
|---|---|
| Today | Today |
| TOD | Today |
| ON | Overnight (today) |
| Tomorrow | Tomorrow |
| TOM | Tomorrow |
| TN | Tomorrow |
| SPOT, Spot | Spot |
| SP | Spot |
| SN | Spot next (spot+1) |
| nD | A number of days from SPOT (for example, 1D, 2D, 10D) |
| nW | A number of weeks from SPOT (for example, 1W, 2W, 3W) |
| nM | A number of months (for example, 1M, 2M, 3M) |
| nY | A number of years from SPOT (for example, 1Y, 2Y, 3Y) |
| nIMM | The next International Monetary Market (IMM) settlement date. IMM dates are the third Wednesday of the last month of every quarter (March, June, September, December). Entering IMM results in the next IMM date on or after the spot date. Entering 2IMM results in two IMM dates after the spot date. |
Order messages are exchanged on order sessions. See Sessions for more information about order and price sessions. Orders originate with Integral sending a New Order – Single message to the maker as part of a pricing workflow.
The following FIX messages implement the order trading flow:
Order trading messages
| Message (Direction) | Session | Comments |
|---|---|---|
| New Order – Single | Order | Customer through Integral submits an order to the maker. |
| Execution Report | Order | Maker sends the current order status to the customer through Integral. The Execution Report with ExecType (#150) value 0 (New) is optional and may be skipped. See Order state transition for details. |
| Order Status Request | Order | Customer through Integral requests the current status of a specific order. |
| Order Cancel Request | Order | Customer through Integral requests cancellation of a previously submitted order. |
| Business Message Reject | Order |
|
| Order Timeout | Order | If autocancellation is configured, maker receives this message if Integral does not receive a rejection or trade verification before the order times out. |
| Don’t Know Trade (DK) | Order | If autocancellation is configured, maker receives this message if Integral receives a trade response after the order times out and an Order Timeout message is sent. |
After Integral submits an order, the maker sends an Execution Report message with an ExecType (#150) value of A=“Pending New” to confirm receipt. After the maker has checked the order’s validity, the maker sends an Execution Report message with an ExecType (#150) value of 0 (zero)=“New” to Integral.
An order can have one or more trades executed against it, either one completely filling or multiple trades partially filling the order.
Order submission and execution
After Integral submits an order, the maker immediately sends an Execution Message with an ExecType (#150) value of A=“Pending New” to confirm receipt. If the order fails the maker’s validity check, the maker sends an Execution Report message with an ExecType (#150) value of 8 “Rejected” to Integral.
Order rejection
An IOC order expires immediately after the initial match. Any residual amount is canceled by the maker by sending an Execution Report message with an ExecType (#150) value of C “Expired” to Integral.
Order expiry
When autocancellation is enabled, if Integral does not receive a trade rejection or verification from the maker by the end of the timeout interval, an Order Timeout message is sent to the maker. This order timeout informs the maker that no valid Execution Report with a fill or rejection was received within the autocancellation timeout interval and the order is timed out (effectively rejected).
If a rejection or verification is received from the maker after the Order Timeout message is sent, a Don’t Know Trade (DK) message is sent to the maker.
In addition, when an order reaches a terminal state (verification, rejection, expiry for a partial fill, or expiry/complete fill for a multiple fill order), then any terminal state message that is sent by the maker triggers a Don’t Know Trade (DK) message in response.
Order timeout
Integral uses the Order Status Request message to query the maker about pending trades.
If the “PendingNew” Execution Report is not received by Integral for a predefined time period, Integral raises a pending trade alert to Integral support personnel and sends an Order Status Request message to the maker to query the status of the pending order.
Alternatively, Integral can automatically cancel the pending trade to the customer by following policies established between Integral and the maker before deployment of the API. See Order timeout.
If the Order Status Request message is rejected or if an Execution Report is not forthcoming, the trade remains pending and requires manual intervention from Integral and the maker’s support staff.
If Integral receives an Execution Report from the maker for a pending trade, Integral updates the status of the trade. Integral support staff may still contact the maker regarding the delayed response because of the possibility of customer exposures.
Order status request
Integral uses the Order Cancel Request message to cancel a previously submitted order.
Order cancel request
The API supports orders with the following OrdType (#40) values. Integral rejects messages from customers with unsupported order types.
Order types
| Order type | OrdType (#40) value | Description |
|---|---|---|
| Previously Quoted | D | The client sends new orders with a reference to a previously received executable price in QuoteEntryID (#299) from a price. |
| Limit | 2 | Orders executed at the limit price or better until they are filled, rejected, or expired (Order expiry (time in force)). Orders must include the requested price and size (Price (#44) and OrderQty (#38)). |
| Market | 1 | Orders are executed at the best available price in the system.until they are filled, rejected, or expired (Order expiry (time in force)). |
The FIX Maker RFS API supports orders with the following TimeInForce (#59) values:
Order expiry
| Expiry type | Description | TimeInForce (#59) | Applicable order types |
|---|---|---|---|
| Day | The order remains active for the entire day until it is completely filled, canceled by the customer, or until the end of the business day (the roll time). | 0=Day |
|
| IOC (Immediate or Cancel) | The order is matched with the available order book in the system after the submission. If the order is not completely filled (or after the expiry/cancel message is received) any remaining amount is cancelled. If no fill/expiry/cancel message is received, the entire order is assumed to be cancelled. If MinQty (#110) is specified, the first fill must be greater than or equal to the minimum quantity and lesser than or equal to the order quantity, otherwise the order goes into a pending state. Subsequent fills, if any, may be of any size.If MinQty (#110) is not specified, the first fill may be of any size less than or equal to the order size. Subsequent fills, if any, may be of any size. | 3=IOC |
|
| FOK (Fill or Kill) | The order is matched with the available order book in the system after the submission. The order amount must be completely filled with one fill or canceled in its entirety. No partial fill is allowed. | 4=FOK |
|
| GTT/GTD (Good Till Date/Time) | The order remains active until completely filled, canceled by the submitter, or expired. Applicable to limit orders only. See Supported order types. You must specify the expiry time in GMT in the ExpireTime (#126) field in the format YYYYMMDD-hh:mm:ss.sss.For example, to set the order to expire at 17:00 on August 14th, 2025, you would specify 126=20250814-17:00:00.000. | 6=GTT/GTD | Limit |
Partial fills apply only to the order trading workflow. See Orders workflow for information.
You can specify how orders are filled with the MinQty (#110) field in the New Order – Single message:
- Partial fill: The order amount can be filled multiple times until the entire amount is filled.
- Partial fill with market minimum: The order amount can be filled multiple times, but the first fill must be no less than the market minimum defined by the
MinQty(#110) field. Subsequent fills have no size requirement. - No partial fill: The order amount must be filled in its entirety with exactly one fill. The value of the
MinQty(#110) field equals the value of theOrderQty(#38) field. This is effectively a fill-or-kill order.
For more details about partial fills, see the MinQty field in the New Order – Single message.
The maker maintains an order’s status and propagates changes in status via Execution Report messages to Integral. The order states and state transitions are shown in Order state transitions. Each circle represents a value of the OrdStatus (#39) field of an Execution Report message. The event names on the transition lines represent the ExecType (#150) values of the Execution Report message. Multiple transitions from the same OrdStatus (#39) may have the same ExecType (#150) value. The destination OrdStatus (#39) is determined by other attributes of the order as described in Orders workflow.
Order status
| Order Status | OrdStatus (#39) | Description |
|---|---|---|
| Pending New | A | An order is received by maker. This order state is optional. |
| New | 0 (zero) | The validity of the order is confirmed. The order is successfully entered maker’s execution management process. |
| Partially filled | 1 | The order is partially filled by maker. |
| Filled | 2 | The total order amount is filled. |
| Rejected | 8 | The maker determines that the order is invalid. The order is rejected. |
| Expired | C | When an order is expired, its residual amount (full amount if the order is New) is canceled. For IOC orders, the order is immediately expired after the initial match. Any remaining amount must be expired or rejected. |
| Canceled | 4 | The order is canceled by the customer. |
The FIX Maker RFS API offers the following order workflow features to makers:
- Order submission
- Order execution reports for accept/acknowledge, reject, trade execution, and partial fill events
All messages sent from the maker to Integral must include millisecond precision in the SendingTime (#52) field.
The API order workflow supports the following FIX messages types:
Supported message types
| MsgType (#35) | Message name | Inbound to Maker (I), Outbound from Maker (O), or Bidirectional (B) |
|---|---|---|
| g | Trading Session Status Request | I |
| h | Trading Session Status | O |
| R | Quote Request | I |
| AG | Quote Request Reject | O |
| S | Quote | O |
| Z | Quote Cancel | O |
| D | New Order – Single | I |
| H | Order Status Request | I |
| F | Order Cancel Request | I |
| OT | Order Timeout | I |
| Q | Don’t Know Trade (DK) | I |
| 8 | Execution Report | O |
| BN | Execution Acknowledgment | O |
| j | Business Message Reject | B |
(Integral to Maker)
This message is sent by Integral to query the maker’s status and as part of starting a trading session with the maker. For more information, see Starting the trading session.
Trading Session Status Request message fields
| Tag | Name | Req’d | Values | Description | Type(length) |
|---|---|---|---|---|---|
| 35 | MsgType | Y | g | — | String(2) |
| 263 | SubscriptionRequestType | Y | — | 0 (zero)=Snapshot | char(1) |
| 335 | TradSesReqID | Y | — | Unique ID assigned by the customer for the request message | String(20) |
(Maker to Integral)
This message is sent by the maker to notify Integral of intra-day closing and opening of the market, and as part of starting a trading session with the maker. For more information, see Starting the trading session.
Trading Session Status message fields
| Tag | Name | Req’d | Values | Description | Type(length) |
|---|---|---|---|---|---|
| 35 | MsgType | Y | h | — | String(2) |
| 52 | SendingTime | Y | — | All messages sent from the maker to Integral must include millisecond precision: YYYYMMDD-HH:MM:SS.sss | UTCTimestamp(21) |
| 325 | UnsolicitedIndicator | N |
| If the message is sent unsolicited, the value of this field should be “Y”. If the message is sent as a response to a customer request, this field should have a value of “N” or may be omitted or left empty. For more information, see Stopping the trading session. | Boolean(1) |
| 335 | TradSesReqID | N | — | Reference to the value of TradSesReqID (#335) field on the customer request, if any. If the status message is sent unsolicited, this field should be left empty or not included. | String(20) |
| 336 | TradingSessionID | Y | — | ID of the trading session. Can be any string. | String(20) |
| 340 | TradSesStatus | Y | — | 0=Unknown 1=Halted (trading temporarily suspended) 2=Open 3=Closed | int(1) |
The messages in this section are used to access the RFS workflow (see Request for stream (RFS) workflow).
(Integral to Maker)
Integral sends a Quote Request message to the maker to initiate the RFS workflow (see Request for stream (RFS) workflow).
Quote Request message fields
| Tag | Name | Req’d | Values | Description | Type(length) | |
|---|---|---|---|---|---|---|
| 35 | MsgType | Y | R | — | String(2) | |
| 1 | Account | Y | — | The account ID. The value of this field is agreed upon by your organization and Integral. | String(30) | |
| 131 | QuoteReqID | Y | — | Client-assigned unique ID for the quote request | String(20) | |
| 7540 | StreamID | N | — | The ID for the stream agreed by Integral and the maker. If the maker does not support multi-stream pricing, this field is not included or is left empty. | String(30) | |
| 146 | NoRelatedSym | Y | 1 | Number of related instruments in the request. This value is always "1" (one). | NumInGroup(1) | |
| 55 | Symbol | Y | — | Currency pair symbol | String(35) | |
| 167 | SecurityType | Y |
| The security type or trade type:
| String(20) | |
| 54 | Side | Y | — | The order side from customer’s (FIX client) perspective. For one-way RFS, the side is in the dealt currency in the Currency (#15) field. For FX swap, it is the side of the far leg.1=Buy 2=Sell Space=2-Way | char(1) | |
| 38 | OrderQty | Y | — | Requested amount specified in the dealt currency Currency (#15). For FX swap, this is the near leg amount. | Qty(20) | |
| 22 | SecurityIDSource | See descr. | 4=ISIN number | (MiFID) Required if SecurityID (#48) is included. Identifies class or source of the SecurityID (#48) value. | String(1) | |
| 48 | SecurityID | N | — | (MiFID) Required if SecurityIDSource (#22) is included. Security identifier value. For swaps, the near- and far-leg values are comma separated (nearLegISIN,farLegISIN). | String(12) | |
| 453 | NoPartyIDs | N | 2 | (MiFID) For quote requests sent to an MTF, the repeating groups represent the following entities:
| NumInGroup(1) | |
| → | 448 | PartyID | N | See descr. | (MiFID) Required if NoPartyIDs (#453) is included. For quote requests sent to an MTF, this field has the following value based on entity type
| String(20) |
| → | 447 | PartyIDSource | N | G=MIC N=LEI | (MiFID) Party ID
| char(1) |
| → | 452 | PartyRole | See descr. | 64=Multilateral Trading Facility 13=Order Originating Firm | (MiFID) Party ID
| char(1) |
| → | 802 | NoPartySubIDs | N | 1 | (MiFID) A repeating group to contain the venue’s LEI. | NumInGroup(1) |
| → | 523 | PartySubID | See descr. | — | (MiFID) The venue’s LEI. Required if NoPartySubIDs (#802) is added. | String(20) |
| 64 | SettlDate | Y | See descr. |
|
| |
| 40 | OrdType | Y | — | D=Previously quoted (for FX spot, FX outright RFS, and NDF) G=FX swap | char(1) | |
| 44 | Price | See descr. | — | Included on the Quote Request message only for Fixed Spot Roll (FSR) requests. This is the near leg rate of the swap as specified by the customer. For subsequent FSR quotes sent by the maker to the FXCloud, the near leg rate is validated to ensure that it is exactly equal to this rate sent in the FSR request. If the quote rates do not match the customer-specified rate, the quotes are dropped and a Business Message Reject is sent to cancel the quote message. | Price(20) | |
| 193 | SettlDate2 | N |
| FX spot, outright: Not applicable FX swap or NDF swap: The far leg value date The field contains either standard tenor symbol or a broken date in YYYYMMDD format. If the field is empty, it is considered a spot stream request. |
| |
| 192 | OrderQty2 | N | — | Requested amount specified in the dealt currency Currency (#15). For FX swap, this is the far leg amount. | Qty(20) | |
| 126 | ExpireTime | Y | YYYYMMDD-HH:MM:SS.sss | The relative expiration time of the quote request the format:YYYYMMDD-HH:MM:SS.sssThe date portion of the value is ignored. The time portion specifies the amount of time before the quote request expires. For example, for a request that expires in 120 seconds, the value would be 00000000-00:02:00. | UTCTimestamp(21) | |
| 60 | TransactTime | Y | YYYYMMDD-HH:MM:SS.sss | The time the Quote Request is sent by the client. This field is automatically stamped by the FIX engine. | UTCTimestamp(21) | |
| 15 | Currency | Y | — | Dealt currency | String(3) | |
| 541 | MaturityDate | N | YYYYMMDD | The fixing date for NDF trades. Near-leg fixing date for NDF swaps. Related to SettlDate (#64).. Value is either calculated based on the applicable quote convention or is a user entered value in YYYYMMDD format. | LocalMktDate(8) | |
| 8541 | MaturityDate2 | N | YYYYMMDD | The far-leg fixing date for NDF swap trades. Related to SettlDate2`` (#193).. Value is either calculated based on the applicable quote convention or is a user entered value in YYYYMMDD format. | LocalMktDate(8) | |
(Maker to Integral)
The maker sends a Quote Request Reject message to Integral to reject a previously sent Quote Request.
Quote Request Reject message fields
| Tag | Name | Req’d | Values | Description | Type(length) |
|---|---|---|---|---|---|
| 35 | MsgType | Y | AG | — | String(2) |
| 52 | SendingTime | Y | — | All messages sent from the maker to Integral must include millisecond precision: YYYYMMDD-HH:MM:SS.sss | UTCTimestamp(21) |
| 60 | TransactTime | Y | YYYYMMDD-HH:MM:SS.sss | The time the Quote Request reject message is generated | UTCTimestamp(21) |
| 131 | QuoteReqID | Y | — | The OrdReqID (#131) of the Quote Request message that has been rejected | String(20) |
| 146 | NoRelatedSym | Y | 1 (one) | Always set to 1 (one) | NumInGroup(1) |
| 55 | Symbol | Y | — | The symbol for the base and variable currencies of the currency pair in the format baseCCY/variableCCY (for example, EUR/USD”) This should be the same value as the one received from the Quote Request message. | String(35) |
| 658 | QuoteRequestRejectReason | Y | — | The reason for the rejection: 1=Unknown symbol (Security) 2=Exchange (Security) closed 3=Quote Request exceeds limit 4=Too late to enter 5 =Invalid price 6=Not authorized to request quote 7=No match for inquiry 8=No market for instrument 9=No inventory 10=Pass 99=Other | String(2) |
(Maker to Integral)
The maker sends a Quote message to Integral in response to a successful Quote Request.
Quote message fields
| Tag | Name | Req’d | Values | Description | Type(length) | ||
|---|---|---|---|---|---|---|---|
| 35 | MsgType | Y | S | — | String(2) | ||
| 52 | SendingTime | Y | — | All messages sent from the maker to Integral must include millisecond precision: YYYYMMDD-HH:MM:SS.sss | UTCTimestamp(21) | ||
| 15 | Currency | Y | — | Dealt currency | String(3) | ||
| 40 | OrdType | Y |
| D=Previously quoted (for FX spot and FX outright RFS). G=FX swap | char(1) | ||
| 54 | Side | Y | 1=Buy 2=Sell Empty=2-Way | The order side from customer’s (FIX client) perspective. For one-way RFS, this value should match the value of the Side (#54) field on the originating Quote Request. For FX swap, it is the side of the far leg. | char(1) | ||
| 55 | Symbol | Y | — | Currency pair symbol | String(35) | ||
| 60 | TransactTime | Y | — | The time the message is generated in the format YYYYMMDD-HH:MM:SS.sss. | UTCTimestamp(21) | ||
| 62 | ValidUntilTime | N | — | Expiry time of the quote in the format YYYYMMDD-HH:MM:SS.sss.Only the time portion is used as a time duration. For example, 00000000-00:01:30.000 means the quote is good for 1 minute and 30 seconds. | UTCTimestamp(21) | ||
| 64 | SettlDate | N | See descr. |
|
| ||
| 117 | QuoteID | Y | — | Unique quote ID assigned by the maker | String(20) | ||
| 131 | QuoteReqID | Y | — | Customer-assigned unique ID from the originating quote request | String(20) | ||
| 132 | BidPx | N | — | All-in bid price. Included only if Side (#54) in the originating Quote Request is 2-way for all trade types, sell for spot and outright trades, and buy for swaps.
| Price(20) | ||
| 133 | OfferPx | N | — | All-in offer price. Included only if Side (#54) in the originating Quote Request is 2-way for all trade types, buy for spot and outright trades, and sell for swaps.
| Price(20) | ||
| 134 | BidSize | N | — | Bid size of the near leg quote. Included only if Side (#54) in the originating Quote Request is sell or 2-way. | Qty(20) | ||
| 135 | OfferSize | N | — | Offer size of the near leg quote. Included only if Side (#54) in the originating Quote Request is buy or 2-way. | Qty(20) | ||
| 167 | SecurityType | Y |
| The security type or trade type:
| String(20) | ||
| 188 | BidSpotRate | N | — | Bid spot rate. Included only if Side (#54) in the originating Quote Request is 2-way for all trade types, sell for spot and outright trades, and buy for spot-fwd swaps.For Fixed Spot Roll (FSR): Must match the rate sent in the FSR Quote Request in Price (#44). If the quote rates do not match the customer-specified rate, the quotes are dropped and a Business Message Reject is sent to cancel the quote message. | Price(20) | ||
| 189 | BidForwardPoints | N | — | Bid forward points. The value is used for outrights and fwd/fwd swaps. Included only if Side (#54) in the originating Quote Request is sell or 2-way. | PriceOffset(20) | ||
| 190 | OfferSpotRate | N | — | Offer spot rate. Included only if Side (#54) in the originating Quote Request is 2-way for all trade types, buy for spot and outright trades, and sell for spot-fwd swaps. | Price(20) | ||
| 191 | OfferForwardPoints | N | — | Offer forward points. The value is used for outrights and fwd/fwd swaps. Included only if Side (#54) in the originating Quote Request is buy or 2-way. | PriceOffset(20) | ||
| 193 | SettlDate2 | N |
| FX spot, outright: Not applicable FX swap: The far leg value date The field contains either standard tenor symbol or a broken date in YYYYMMDD format. | LocalMktDate(8) | ||
| 537 | QuoteType | N | 0 (zero) or missing=Indicative (the quote is not tradable) 1=Tradable | Whether or not the quote is tradable. If this field is missing, the quote is indicative and not tradable. | int(1) | ||
| 541 | MaturityDate | See descr. | — | The fixing date for NDF trades and near leg of NDF swaps. This value can be either the Integral-provided fixing date or the fixing date generated by your system. Either this field or a value date SettlDate (#64) can be specified. If this field is omitted or empty, then the Integral-provided fixing date is used. If both this field and a value date is specified, then the value of this field must be before SettlDate (#64). | LocalMktDate(8) | ||
| 8541 | MaturityDate2 | See descr. | — | The far-leg fixing date for NDF swap trades. Either this field or a far value date SettlDate2 (#193) can be specified. If this field is omitted or empty, then the Integral-provided fixing date is used. If both this field and a value date is specified, then the value of this field must be before SettlDate2 (#193). | LocalMktDate(8) | ||
| 631 | MidPx | N | — | The near-leg all-in mid price. Only required when the receiving organization is required to receive Pre-Trade Mid-Market Mark. This decision is made by the maker. | Price(20) | ||
| 7631 | MidPxFl | N | — | The far-leg all-in mid price. Only required when the receiving organization is required to receive Pre-Trade Mid-Market Mark. This decision is made by the maker. | Price(20) | ||
| 642 | BidForwardPoints2 | N | — | Bid Forward Points for the far leg. The value is used for Swap and Fwd/Fwd Swap only. Included only if Side (#54) in the originating Quote Request is sell or 2-way. | PriceOffset(20) | ||
| 643 | OfferForwardPoints2 | N | — | Offer Forward Points for the far leg. The value is used for Swap and Fwd/Fwd Swap only. Included only if Side (#54) in the originating Quote Request is buy or 2-way. | PriceOffset(20) | ||
| 7551 | BidSize2 | N | — | Bid size of the far leg quote. Included only if Side (#54) in the originating Quote Request is sell or 2-way. | Qty(20) | ||
| 7552 | OfferSize2 | N | — | Offer size of the far leg quote. Included only if Side (#54) in the originating Quote Request is buy or 2-way. | Qty(20) | ||
| 22 | SecurityIDSource | See descr. | 4=ISIN number | (MiFID) Required if SecurityID (#48) is included. Identifies class or source of the SecurityID (#48) value. | String(1) | ||
| 48 | SecurityID | N | — | (MiFID) Required if SecurityIDSource (#22) is included. Security identifier value. For swaps, the near- and far-leg values are comma separated (nearLegISIN,farLegISIN). | String(12) | ||
| 453 | NoPartyIDs | N | 3 | (MiFID) For quotes on an MTF, the repeating groups represent the following entities :
| NumInGroup(1) | ||
| → | 448 | PartyID | See descr. | — | (MiFID) Required if NoPartyIDs (#453) is included. For quotes on an MTF, this field has the following value based on entity type:
| String(20) | |
| → | 447 | PartyIDSource | See descr. | N=LEI P=Short Code | (MiFID) Required if NoPartyIDs (#453) is included. For quotes on an MTF, this field has the following value based on entity type:
| char(1) | |
| → | 452 | PartyRole | See descr. | 12=Executing Trader 35=Liquidity Provider 122=Investment Decision Maker | (MiFID) Required if NoPartyIDs (#453) is included. For quotes on an MTF, this field has the following value based on entity type:
| int(2) | |
| → | 2376 | PartyRoleQualifier | See descr. | 22=Algorithm 24=Originating user | (MiFID) For quotes on an MTF, the user type. Only required for Executing Trader (PartyRole (#452)= 12) and Investment Decision Maker (PartyRole (#452)= 122). | int(2) | |
(Maker to Integral)
The maker sends a Quote Cancel message to Integral to stop an RFS quote stream and cancel all quotes.
Quote Cancel message fields
| Tag | Name | Req’d | Values | Description | Type(length) |
|---|---|---|---|---|---|
| 35 | MsgType | Y | Z | — | String(2) |
| 52 | SendingTime | Y | — | All messages sent from the maker to Integral must include millisecond precision: YYYYMMDD-HH:MM:SS.sss | UTCTimestamp(21) |
| 60 | TransactTime | Y | YYYYMMDD-HH:MM:SS.sss | The time the message was generated. | UTCTimestamp(21) |
| 117 | QuoteID | Y | Empty | This field must be included as a single space character. The entire RFS quote stream is canceled by the maker. | String(20) |
| 131 | QuoteReqID | N | — | The QuoteReqID (#131) of the originating quote request. This field may be left blank. | String(20) |
| 298 | QuoteCancelType | Y | — | 4=Quote Withdrawn, used when the quote stream is canceled by the maker 5=Quote/Request Expired, used when the request or quote expiry is reached 6=Request Withdrawn, used when the originating request has been withdrawn by the customer | int(1) |
| 7540 | StreamID | N | — | The ID for the stream agreed by Integral and the maker. If the maker does not support multi-stream pricing, this field is not included or is left empty. | String(30) |
The messages in this section are used to access the trading workflow of the API.
(Integral to Maker)
Integral sends a New Order – Single message to submit an order to the maker.
Groups of associated fields are indicated by arrows in the table below.
New Order – Single message fields
| Tag | Field name | Req’d | Valid values | Description | Type(length) | ||
|---|---|---|---|---|---|---|---|
| 35 | MsgType | Y | D | — | String(2) | ||
| 1 | Account | Y | — | The account ID. The value of this field is agreed upon by your organization and Integral. | String(30) | ||
| 11 | ClOrdID | Y | — | A session-scoped unique order ID assigned by Integral. | String(11) | ||
| 15 | Currency | Y | — | The dealt currency. This may be the base or term currency of a currency pair. | String(3) | ||
| 21 | HandlInst | Y | 1 (one) | Instructions for order handling on the broker trading floor. The value of this field is always: 1=Automated execution order, private, no Broker intervention | char(1) | ||
| 38 | OrderQty | Y | — | FX spot, outright, NDF: The amount of the dealt currency (as specified by the Currency (#15) field) to be either bought or sold (as determined by the Side (#54) field).FX swap: The near leg currency amount of the dealt currency (as specified by the Currency (#15) field) to be either bought or sold (as determined by the Side (#54) field). | Qty(20) | ||
| 40 | OrdType | Y | D=Previously quoted 2=Limit 1=Market | Other order types are not currently supported. See Supported order types. | char(1) | ||
| 44 | Price | Y | — | FX spot, outright, NDF: The execution price or limit price. The precision of this float value must be agreed upon by both the sending and the receiving parties. For outrights and NDFs this is the all-in price. FX swap: The near-leg execution price or limit price. The precision of this float value must be agreed upon by both the sending and the receiving parties. | Price(20) | ||
| 7633 | ForwardPoints | N | — | Forward points. Applicable when SecurityType (#167)=FXFWD or FXNDF. | PriceOffset(20) | ||
| 54 | Side | Y | 1=Buy (Bid) 2=Sell (Offer) | FX spot, outright, NDF: The side of the order from the customer’s perspective and in terms of the dealt currency Currency (#15).FX swap: The side of the far leg. | char(1) | ||
| 55 | Symbol | Y | — | The symbol for the base and variable currencies of the currency pair in the following format: baseCurrency/termCurrency (for example, “EUR/USD”) For inverted quotes, this field should be specified as: termCurrency/baseCurrency (for example, “USD/EUR”) | String(35) | ||
| 58 | Text | N | — | Free format text string | String(150) | ||
| 59 | TimeInForce | Y |
| See Order expiry for a description of order expiry types. 0=Day 3=IOC 4=FOK 6=GTT/GTD | char(1) | ||
| 126 | ExpireTime | C | — | Required when TimeInForce (#59)=6(GTT/GTD).The expiry time in the format YYYYMMDD-hh:mm:ss.sss. For example, to set the order to expire at 17:00 on August 14th, 2025, you would specify 126=20250814-17:00:00.000. | UTCTimestamp(21) | ||
| 60 | TransactTime | Y | — | Time automatically stamped by the server that this order request was initiated/released by the trader, trading system, or intermediary in the format: YYYYMMDD-HH:MM:SS.sss | UTCTimestamp(21) | ||
| 64 | SettlDate | Y | See descr. |
|
| ||
| 110 | MinQty | N |
| This field is sent only if the incoming customer order specifies a minimum quantity. This field can be ignored if TimeInForce (#59) is 4 (FOK).Specifies how the order can be filled:
| Qty(20) | ||
| 117 | QuoteID | See descr. | — | This is only required for OrdType (#40)=D (previously quoted) orders. The reference ID of the bid or offer dealing price. | String(11) | ||
| 167 | SecurityType | Y |
| The security type or trade type:
| String(20) | ||
| 132 | BidPx | N | — | This field is only applicable to the RFS workflow. All-in bid price. Included only if Side (#54) in the originating Quote Request is 2-way for all trade types, sell for spot and outright trades, and buy for swaps.
| Price(20) | ||
| 133 | OfferPx | N | — | This field is only applicable to the RFS workflow. All-in offer price. Included only if Side (#54) in the originating Quote Request is 2-way for all trade types, buy for spot and outright trades, and sell for swaps.
| Price(20) | ||
| 188 | BidSpotRate | N | — | This field is only applicable to the RFS workflow. Bid spot rate. Included only if Side (#54) in the originating Quote Request is 2-way for all trade types, sell for spot and outright trades, and buy for spot-fwd swaps. | Price(20) | ||
| 189 | BidForwardPoints | N | — | This field is only applicable to the RFS workflow. Bid forward points. The value is used for outrights and fwd/fwd swaps. Included only if Side (#54) in the originating Quote Request is sell or 2-way. | PriceOffset(20) | ||
| 190 | OfferSpotRate | N | — | This field is only applicable to the RFS workflow. Offer spot rate. Included only if Side (#54) in the originating Quote Request is 2-way for all trade types, buy for spot and outright trades, and sell for spot-fwd swaps. | Price(20) | ||
| 191 | OfferForwardPoints | N | — | This field is only applicable to the RFS workflow. Offer forward points. The value is used for outrights and fwd/fwd swaps. Included only if Side (#54) in the originating Quote Request is buy or 2-way. | PriceOffset(20) | ||
| 192 | OrderQty2 | N | — | This field is only applicable to the RFS workflow. FX spot, outright: Not applicable. FX swap: The far leg currency amount of the dealt currency (as specified by the Currency (#15) field) to be either bought or sold (as determined by the Side (#54) field). | Qty(20) | ||
| 541 | MaturityDate | See descr. | — | The fixing date for NDF trades and near leg of NDF swaps. This value can be either the Integral-provided fixing date or the fixing date generated by your system. Either this field or a value date SettlDate (#64) can be specified. If this field is omitted or empty, then the Integral-provided fixing date is used. If both this field and a value date is specified, then the value of this field must be before SettlDate (#64). | LocalMktDate(8) | ||
| 8541 | MaturityDate2 | N | — | The far-leg fixing date for NDF swap trades. Either this field or a far value date SettlDate2 (#193) can be specified. If this field is omitted or empty, then the Integral-provided fixing date is used. If both this field and a value date is specified, then the value of this field must be before SettlDate2 (#193). | LocalMktDate(8) | ||
| 640 | Price2 | N | — | This field is only applicable to the RFS workflow. FX spot: Not applicable. FX swap: The far-leg execution price or limit price. The precision of this float value must be agreed upon by both the sending and the receiving parties. The precision of this value must be agreed upon by both the sending and receiving parties. | Price(20) | ||
| 7540 | StreamID | N | — | The ID for the stream agreed by Integral and the maker. If the maker does not support multi-stream pricing, this field is not included or is left empty. | String(30) | ||
| 22 | SecurityIDSource | See descr. | 4=ISIN number | (MiFID) Required if SecurityID (#48) is included. Identifies class or source of the SecurityID (#48) value. | String(1) | ||
| 48 | SecurityID | N | — | (MiFID) Required if SecurityIDSource (#22) is included. Security identifier value. For swaps, the near- and far-leg values are comma separated (nearLegISIN,farLegISIN). | String(12) | ||
| 453 | NoPartyIDs | N | 1 2 (MiFID) | The number of groups of PartyID (#448), PartyIDSource (#447) and PartyRole (#452) fields that represent the ClientTag on the trade request, if any. If this component is included in the message, the value of the NoPartyIDs (#453) field always has the value of 1 (one), indicating a ClientTag.(MiFID) For orders sent to an MTF, the repeating groups represent the following entities:
| NumInGroup(1) | ||
| → | 448 | PartyID | N | — | The ClientTag on the trade request. (MiFID) For orders sent to an MTF, this field has the following value based on entity type:
| String(20) | |
| → | 447 | PartyIDSource | See descr. | D=Proprietary/Custom code G=MIC N=LEI | Identifies class or source of the PartyID (#448) value. Required if PartyID is specified.(MiFID) For orders sent to an MTF, this field has the following value based on entity type:
| char(1) | |
| → | 452 | PartyRole | N | 3=Client ID 64=Multilateral Trading Facility 13=Order Originating Firm | Identifies the type or role of the PartyID (#448) specified.(MiFI D) For orders sent to an MTF, this field has the following value based on entity type:
| int(2) | |
| → | 802 | NoPartySubIDs | N | 1 | (MiFID) A repeating group to contain the venue’s LEI. | NumInGroup(1) | |
| →→ | 523 | PartySubID | See descr. | — | (MiFID) The venue’s LEI. Required if NoPartySubIDs (#802) is added. | String(20) | |
| 768 | NoTrdRegTimestamps | See descr. | 1 | (MiFID) Regulatory timestamp in the format YYYYMMDD-HH:MM:SS.sss, required for MTF trading activity | NumInGroup(1) | ||
| → | 769 | TrdRegTimestamp | See descr. | — | (MiFID) Regulatory timestamp in the format YYYYMMDD-HH:MM:SS.sss, required for MTF trading activity | UTCTimestamp(21) | |
| → | 770 | TrdRegTimestampType | See descr. | 10=Order submission time | (MiFID) Regulatory timestamp type | int(2) | |
| 1839 | TradePriceCondition | N | 15=Non-price forming trade. | (MiFID) Price conditions in effect at the time of the order. | int(2) | ||
| 2668 | NoTrdRegPublications | N | Up to 3 | (MiFID) Number of regulatory publication rules in repeating group. | NumInGroup(1) | ||
| → | 2669 | TrdRegPublicationType | N | 0=Pre-trade transparency waiver 1=Post-trade deferral 2=Exempt from Publication | (MiFID) Specifies the type of regulatory trade publication. | char(1) | |
| → | 2670 | TrdRegPublicationReason | N | 4=No public price quoted as instrument is illiquid 7=Deferral due to "Illiquid Instrument" 11=Exempted due to securities financing transaction | (MiFID) Additional reason for trade publication type specified in TrdRegPublicationType (#2669). Reasons may be specific to regulatory trade publication rules. | char(1) | |
(Integral to Maker)
Integral sends this message to the maker to request an Execution Report be sent with the order’s current status. You should respond with an Execution Report message with the order's status and with the following fields set with values from the request when available:
ClOrdID(#11)OrderID(#37)OrdStatusReqID(#790)
Order Status Request message fields
| Tag | Name | Req’d | Values | Description | Type(length) |
|---|---|---|---|---|---|
| 35 | MsgType | Y | H | — | String(2) |
| 790 | OrdStatusReqID | N | — | Optional, can be used to uniquely identify a specific Order Status Request message. Returned on Execution Report if provided. | String(11) |
| 11 | ClOrdID | See descr. | — | Required by the FIX specification, but not required by the FIX Maker ESP API. The unique ID assigned by Integral to the order, the ClOrdID (#11) of the originating New Order – Single message. This field is ignored if OrderID (#37) is included. | String(11) |
| 37 | OrderID | N | — | The order’s ID as assigned by Integral. If this field is included, the ClOrdID (#11) field is ignored. | String(20) |
| 54 | Side | Y | — | The order side from customer’s perspective. For FX swap, it is the side of the far leg. 1=Buy (Bid) 2=Sell (Offer) This should be the same value as the one received from the associated New Order - Single message. | char(1) |
| 55 | Symbol | N | — | The symbol for the base and variable currencies of the currency pair in the following format: baseCCY/variableCCY (for example, “EUR/USD”) | String(35) |
(Integral to Maker)
Integral sends this message to the maker to request cancellation of a previously submitted order.
You should respond with two Execution Report messages in the following order:
- Execution Report (pending cancel):
ExecType(#150)=6 andOrdStatus(#39)=6 - Execution Report (canceled):
ExecType(#150)=4 andOrdStatus(#39)=4
The following fields on the Execution Report should be set with values from the request when available:
ClOrdID(#11)OrderID(#37)
Order Cancel Request message fields
| Tag | Name | Req’d | Values | Description | Type(length) |
|---|---|---|---|---|---|
| 35 | MsgType | Y | F | — | String(2) |
| 41 | OrigClOrdID | Y | — | The ClOrdID (#11) of the original order to be canceled. | String(11) |
| 11 | ClOrdID | See descr. | — | Unique ID of the cancel request. | String(11) |
| 37 | OrderID | N | — | The order’s ID as assigned by Integral. | String(20) |
| 54 | Side | Y | — | The order side from customer’s perspective. For FX swap, it is the side of the far leg. 1=Buy (Bid) 2=Sell (Offer) This should be the same value as the one received from the associated New Order - Single message. | char(1) |
| 55 | Symbol | N | — | The symbol for the base and variable currencies of the currency pair in the following format: baseCCY/variableCCY (for example, “EUR/USD”) | String(35) |
| 60 | TransactTime | Y | — | The timestamp of the Execution Report creation in the format: YYYYMMDD-HH:MM:SS.sss | UTCTimestamp(21) |
(Integral to Maker)
When Integral is configured to automatically cancel timed-out orders, this message is sent to inform the maker that Integral did not receive an Execution Report message response (either an order rejection or a trade verification) for the order within the time-out period. The original order is effectively rejected. If Integral receives a trade verification or rejection after the order has been timed out, Integral sends a Don’t Know Trade message to the maker. This order time-out conversation happens in an order session. See Order timeout for more information about the order timeout workflow.
Order Timeout message fields
| Tag | Name | Req’d | Values | Description | Type(length) |
|---|---|---|---|---|---|
| 35 | MsgType | Y | OT | — | String(2) |
| 11 | ClOrdID | Y | — | The unique ID assigned by Integral to the order, the ClOrdID (#11) of the originating New Order – Single message. This is the order for which no response was received. | String(11) |
(Integral to Maker)
The Don’t Know Trade (DK) message is sent to the maker if a fill, rejection, or any other terminal-state message is received by Integral for an order that has been timed out. See Order timeout for more information about the order timeout workflow.
Don’t Know Trade (DK) message fields
| Tag | Field Name | Req’d | Values | Description | Type(length) |
|---|---|---|---|---|---|
| 35 | MsgType | Y | Q | — | String(2) |
| 17 | ExecID | Y | — | The maker’s unique trade ID of problem execution | String(20) |
| 54 | Side | See descr. | — | Required by the FIX specification, but not required by the FIX Maker RFS API. This field is included if it is present in the Execution Report from the maker. .The trade’s side from customer’s perspective. For FX swap, it is the side of the far leg. 1=Buy (Bid) 2=Sell (Offer) | char(1) |
| 37 | OrderID | Y | — | The maker’s order ID on the problem execution | String(20) |
| 55 | Symbol | Y | — | The symbol for the base and variable currencies of the currency pair in the following format: baseCCY/variableCCY (for example, “EUR/USD”) | String(35) |
| 127 | DKReason | Y | D | Reason for execution rejection. D=No matching order | char(1) |
(Maker to Integral)
The maker sends an Execution Report message for the following events:
- Order filled/partially filled.
- Order status request received from Integral.
- Order cancellation in response to a cancel request.
The combination of the OrdStatus (#39) and ExecType (#150) fields indicate the current state of the order. See Order state transition for more information about order status.
Execution Report message fields
| Tag | Field name | Req’d | Values | Description | Type(length) | |
|---|---|---|---|---|---|---|
| 35 | MsgType | Y | 8 | — | String(2) | |
| 52 | SendingTime | Y | — | All messages sent from the maker to Integral must include millisecond precision: YYYYMMDD-HH:MM:SS.sss | UTCTimestamp(21) | |
| 37 | OrderID | Y | — | The unique order ID assigned by your organization. | String(20) | |
| 11 | ClOrdID | Y | — | A unique order ID assigned by Integral. It is the same value as sent by the customer in:
| String(11) | |
| 790 | OrdStatusReqID | N | — | Uniquely identifies a specific Order Status Request message sent by Integral. Required if the Execution Report is a response to an Order Status Request. The ExecType (#150) is I=Order Status for this Execution Report. | String(1) | |
| 17 | ExecID | Y | — | Unique ID for each order execution report. | String(20) | |
| 40 | OrdType | N | D=Previously quoted 2=Limit 1=Market\ | The order type. See Supported order types. | char(1) | |
| 150 | ExecType | Y | — | Describes the type of execution report. These are the state transition events illustrated in Order state transitions except Order Status: A=Pending new 0=New 4=Canceled 6=Pending Cancel 8=Rejected C=Expired F=Trade I=Order Status 2=Fill | char(1) | |
| 39 | OrdStatus | Y | — | Describes the current state of the order. The value 4=Canceled is not applicable to the API. Valid values: A=Pending New 0=New (outstanding) 1=Partial Fill (after order matching) 2=Filled (after order matching) 4=Canceled 6=Pending Cancel 8=Rejected (before or after order matching) C=Expired | char(1) | |
| 103 | OrdRejReason | N | — | Code to identify reason for order rejection. Valid values: 0=Broker / Exchange option 1=Unknown symbol 2=Exchange closed 3=Order exceeds limit 4=Too late to enter 5=Unknown Order 6=Duplicate Order (duplicate ClOrdID (#11))7=Duplicate of a verbally communicated order 8=Stale Order 9=Trade Along required 10=Invalid Investor ID 11=Unsupported order characteristic 12=Surveillance Option | int(2) | |
| 1 | Account | N | — | The account ID. The value of this field is agreed upon by your organization and Integral. | String(30) | |
| 32 | LastQty | See descr. | — | For fills or partial fills, the quantity bought or sold on this fill. If a fill or partial fill is received with this field not specified or set to zero, Integral rejects it with a Business Message Reject message. | Qty(20) | |
| 119 | SettlCurrAmt | Y | — | FX spot, outright, NDF: Settled amount in terms of settlement currency specified by the SettlCurrency (#120) field.FX swap: Near-leg settled amount in terms of settlement currency specified by the SettlCurrency (#120) field. | Amt(20) | |
| 120 | SettlCurrency | Y | — | FX spot, outright, NDF: Settled currency FX swap: Settled currency of the far leg | Currency(3) | |
| 64 | SettlDate | See descr. | See descr. | This field is required for all fills (ExecType (#150)=2). Settlement date on the fill message at the maker’s end in YYYYMMDD format.
| LocalMktDate(8) | |
| 55 | Symbol | Y | — | The symbol for the base and variable currencies of the currency pair in the following format: baseCCY/variableCCY (for example, “EUR/USD”) This should be the same value as the one received from the associated New Order - Single message. | String(35) | |
| 54 | Side | Y | — | The order side from customer’s perspective. For FX swap, it is the side of the far leg. 1=Buy (Bid) 2=Sell (Offer) This should be the same value as the one received from the associated New Order - Single message. | char(1) | |
| 38 | OrderQty | N | — | FX spot, outright: The total quantity ordered FX swap: Near-leg total quantity ordered | Qty(20) | |
| 44 | Price | N | — | Do not use this field to determine the price of a fill. Use LastPx (#31) instead. This should be the same value as the one received from the associated New Order - Single message.The precision of this float value must be agreed upon by both the sending and the receiving parties FX spot, outright, NDF: Spot price. FX swap: Near-leg execution price. | Price(20) | |
| 15 | Currency | N | — | The dealt currency (near-leg currency for swap). This may be the base or term currency of a currency pair. | String(3) | |
| 167 | SecurityType | Y |
| The security type or trade type:
| String(20) | |
| 60 | TransactTime | Y | — | The timestamp of the Execution Report creation. The format is: YYYYMMDD-HH:MM:SS.sss | UTCTimestamp(21) | |
| 59 | TimeInForce | N | 0=Day 1=GTC 3=IOC 4=FOK 6=GTD | The time-in-force of the order. See Order Expiry. | char(1) | |
| 151 | LeavesQty | Y | — | Amount not filled (equals OrderQty (#38) minus CumQty (#14)FX spot, outright, NDF: Open amount. Responses for a complete fill or rejection are “0” (zero). Any value other than zero indicates a partial fill. FX swap: Near-leg open amount | Qty(20) | |
| 14 | CumQty | Y | — | FX spot, outright, NDF: Total filled amount. If OrdStatus (#39)=F (partial fill), this value is total amount filled at the time of the current fill. If OrdStatus (#39)=2 (filled), the value of this field is the same as the OrderQty (#38) field. If OrdStatus (#39)=8 (rejected), the value of this field is “0” (zero).FX swap: Near-leg total filled amount. If the OrdStatus (#39) field is “2”, the value of this field is the same as the OrderQty (#38) field. If the OrdStatus (#39) field is “8”, the value of this field is “0” (zero). | Qty(20) | |
| 31 | LastPx | See descr. | — | The price of a fill to ensure trade reconciliation and to determine any price improvement. FX spot, outright, NDF: Price at which the current or last fill was made. FX swap: Near-leg price at which the current or last fill was made. | Price(20) | |
| 194 | LastSpotRate | See descr. | — | If an RFS quote has points, the corresponding Execution Report must include this field. If the RFS quote does not include points, this field is not required. FX spot: Not applicable. FX outright or NDF: Spot rate FX swap: Near-leg spot rate | Price(20) | |
| 195 | LastForwardPoints | See descr. | — | If an RFS quote has points, the corresponding Execution Report must include this field. If the RFS quote does not include points, this field is not required. FX spot: Not applicable. FX outright or NDF: Forward points FX swap: Near-leg forward points | PriceOffset(20) | |
| 6 | AvgPx | Y | — | The average execution price for the filled amount specified in CumQty (#14) field). If this field is set, then the CumQty (#14) field must be set to a non-zero value to avoid errors. The precision of this float value must be agreed upon by both the sending and the receiving parties. Do not use this field to determine the price of a fill. Use LastPx (#31) instead. | Price(20) | |
| 193 | SettlDate2 | N | — | FX spot, outright: Not applicable FX swap: The far leg value date The field contains a date in YYYYMMDD format. | LocalMktDate(8) | |
| 192 | OrderQty2 | N | — | FX spot, outright: Not applicable. FX swap: The far leg dealt amount of the dealt currency (as specified by the Currency (#15) field). | Qty(20) | |
| 541 | MaturityDate | See descr. | — | The fixing date for NDF trades and near leg of NDF swaps. This value can be either the Integral-provided fixing date or the fixing date generated by your system. Either this field or a value date SettlDate (#64) can be specified. If this field is omitted or empty, then the Integral-provided fixing date is used. If both this field and a value date is specified, then the value of this field must be before SettlDate (#64). | LocalMktDate(8) | |
| 8541 | MaturityDate2 | See descr. | — | The far-leg fixing date for NDF swap trades. Either this field or a far value date SettlDate2 (#193) can be specified. If this field is omitted or empty, then the Integral-provided fixing date is used. If both this field and a value date is specified, then the value of this field must be before SettlDate2 (#193). | LocalMktDate(8) | |
| 640 | Price2 | N | — | FX spot: Not applicable. FX swap: The far-leg execution price. The precision of this float value must be agreed upon by both the sending and the receiving parties. | Price(20) | |
| 641 | LastForwardPoints2 | N | — | FX spot: Not applicable. FX outright: Not applicable. FX swap: Far-leg forward points | PriceOffset(20) | |
| 7541 | LastPx2 | N | — | FX spot, outright: Not applicable. FX swap: Far-leg price at which the current or last fill was made. | Price(20) | |
| 7543 | LeavesQty2 | N | — | FX spot, outright: Not applicable. FX swap: Far-leg open amount | Qty(20) | |
| 7544 | CumQty2 | N | — | FX spot, outright: Not applicable. FX swap: Far-leg total filled amount. | Qty(20) | |
| 7545 | SettlCurrAmt | N | — | FX spot, outright: Not applicable. FX swap: Far-leg settled amount in terms of settlement currency specified by the Currency (#15) field. | Amt(20) | |
| 58 | Text | N | — | Free format text explaining the reason for rejection if the Order Execution Report message is sent because of order rejection (the ExecType (#150) field=“8”).If the Text (#58) field includes the text “INTERNAL_SERVER_ERROR”, this indicates a serious error. Stop trading immediately and contact Business Support to resolve the issue. | String(150) | |
| 75 | TradeDate | N | — | The trade date (YYYYMMDD) | LocalMktDate(8) | |
| 22 | SecurityIDSource | See descr. | 4=ISIN number | (MiFID) Required if SecurityID (#48) is included. Identifies class or source of the SecurityID (#48) value. | String(1) | |
| 48 | SecurityID | N | — | (MiFID) Required if SecurityIDSource (#22) is included. Security identifier value. For swaps, the near- and far-leg values are comma separated (nearLegISIN,farLegISIN). | String(12) | |
| 957 | NoStrategyParameters | N | — | Number of strategy parameters in this repeating group. | NumInGroup(3) | |
| → | 958 | StrategyParameterName | N | — | Name of the parameter. | String(255) |
| → | 959 | StrategyParameterType | N | See descr. | Datatype of the parameter. 1=Int 2=Length 3=NumInGroup 4=SeqNum 5=TagNum 6=Float 7=Qty 8=Price 9=PriceOffset 10=Amt 11=Percentage 12=Char 13=Boolean 14=String 15=MultipleCharValue 16=Currency 17=Exchange 18=Month-Year 19=UTCTimeStamp 20=UTCTimeOnly 21=LocalMktDate 22=UTCDateOnly 23=Data 24=MultipleStringValue | int(2) |
| → | 960 | StrategyParameterValue | N | — | Value of the parameter. | String(1023) |
| 768 | NoTrdRegTimestamps | See descr. | 1 | (MiFID) Regulatory timestamp in the format YYYYMMDD-HH:MM:SS.sss, required for MTF trading activity | NumInGroup(1) | |
| → | 769 | TrdRegTimestamp | See descr. | — | (MiFID) Regulatory timestamp in the format YYYYMMDD-HH:MM:SS.sss, required for MTF trading activity | UTCTimestamp(21) |
| → | 770 | TrdRegTimestampType | See descr. | 1=Execution time | (MiFID) Regulatory timestamp type | int(2) |
| 29 | LastCapacity | N | 1=Agent (AOTC, any other capacity) 3=Cross as Principal (MTCH, matched principal) 4=Riskless Principal (DEAL, dealing on own account) | (MiFID) Maker’s Trading Capacity | char(1) | |
| 453 | NoPartyIDs | N | 3 | (MiFID) Repeating group identifying:
| NumInGroup(1) | |
| → | 448 | PartyID | N | See descr. | (MiFID) Party ID
| String(20) |
| → | 447 | PartyIDSource | Y | N=LEI 447=N P=Short Code 447=N | (MiFID) For trades done on an MTF, this field has the following value based on entity type:
| char(1) |
| → | 452 | PartyRole | Y | 12=Executing Trader 35=Liquidity Provider 122=Investment Decision Maker | (MiFID) For trades done on an MTF, this field has the following value based on entity type:
| int(2) |
| → | 2376 | PartyRoleQualifier | See descr. |
| (MiFID) User role qualifier.
| int(2) |
| → | 802 | NoPartySubIDs | See descr. | 2 | (MiFID) Required when PartyRole (#452)= 35 (Liquidity Provider). The number of repeating groups that indicate whether or not the trade was done by a Systematic Internaliser (SI) and, if true, includes the SI venue’s MIC and the maker’s branch ISO country code. | NumInGroup(1) |
| →→ | 523 | PartySubID | See descr. | — | (MiFID) Required if NoPartySubIDs (#802) is included.If PartySubIDType (#803)=76 (Systematic Internaliser):
| String(20) |
| →→ | 803 | PartySubIDType | See descr. | 32=Execution venue 70=Location or jurisdiction 76=Systematic Internaliser | (MiFID) Required if NoPartySubIDs (#802) is included. | int(2) |
(Maker to Integral)
Execution Acknowledgment message fields
| Tag | Field name | Req'd | Values | Description | Type(length) | |
|---|---|---|---|---|---|---|
| 35 | MsgType | Y | BN | — | String(2) | |
| 37 | OrderID | Y | — | Unique identifier for the order assigned by Integral. | String(20) | |
| 11 | ClOrdID | Y | — | Unique identifier for the order assigned by the customer. It is the same value as sent by the client in the order message or Order Cancel Request message. | String(11) | |
| 1036 | ExecAckStatus | Y | 0=Received, not yet processed 1=Accepted 2 =Don't know / Rejected | Indicates the status of the execution acknowledgment. | char(1) | |
| 17 | ExecID | Y | — | Unique ID for the execution message. | String(20) | |
| 127 | DKReason | — | A=Unknown Symbol B=Wrong Side C=Quantity Exceeds Order D=No Matching OrderD E=Price Exceeds Limit F=Calculation Difference Z=Other | Conditionally required when ExecAckStatus (#1036)= 2 (Don't know / Rejected). | char(1) | |
| 54 | Side | Y | 1=Buy (Bid) 2=Sell (Offer) | The side of the order from the customer’s perspective. For FX swap orders, this is the side of the far leg. This should be the same value as was sent on the order message. | char(1) | |
| 55 | Symbol | Y | — | The symbol for the base and variable currencies of the currency pair in the format baseCCY/variableCCY (for example, EUR/USD”) This should be the same value as the one received from the associated message. | String(35) | |
| 22 | SecurityIDSource | N | 4=ISIN number | (MiFID) Identifies class or source of the SecurityID (#48) value. | String(1) | |
| 48 | SecurityID | N | — | (MiFID) Required if SecurityIDSource (#22) is included. Security identifier value. For swaps, the near- and far-leg values are comma separated (nearLegISIN,farLegISIN). | String(12) | |
| 768 | NoTrdRegTimestamps | C | 2 | (MiFID) Regulatory timestamps in the format YYYYMMDD-HH:MM:SS.sss, required for MTF trading activity. | NumInGroup(1) | |
| → | 769 | TrdRegTimestamp | C | — | (MiFID) Regulatory timestamp in the format YYYYMMDD-HH:MM:SS.sss, required for MTF trading activity | UTCTimestamp(21) |
| → | 770 | TrdRegTimestampType | C | 1=Execution Time 10=Order Submission Time | (MiFID) Regulatory timestamp type, required if TrdRegTimestamp (#769) is specified | int(1) |
(Bidirectional)
The Business Message Reject message is sent by both Integral and the maker:
- The maker rejects an order status request if the order does not exist (
RefMsgType(#372)=H). See Orders workflow. - The maker rejects an order cancel request if the order does not exist (
RefMsgType(#372)=F). See Orders workflow. - Integral sends to cancel a Quote Request (
RefMsgType(#372)=Z). See Request for stream (RFS) workflow. - For Fixed Spot Rolls (FSRs), if the quote rates do not match the customer-specified rate, the quotes are dropped and a Business Message Reject is sent to cancel the quote message. See Price.
- If an Execution Report message for a fill or partial fill is received with the
LastQty(#32) field not specified or set to zero, Integral rejects it with a Business Message Reject message. See LastQty.
Business Message Reject message fields
| Tag | Field Name | Req’d | Value | Description | Type(length) |
|---|---|---|---|---|---|
| 35 | MsgType | Y | j | — | String(2) |
| 52 | SendingTime | Y | — | All messages sent from the maker to Integral must include millisecond precision: YYYYMMDD-HH:MM:SS.sss | UTCTimestamp(21) |
| 372 | RefMsgType | Y |
| The MsgType (#35) of the message referred to:H=Order Status Request (from server to reject an order status request if the order does not exist) F=Order Cancel Request Z=Quote Cancel (from client to cancel a Quote Request) | String(2) |
| 379 | BusinessRejectRefID | N | — | If the message is sent in response to an order status request (RefMsgType (#372)=H), this field contains the ClOrdID (#11) of the order status request being rejected.If the message is sent to cancel an order ( RefMsgType (#372)=F), this field contains the ClOrdID (#11) of the order being canceled.If the message is sent to cancel a quote request ( RefMsgType (#372)=Z), this field contains the QuoteID (#117) of the quote being canceled. | String(11) |
| 380 | BusinessRejectReason | Y |
| The reason for a Business Message Reject message. Required only for the order status reject from the maker. 1=Unknown ID is supported 5=Conditionally Required Field Missing | int(1) |
| 58 | Text | N | — | Free-format text string | String(150) |
The FIX protocol uses the non-printing ASCII "Start of Heading" (SOH) character (also shown as "Control A" or "^A") as the delimiter between tags in the message.
The following examples replace the SOH character with "| " (pipe and space) characters so that the delimiters are visible and examples break across lines.
8=FIX.4.3| 9=78| 35=A| 34=1| 49=demo.fxgrid| 52=20250624-09:50:57.031| 56=order.MakerOrg| 98=0| 108=30| 141=N| 10=107|
8=FIX.4.3| 9=78| 35=A| 34=1| 49=demo.fxgrid| 52=20250624-09:50:57.032| 56=price.MakerOrg| 98=0| 108=30| 141=Y| 10=090|
8=FIX.4.3| 9=78| 35=A| 34=1| 49=order.MakerOrg| 52=20250624-09:50:56.967| 56=demo.fxgrid| 98=0| 108=30| 141=Y| 10=124|
8=FIX.4.3| 9=78| 35=A| 34=1| 49=price.MakerOrg| 52=20250624-09:50:56.968| 56=demo.fxgrid| 98=0| 108=30| 141=Y| 10=107|
8=FIX.4.3| 9=78| 35=5| 34=109| 49=demo.fxgrid| 52=20250624-13:58:16.225| 56=order.MakerOrg| 10=133|
8=FIX.4.3| 9=77| 35=5| 34=93| 49=demo.fxgrid| 52=20250624-13:58:16.225| 56=price.MakerOrg| 10=087|
8=FIX.4.4| 9=75| 35=5| 34=2889| 49=demo.maker| 52=20250704-21:01:00.971| 56=price.MakerOrg| 58=Unknown user ID| 10=100|
8=FIX.4.3| 9=78| 35=5| 34=135| 49=order.MakerOrg| 52=20250624-13:58:16.155| 56=demo.fxgrid| 10=134|
8=FIX.4.3| 9=80| 35=5| 34=17098| 49=price.MakerOrg| 52=20250624-13:58:16.155| 56=demo.fxgrid| 10=240|
8=FIX.4.3| 9=66| 35=0| 34=4| 49=order.MakerOrg| 52=20250624-09:51:27.963| 56=demo.fxgrid| 10=077|
8=FIX.4.3| 9=66| 35=0| 34=5| 49=demo.fxgrid| 52=20250624-09:52:27.989| 56=order.MakerOrg| 10=087|
8=FIX.4.3| 9=107| 35=2| 34=240| 49=price.MakerOrg| 52=20250704-10:01:56.324| 56=demo.fxgrid| 7=2647| 16=0| 10=229|
8=FIX.4.3| 9=137| 35=4| 34=2672| 43=Y| 49=demo.fxgrid| 52=20250704-10:02:04.098| 56=price.MakerOrg| 122=20250704-10:02:04| 36=2680| 123=Y| 10=214|
8=FIX.4.3| 9=169| 35=3| 34=11| 49=order.MakerOrg| 50=FI220LE| 52=20250705-14:14:34.070| 56=demo.fxgrid| 57=DBNB| 128=orgID| 45=13| 58=Invalid tag number| 371=50| 372=8| 373=0| 10=113|
8=FIX.4.3| 9=105| 35=1| 34=1089| 49=demo.fxgrid| 52=20250705-09:06:30.882| 56=price.MakerOrg| 112=TEST| 10=034|
8=FIX.4.3| 9=230| 35=R| 34=1024| 49=quote.demo.fxgrid| 52=20250605-06:00:15.600| 56=price.MakerOrg| 1=MakerAccnt| 131=FXI57410456| 7540=Stream1| 146=1| 55=EUR/USD| 167=FOR| 54= | 38=1245000| 64=Spot| 40=D| 126=00000000-00:02:00| 60=20250605-06:00:15.600| 15=USD| 10=158|
8=FIX.4.3| 9=234| 35=R| 34=1499| 49=quote.demo.fxgrid| 52=20250605-09:00:55.237| 56=price.MakerOrg| 1=MakerAccnt| 131=FXI57412064| 7540=Stream1| 146=1| 55=EUR/USD| 167=FOR| 54=1| 38=1000000| 64=20150131| 40=D| 126=00000000-00:02:00| 60=20250605-09:00:55.237| 15=USD| 10=179|
8=FIX.4.3| 9=248| 35=R| 34=207| 49=quote.demo.fxgrid| 52=20250605-23:08:12.263| 56=price.MakerOrg| 1=MakerAccnt| 131=FXI57412211| 7540=Stream1| 146=1| 55=EUR/USD| 167=FOR| 54=2| 38=2000000| 64=Spot| 40=G| 193=1W| 192=1000000| 126=00000000-00:02:00| 60=20250605-23:08:12.263| 15=EUR| 10=008|
8=FIX.4.3| 9=259| 35=R| 34=1651| 49=quote.demo.fxgrid| 52=20250605-10:10:54.162| 56=price.MakerOrg| 1=MakerAccnt| 131=FXI57412089| 7540=Stream1| 146=1| 55=EUR/USD| 167=FOR| 54=1| 38=2000000| 64=Spot| 40=G| 193=1M| 192=8000000| 126=00000000-00:02:00| 60=20250605-10:10:54.161| 15=EUR| 10=066|
8=FIX.4.3| 9=258| 35=R| 34=767| 49=quote.demo.fxgrid| 52=20250605-03:56:27.110| 56=price.MakerOrg| 1=MakerAccnt| 131=FXI57410448| 7540=Stream1| 146=1| 55=EUR/USD| 167=FOR| 54= | 38=1000000| 64=20250614| 40=G| 193=20150131| 192=1000000| 126=00000000-00:02:00| 60=20250605-03:56:27.110| 15=EUR| 10=005|
8=FIX.4.3| 9=131| 35=Z| 34=768| 49=quote.demo.fxgrid| 52=20250605-03:56:32.804| 56=price.MakerOrg| 60=20250605-03:56:32.804| 117= | 131=FXI57410448| 298=6| 7540=Stream1| 10=026|
8=FIX.4.3| 9=271| 35=S| 34=736797| 49=price.MakerOrg| 52=20250605-07:13:03.719| 56=quote.demo.fxgrid| 15=USD| 40=D| 54=1| 55=EUR/USD| 60=20250605-07:13:03.719| 62=00000000-00:00:30.000| 64=20250614| 117=1307257984504| 131=FXI57412019| 132=1.1242762| 134=1000000| 167=FOR| 188=1.1254| 189=-0.0011238| 537=1| 10=105|
8=FIX.4.3| 9=271| 35=S| 34=725990| 49=price.MakerOrg| 52=20250605-07:04:31.483| 56=quote.demo.fxgrid| 15=EUR| 40=D| 54=2| 55=EUR/USD| 60=20250605-07:04:31.483| 62=00000000-00:00:30.000| 64=20250614| 117=1307257472251| 131=FXI57412016| 132=1.1242762| 134=1000000| 167=FOR| 188=1.1254| 189=-0.0011238| 537=1| 10=085|
8=FIX.4.3| 9=283| 35=S| 34=644117| 49=price.MakerOrg| 52=20250605-06:00:16.537| 56=quote.demo.fxgrid| 15=USD| 40=D| 54= | 55=EUR/USD| 60=20250605-06:00:16.536| 62=00000000-00:00:30.000| 64=Spot| 117=1307253616621| 131=FXI57410456| 132=1.1251| 133=1.1265| 134=1245000| 135=1245000| 167=FOR| 188=1.1251| 190=1.1265| 537=1| 10=043|
8=FIX.4.3| 9=661| 35=W| 34=651082| 49=price.MakerOrg| 52=20250605-06:05:47.418| 56=quote.demo.fxgrid| 55=USD/CHF| 262=FXLP1305c92fbd738| 541=20250606| 268=8| 269=1| 270=1.21993| 15=USD| 271=10000000| 276=A| 299=OFFER1.21993| 290=0| 269=0| 270=1.21992| 15=USD| 271=10000000| 276=A| 299=BID1.21992| 290=0| 269=1| 270=1.21993| 15=USD| 271=10000000| 276=A| 299=OFFER1.21993| 290=0| 269=0| 270=1.21992| 15=USD| 271=10000000| 276=A| 299=BID1.21992| 290=0| 269=1| 270=1.21993| 15=USD| 271=10000000| 276=A| 299=OFFER1.21993| 290=0| 269=0| 270=1.21992| 15=USD| 271=10000000| 276=A| 299=BID1.21992| 290=0| 269=1| 270=1.21993| 15=USD| 271=10000000| 276=A| 299=OFFER1.21993| 290=0| 269=0| 270=1.21992| 15=USD| 271=10000000| 276=A| 299=BID1.21992| 290=0| 10=023|
8=FIX.4.3| 9=249| 35=S| 34=650752| 49=price.MakerOrg| 52=20250605-06:05:31.269| 56=quote.demo.fxgrid| 15=EUR| 40=D| 54=2| 55=EUR/USD| 60=20250605-06:05:31.269| 62=00000000-00:00:30.000| 64=Spot| 117=1307253931359| 131=FXI57410457| 132=1.1251| 134=1245000| 167=FOR| 188=1.1251| 537=1| 10=025|
8=FIX.4.3| 9=310| 35=S| 34=752525| 49=price.MakerOrg| 52=20250605-07:25:30.250| 56=quote.demo.fxgrid| 15=EUR| 40=D| 54=1| 55=EUR/USD| 60=20250605-07:25:30.250| 62=00000000-00:00:30.000| 64=20250615| 117=1307258731038| 131=FXI57412020| 132=1.1239762| 134=1000000| 167=FOR| 188=1.1251| 189=-0.0011238| 193=20250622| 537=1| 643=-0.02671| 7552=1000000| 10=110|
8=FIX.4.3| 9=305| 35=S| 34=123325| 49=price.MakerOrg| 52=20250605-22:51:28.934| 56=quote.demo.fxgrid| 15=EUR| 40=D| 54=2| 55=EUR/USD| 60=20250605-22:51:28.933| 62=00000000-00:00:30.000| 64=TOD| 117=1307314291582| 131=FXI57412205| 133=1.126424| 135=2000000| 167=FOR| 190=1.1265| 191=-0.000076| 193=20250607| 537=1| 642=-0.0267231| 7551=1000000| 10=205|
8=FIX.4.3| 9=282| 35=D| 34=758| 49=quote.demo.fxgrid| 52=20250605-03:55:54.572| 56=order.MakerOrg| 1=MakerAccnt| 11=FXI57410446| 15=EUR| 21=1| 38=1000000| 40=D| 44=1.1242762| 54=1| 55=EUR/USD| 59=3| 60=20250605-03:55:54.572| 64=20250615| 117=1307246152505| 167=FOR| 192=1000000| 193=20250621| 640=1.09869| 7540=Stream1| 10=161|
8=FIX.4.3| 9=229| 35=8| 34=65| 49=order.MakerOrg| 52=20250505-21:35:34.528| 56=demo.fxgrid| 1=MakerAccnt1| 6=0| 11=FXI57002344| 14=0| 17=FXI57002344| 37=FXI57002344| 38=1000000| 39=A| 44=1.45455| 54=2| 55=EUR/USD| 60=20250505-21:35:34| 119=0| 120=USD| 150=0| 151=0| 167=FOR| 10=180|
8=FIX.4.3| 9=229| 35=8| 34=66| 49=order.MakerOrg| 52=20250505-21:35:34.530| 56=demo.fxgrid| 1=MakerAccnt1| 6=0| 11=FXI57002344| 14=0| 17=FXI57002344| 37=FXI57002344| 38=1000000| 39=0| 44=1.45455| 54=2| 55=EUR/USD| 60=20250505-21:35:34| 119=0| 120=USD| 150=0| 151=0| 167=FOR| 10=157|
8=FIX.4.3| 9=219| 35=D| 34=5| 49=demo.fxgrid| 52=20250518-21:28:47.037| 56=order.MakerOrg| 1=MakerAccnt| 11=FXI57748726| 15=EUR| 21=1| 38=1000000| 40=D| 44=1.4048| 54=2| 55=EUR/USD| 59=3| 60=20250518-21:28:47.036| 117=27 718040708200504334| 167=FOR| 7540=Stream1| 10=225|
8=FIX.4.3| 9=253| 35=8| 34=6| 49=order.MakerOrg| 52=20250518-21:28:47.081| 56=demo.fxgrid| 1=MakerAccnt| 6=0| 11=FXI57748726| 14=0| 17=10130575412707914| 32=0| 37=CA-FXI57748726| 38=1000000| 39=8| 54=2| 55=EUR/USD| 58=Rate Moved| 60=20250518 21:28:47| 75=19700101| 119=0| 120=EUR| 150=8| 151=0| 167=FOR| 10=090|
8=FIX.4.3| 9=92| 35=OT| 34=412| 49=demo.fxgrid| 52=20250601-00:54:25.130| 56=order.MakerOrg| 11=FXI107111| 10=157|
8=FIX.4.3| 9=219| 35=D| 34=4| 49=demo.fxgrid| 52=20250517-22:17:16.035| 56=order.MakerOrg| 1=MakerAccnt| 11=FXI57677008| 15=EUR| 21=1| 38=5000000| 40=D| 44=1.4047| 54=2| 55=EUR/USD| 59=3| 60=20250517-22:17:16.034| 117=27 299010107270301260| 167=FOR| 7540=Stream1| 10=196|
8=FIX.4.3| 9=302| 35=8| 34=4| 49=order.MakerOrg| 52=20250517-22:17:16.085| 56=demo.fxgrid| 1=MakerAccnt| 6=1.4047| 11=FXI57677008| 14=1000000| 17=FXI57677008-1305670636084-1| 31=1.4047| 32=1000000| 37=FXI57677008AC-| 38=5000000| 39=1| 54=2| 55=EUR/USD| 60=20250517-22:17:16| 75=20250518| 119=1000000| 120=EUR| 150=1| 151=4000000| 167=FOR| 10=211|
8=FIX.4.3| 9=296| 35=8| 34=5| 49=order.MakerOrg| 52=20250517-22:17:16.088| 56=demo.fxgrid| 1=MakerAccnt| 6=1.4047| 11=FXI57677008| 14=5000000| 17=FXI57677008-1305670636087-2| 31=1.4047| 32=4000000| 37=FXI57677008AC-| 38=5000000| 39=2| 54=2| 55=EUR/USD| 60=20250517-22:17:16| 75=20250518| 119=4000000| 120=EUR| 150=F| 151=0| 167=FOR| 10=207|
8=FIX.4.3| 9=221| 35=D| 34=54| 49=demo.fxgrid| 52=20250505-21:35:35.375| 56=order.MakerOrg| 1=MakerAccnt1| 11=FXI57002344| 15=EUR| 21=1| 38=1000000| 40=D| 44=1.45455| 54=2| 55=EUR/USD| 59=3| 60=20250505-21:35:35.375| 64=20250510| 117=FXLP1312fc20dd75936| 167=FOR| 7540=Stream1| 10=056|
8=FIX.4.3| 9=229| 35=8| 34=65| 49=order.MakerOrg| 52=20250505-21:35:34.528| 56=demo.fxgrid| 1=MakerAccnt1| 6=0| 11=FXI57002344| 14=0| 17=FXI57002344| 37=FXI57002344| 38=1000000| 39=A| 44=1.45455| 54=2| 55=EUR/USD| 60=20250505-21:35:34| 119=0| 120=USD| 150=0| 151=0| 167=FOR| 10=180|
8=FIX.4.3| 9=229| 35=8| 34=66| 49=order.MakerOrg| 52=20250505-21:35:34.530| 56=demo.fxgrid| 1=MakerAccnt1| 6=0| 11=FXI57002344| 14=0| 17=FXI57002344| 37=FXI57002344| 38=1000000| 39=0| 44=1.45455| 54=2| 55=EUR/USD| 60=20250505-21:35:34| 119=0| 120=USD| 150=0| 151=0| 167=FOR| 10=157|
8=FIX.4.3| 9=251| 35=8| 34=67| 49=order.MakerOrg| 52=20250505-21:35:34.986| 56=demo.fxgrid| 6=1.45455| 11=FXI57002344| 14=1000000| 17=S000000A0577ECA9E| 31=1.45455| 32=1000000| 37=FXI57002344| 38=1000000| 39=2| 54=2| 55=EUR/USD| 60=20250505-16:35:34| 119=1454550| 120=USD| 150=F| 151=0| 167=FOR| 10=049|
8=FIX.4.3| 9=221| 35=D| 34=51| 49=demo.fxgrid| 52=20250505-21:34:17.255| 56=order.MakerOrg| 1=MakerAccnt1| 11=FXI57002340| 15=EUR| 21=1| 38=1000000| 40=D| 44=1.45453| 54=2| 55=EUR/USD| 59=3| 60=20250505-21:34:17.255| 64=20250510| 117=FXLP1312fc20dd75936| 167=FOR| 7540=Stream1| 10=039|
8=FIX.4.3| 9=229| 35=8| 34=59| 49=order.MakerOrg| 52=20250505-21:34:16.413| 56=demo.fxgrid| 1=MakerAccnt1| 6=0| 11=FXI57002340| 14=0| 17=FXI57002340| 37=FXI57002340| 38=1000000| 39=A| 44=1.45453| 54=2| 55=EUR/USD| 60=20250505-21:34:16| 119=0| 120=USD| 150=0| 151=0| 167=FOR| 10=160|
8=FIX.4.3| 9=229| 35=8| 34=60| 49=order.MakerOrg| 52=20250505-21:34:16.416| 56=demo.fxgrid| 1=MakerAccnt1| 6=0| 11=FXI57002340| 14=0| 17=FXI57002340| 37=FXI57002340| 38=1000000| 39=0| 44=1.45453| 54=2| 55=EUR/USD| 60=20250505-21:34:16| 119=0| 120=USD| 150=0| 151=0| 167=FOR| 10=138|
8=FIX.4.3| 9=256| 35=8| 34=61| 49=order.MakerOrg| 52=20250505-21:34:16.877| 56=demo.fxgrid| 6=1.45453| 11=FXI57002340| 14=125000| 17=S000000A052D6F5AE| 31=1.45453| 32=125000| 37=FXI57002340| 38=1000000| 39=1| 54=2| 55=EUR/USD| 60=20250505-16:34:16| 119=181816.25| 120=USD| 150=1| 151=875000| 167=FOR| 10=027|
8=FIX.4.3| 9=256| 35=8| 34=62| 49=order.MakerOrg| 52=20250505-21:34:18.568| 56=demo.fxgrid| 6=1.45453| 11=FXI57002340| 14=250000| 17=S000000A052F0BDAD| 31=1.45453| 32=125000| 37=FXI57002340| 38=1000000| 39=1| 54=2| 55=EUR/USD| 60=20250505-16:34:18| 119=181816.25| 120=USD| 150=1| 151=750000| 167=FOR| 10=026|
8=FIX.4.3| 9=247| 35=8| 34=63| 49=order.MakerOrg| 52=20250505-21:34:36.098| 56=demo.fxgrid| 1=MakerAccnt1| 6=1.45453| 11=FXI57002340| 14=250000| 17=FXI57002340| 37=FXI57002340| 38=1000000| 39=C| 44=1.45453| 54=2| 55=EUR/USD| 60=20250505-21:34:16| 119=363632.5| 120=USD| 150=C| 151=0| 167=FOR| 10=080|
8=FIX.4.3| 9=221| 35=D| 34=43| 49=demo.fxgrid| 52=20250505-21:31:01.762| 56=order.MakerOrg| 1=MakerAccnt1| 11=FXI57002334| 15=EUR| 21=1| 38=1000000| 40=D| 44=1.45444| 54=2| 55=EUR/USD| 59=3| 60=20250505-21:31:01.762| 64=20250510| 117=FXLP1312fc20dd75936| 167=FOR| 7540=Stream1| 10=029|
8=FIX.4.3| 9=229| 35=8| 34=48| 49=order.MakerOrg| 52=20250505-21:31:00.921| 56=demo.fxgrid| 1=MakerAccnt1| 6=0| 11=FXI57002334| 14=0| 17=FXI57002334| 37=FXI57002334| 38=1000000| 39=A| 44=1.45444| 54=2| 55=EUR/USD| 60=20250505-21:31:00| 119=0| 120=USD| 150=0| 151=0| 167=FOR| 10=151|
8=FIX.4.3| 9=229| 35=8| 34=49| 49=order.MakerOrg| 52=20250505-21:31:00.923| 56=demo.fxgrid| 1=MakerAccnt1| 6=0| 11=FXI57002334| 14=0| 17=FXI57002334| 37=FXI57002334| 38=1000000| 39=0| 44=1.45444| 54=2| 55=EUR/USD| 60=20250505-21:31:00| 119=0| 120=USD| 150=0| 151=0| 167=FOR| 10=137|
8=FIX.4.3| 9=253| 35=8| 34=50| 49=order.MakerOrg| 52=20250505-21:31:01.382| 56=demo.fxgrid| 6=1.45444| 11=FXI57002334| 14=125000| 17=S000000A0472FF846| 31=1.45444| 32=125000| 37=FXI57002334| 38=1000000| 39=1| 54=2| 55=EUR/USD| 60=20250505-16:31:01| 119=181805| 120=USD| 150=1| 151=875000| 167=FOR| 10=083|
8=FIX.4.3| 9=245| 35=8| 34=51| 49=order.MakerOrg| 52=20250505-21:31:07.263| 56=demo.fxgrid| 1=MakerAccnt1| 6=1.45444| 11=FXI57002334| 14=125000| 17=FXI57002334| 37=FXI57002334| 38=1000000| 39=C| 44=1.45444| 54=2| 55=EUR/USD| 60=20250505-21:31:00| 119=181805| 120=USD| 150=C| 151=0| 167=FOR| 10=221|
8=FIX.4.3| 9=219| 35=D| 34=4| 49=demo.fxgrid| 52=20250518-21:52:29.916| 56=order.MakerOrg| 1=MakerAccnt| 11=FXI57748770| 15=USD| 21=1| 38=5000000| 40=D| 44=1.4045| 54=1| 55=EUR/USD| 59=3| 60=20250518-21:52:29.916| 117=27800090007270703184| 167=FOR| 7540=Stream1| 10=230|
8=FIX.4.3| 9=303| 35=8| 34=4| 49=order.MakerOrg| 52=20250518-21:52:29.962| 56=demo.fxgrid| 1=MakerAccnt| 6=1.4045| 11=FXI57748770| 14=1404500| 17=FXI57748770-1305755549961-55| 31=1.4045| 32=1404500| 37=FXI57748770AC-| 38=5000000| 39=1| 54=1| 55=EUR/USD| 60=20250518-21:52:29| 75=20250519| 119=1404500| 120=USD| 150=1| 151=3595500| 167=FOR| 10=110|
8=FIX.4.3| 9=303| 35=8| 34=5| 49=order.MakerOrg| 52=20250518-21:52:29.962| 56=demo.fxgrid| 1=MakerAccnt| 6=1.4045| 11=FXI57748770| 14=2809000| 17=FXI57748770-1305755549961-56| 31=1.4045| 32=1404500| 37=FXI57748770AC-| 38=5000000| 39=1| 54=1| 55=EUR/USD| 60=20250518-21:52:29| 75=20250519| 119=1404500| 120=USD| 150=1| 151=2191000| 167=FOR| 10=103|
8=FIX.4.3| 9=260| 35=8| 34=6| 49=order.MakerOrg| 52=20250518-21:52:29.963| 56=demo.fxgrid| 1=MakerAccnt| 6=1.4045| 11=FXI57748770| 14=2809000| 17=COMPLETE| 32=0| 37=COMPLETEFXI57748770| 38=5000000| 39=C| 54=1| 55=EUR/USD| 60=20250518-21:52:29| 75=19700101| 119=0| 120=USD| 150=C| 151=0| 167=FOR| 10=057|
8=FIX.4.3| 9=95| 35=g| 34=2| 49=demo.fxgrid| 52=20250624-09:50:57.032| 56=order.MakerOrg| 263=0| 335=Order1308909057032| 10=246|
8=FIX.4.3| 9=95| 35=g| 34=2| 49=demo.fxgrid| 52=20250624-09:50:57.032| 56=price.MakerOrg| 263=0| 335=Price1308909057032| 10=219|
8=FIX.4.3| 9=111| 35=h| 34=2| 49=order.MakerOrg| 52=20250505-21:05:07.185| 56=demo.fxgrid| 325=N| 335=Order1304629507988| 336=20250505| 340=2| 10=096|
8=FIX.4.3| 9=111| 35=h| 34=2| 49=price.MakerOrg| 52=20250505-21:05:07.189| 56=demo.fxgrid| 325=N| 335=Price1304629507988| 336=20250505| 340=2| 10=073|
8=FIX.4.3| 9=241| 35=R| 34=1738| 49=demo.INTEGRAL.TEST| 52=20150628-07:24:24.807| 56=Price.Maker.TEST| 1=TEST| 131=FXI125886856| 541=20150725| 7540=Stream2| 146=1| 55=USD/INR| 167=FOR| 54= | 38=3750000| 64=20150727| 40=D| 126=00000000-00:02:00| 60=20150628-07:24:24.807| 15=USD| 10=097|
8=FIX.4.3| 9=308| 35=S| 34=15757| 49=Price.Maker.TEST| 52=20150628-07:24:25.461| 56=demo.INTEGRAL.TEST| 15=USD| 40=D| 54= | 55=USD/INR| 60=20150628-07:24:25.461| 62=00000000-00:00:30.000| 64=20150727| 117=1340868265472| 131=FXI125886856| 132=45.57| 133=45.58| 134=3750000| 135=3750000| 167=FOR| 188=45.57| 189=0| 190=45.58| 191=0| 537=1| 541=20150725| 10=054|
8=FIX.4.3| 9=248| 35=D| 34=881| 49=demo.INTEGRAL.TEST| 52=20150628-07:24:25.955| 56=Order.Maker.TEST| 1=TEST| 11=FXI125886856| 15=USD| 21=1| 38=3750000| 40=D| 44=45.58| 54=1| 55=USD/INR| 59=4| 60=20150628-07:24:25.955| 64=20150727| 117=1340868265472| 167=FOR| 541=20150725| 7540=Stream2| 10=208|
8=FIX.4.3| 9=277| 35=8| 34=898| 49=Order.Maker.TEST| 52=20150628-07:24:25.956| 56=demo.INTEGRAL.TEST| 6=45.58| 11=FXI125886856| 14=3750000| 15=USD| 17=1340868265956| 31=45.58| 32=3750000| 37=1340868265956| 38=3750000| 39=2| 40=D| 54=1| 55=USD/INR| 59=4| 64=20150727| 150=2| 151=0| 167=FOR| 194=45.58| 195=0| 541=20150725| 10=060|
8=FIX.4.3| 9=241| 35=R| 34=3148| 49=demo.INTEGRAL.TEST| 52=20150628-09:12:19.278| 56=Price.Maker.TEST| 1=TEST| 131=FXI125891978| 541=20150716| 7540=Stream2| 146=1| 55=USD/INR| 167=FOR| 54=2| 38=2250000| 64=20150718| 40=D| 126=00000000-00:02:00| 60=20150628-09:12:19.277| 15=INR| 10=113|
8=FIX.4.3| 9=270| 35=S| 34=39106| 49=Price.Maker.TEST| 52=20150628-09:12:24.125| 56=demo.INTEGRAL.TEST| 15=INR| 40=D| 54=2| 55=USD/INR| 60=20150628-09:12:24.125| 62=00000000-00:00:30.000| 64=20150718| 117=1340874744156| 131=FXI125891978| 133=45.58| 135=2250000| 167=FOR| 190=45.58| 191=0| 537=1| 541=20150716| 10=046|
8=FIX.4.3| 9=249| 35=D| 34=2136| 49=demo.INTEGRAL.TEST| 52=20150628-09:12:24.334| 56=Order.Maker.TEST| 1=TEST| 11=FXI125891978| 15=INR| 21=1| 38=2250000| 40=D| 44=45.58| 54=2| 55=USD/INR| 59=4| 60=20150628-09:12:24.334| 64=20150718| 117=1340874744156| 167=FOR| 541=20150716| 7540=Stream2| 10=221|
8=FIX.4.3| 9=278| 35=8| 34=2166| 49=Order.Maker.TEST| 52=20150628-09:12:24.335| 56=demo.INTEGRAL.TEST| 6=45.58| 11=FXI125891978| 14=2250000| 15=INR| 17=1340874744335| 31=45.58| 32=2250000| 37=1340874744335| 38=2250000| 39=2| 40=D| 54=2| 55=USD/INR| 59=4| 64=20150718| 150=2| 151=0| 167=FOR| 194=45.58| 195=0| 541=20150716| 10=049|
8=FIX.4.4| 9=241| 35=R| 49=quote.demo.fxgrid| 56=price.MakerOrg| 34=461| 52=20240521-14:51:42| 50=PN1907LE| 128=WU| 131=1414672234| 146=1| 55=USD/INR| 167=FOR| 54= | 38=1000000| 64=2W| 193=2M| 192=1000000| 15=USD| 40=G| 126=20240521-14:51:42| 60=20240521-14:51:42| 10=191|
8=FIX.4.4| 9=470| 35=S| 34=478| 49=price.MakerOrg| 52=20240521-14:51:57.644| 56=quote.demo.fxgrid| 57=demoLE| 115=WU| 15=USD| 40=G| 54= | 55=USD/INR| 60=20240521-14:51:57.644| 62=00000000-00:02:00.000| 64=20240607| 117=G-4796976cb-18f9ba33d4a-WU-1bf9e4-PN1907-WU-1716303117643| 131=1414672234| 132=74.7501| 133=74.7602| 134=1000000| 135=1000000| 167=FOR| 188=74.75| 189=0.0001| 190=74.76| 191=0.0002| 193=20240723| 537=1| 541=20240604| 642=-0.0002| 643=-0.0001| 7551=1000000| 7552=1000000| 8541=20240719| 10=122|
8=FIX.4.4| 9=312| 35=D| 49=quote.demo.fxgrid| 56=order.MakerOrg| 34=461| 52=20240521-14:52:14| 50=demoLE| 128=WU| 11=173549109| 15=USD| 21=1| 38=1000000| 40=D| 44=74.7501| 54=1| 55=USD/INR| 59=3| 60=20240521-14:52:14| 64=2W| 117=G-4796976cb-18f9ba33d4a-WU-1bf9e4-PN1907-WU-1716303117643| 167=FOR| 192=1000000| 193=2M| 460=4| 640=74.7499| 10=023|
8=FIX.4.4| 9=350| 35=8| 34=464| 49=order.MakerOrg| 52=20240521-14:52:14.499| 56=quote.demo.fxgrid| 57=demoLE| 115=WU| 6=0| 11=173549109| 14=0| 15=USD| 17=NONE| 31=0| 32=0| 37=NONE| 38=1000000| 39=A| 40=D| 44=74.7501| 54=1| 55=USD/INR| 59=3| 60=20240521-14:52:14.499| 64=2W| 150=A| 151=1000000| 167=FOR| 192=1000000| 193=2M| 194=0| 195=0| 460=4| 640=74.7499| 641=0| 7541=0| 7543=0| 7544=0| 10=200|
8=FIX.4.4| 9=359| 35=8| 34=465| 49=order.MakerOrg| 52=20240521-14:52:14.549| 56=quote.demo.fxgrid| 57=demoLE| 115=WU| 6=0| 11=173549109| 14=0| 15=USD| 17=NONE| 31=0| 32=0| 37=FXI9405106268| 38=1000000| 39=0| 40=D| 44=74.7501| 54=1| 55=USD/INR| 59=3| 60=20240521-14:52:14.548| 64=2W| 150=0| 151=1000000| 167=FOR| 192=1000000| 193=2M| 194=0| 195=0| 460=4| 640=74.7499| 641=0| 7541=0| 7543=0| 7544=0| 10=103|
8=FIX.4.4| 9=547| 35=8| 34=466| 49=order.MakerOrg| 50=WU| 52=20240521-14:52:15.240| 56=quote.demo.fxgrid| 57=demoLE| 115=WU| 6=74.7501| 11=173549109| 14=1000000| 15=USD| 17=FXI9405106268| 31=74.7501| 32=1000000| 37=FXI9405106268| 38=1000000| 39=2| 40=D| 44=74.7501| 54=1| 55=USD/INR| 59=4| 60=20240521-14:52:14.523| 64=20240607| 75=20240521| 119=74750100| 120=INR| 150=F| 151=0| 167=FOR| 192=1000000| 193=20240723| 194=74.75| 195=0.0001| 460=4| 541=20240604| 640=74.7499| 641=-0.0001| 7541=74.7499| 7543=0| 7544=1000000| 7545=74749900| 8541=20240719| 9395=Y28912MCQRZU5ST13393INP9405106268RTN| 10=193|
8=FIX.4.3| 9=265| 35=R| 34=127| 49=quote.demo.fxgrid| 50=requestingID| 52=20250522-19:52:12.208| 56=price.MakerOrg| 128=MakerOrgID| 131=FSR14| 146=1| 55=EUR/USD| 167=FOR| 54=1| 38=1000000| 64=SPOT| 40=G| 193=1W| 192=1000000| 126=20250522-19:02:00.207| 60=20250522-19:52:12.207| 15=EUR| 44=1.21135| 10=170|
8=FIX.4.3| 9=396| 35=S| 34=139| 49=price.MakerOrg| 52=20250522-19:52:22.794| 56=quote.demo.fxgrid| 57=requestingID| 115=MakerOrgID| 15=EUR| 40=G| 54=1| 55=EUR/USD| 60=20250522-19:52:22.794| 62=00000000-00:01:48.000| 64=20250527| 117=G-479694da5-146257dd80f-MakerOrgID-272-requestingID-MakerOrgID-1400788342792| 131=FSR14| 132=1.21135| 134=1000000| 167=FOR| 188=1.21135| 189=0| 193=20250603| 537=1| 631=1.200025| 643=0.0004| 7552=1000000| 7631=1.200325| 10=163|
8=FIX.4.3| 9=352| 35=8| 34=130| 49=price.MakerOrg| 52=20250522-19:52:26.124| 56=order.demo.fxgrid| 57=requestingID| 115=MakerOrgID| 6=0| 11=fsr36| 14=0| 15=EUR| 17=NONE| 18=B| 31=0| 32=0| 37=NONE| 38=1000000| 39=A| 40=D| 44=1.21135| 54=1| 55=EUR/USD| 60=20250522-19:52:26.122| 64=SPOT| 150=A| 151=1000000| 167=FOR| 192=1000000| 193=1W| 194=0| 195=0| 460=4| 640=1.21175| 641=0| 7541=0| 7543=0| 7544=0| 10=164|
8=FIX.4.3| 9=387| 35=8| 34=131| 49=price.MakerOrg| 52=20250522-19:52:26.162| 56=order.demo.fxgrid| 57=requestingID| 115=MakerOrgID| 6=0| 11=fsr36| 14=0| 15=EUR| 17=NONE| 18=B| 31=0| 32=0| 37=FXI354822177| 38=1000000| 39=0| 40=D| 44=1.21135| 54=1| 55=EUR/USD| 60=20250522-19:52:26.162| 64=SPOT| 150=0| 151=1000000| 167=FOR| 192=1000000| 193=1W| 194=0| 195=0| 460=4| 631=1.200025| 640=1.21175| 641=0| 7541=0| 7543=0| 7544=0| 7631=1.200325| 10=025|
8=FIX.4.3| 9=346| 35=D| 34=129| 49=order.demo.fxgrid| 50=requestingID| 52=20250522-19:52:26.613| 56=price.MakerOrg| 128=MakerOrgID| 11=fsr36| 15=EUR| 18=B| 21=1| 38=1000000| 40=D| 44=1.21135| 54=1| 55=EUR/USD| 60=20250522-19:52:26.612| 64=SPOT| 117=G-479694da5-146257dd80f-MakerOrgID-272-requestingID-MakerOrgID-1400788342792| 167=FOR| 192=1000000| 193=1W| 460=4| 640=1.21175| 453=1| 448=| 447=D| 452=3| 10=196|
8=FIX.4.3| 9=501| 35=8| 34=132| 49=price.MakerOrg| 50=MakerOrgIDle| 52=20250522-19:52:26.228| 56=order.demo.fxgrid| 57=requestingID| 115=MakerOrgID| 6=1.21135| 11=fsr36| 14=1000000| 15=EUR| 17=FXI354822177| 31=1.21135| 32=1000000| 37=FXI354822177| 38=1000000| 39=2| 40=D| 44=1.21135| 54=1| 55=EUR/USD| 59=4| 60=20250522-19:52:26.138| 64=20250527| 75=20250522| 119=1211350| 120=USD| 150=F| 151=0| 167=FOR| 192=1000000| 193=20250603| 194=1.21135| 195=0| 460=4| 631=1.200025| 640=1.21175| 641=0.0004| 7541=1.21175| 7543=0| 7544=1000000| 7545=1211750| 7631=1.200325| 10=065|
This appendix provides information about the changes to the last five versions of this document. The information is in chronological order from newest to oldest.
Document changes
| Date | API Version | Enhancements |
|---|---|---|
| November 2025 (2.1v24) | 2.1 |
|
| October 2025 (2.1v23) | 2.1 |
|
| May 2024 (2.1v22) | 2.1 |
|