FIX Maker API: ESP Workflow

This document describes the Integral FIX Maker ESP API, a FIX-based channel that allows makers to publish streams of liquidity to customers 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

• FIX implementation
• Configuration
• Business rules

This specification is based on the FIX 4.3 and FIX 4.4 specifications (https://www.fixtrading.org/) and has been adapted to Integral’s requirements. Users should have a basic knowledge of the FIX protocol and FIX messaging.

Each FIX Maker ESP 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 ESP API implementation.
  • N = optional for both the FIX Maker ESP 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

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

Standard message footer field

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 ESP 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.yourOrg4

Organization ID format

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.integral

Organization ID format

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 ESP 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=5

The 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_York

The API allows you to set custom start and end times for every day of the week.

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:00

Parameters for initiator sequence number reset

ResetOnDisconnect=N
ResetOnLogout=N
StartTime=17:00:05
EndTime=17:00:00

The 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:

• FX spot only

To submit an order to a specific venue, set ExDestination (#100) to the target venue.

Subsequent order workflow is routed to and from the venue by Integral (for example, order cancel, order cancel/replace, order fills, status).

You can send orders for algos in third-party venues with the following fields on New Order - Single:

External algo fields

The API holds mid-mark information in the following fields:

Integral applies flow control on makers’ incoming rates. A maximum 200 rate updates per currency pair per price stream in a 2 second window are permitted. Please contact your Integral Technical Account Manager if you have any questions.

The following messages are used to control the FIX session and manage message conversations:

• Logon
• Logout
• Heartbeat
• Test Request
• Resend Request
• Session-level Reject
• Sequence Reset

(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.

If Integral receives a Logon message with invalid fields, it sends a Logout message in response. See Logout.

Logon message fields

(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

(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

(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

(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

(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

(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

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 ESP pricing workflow (Executable streaming prices (ESP) workflow).

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.

1. Logon (#35=A) sent from maker on price session.
2. Logon response (#35=A) on price session from Integral.
3. Trading Session Status Request (#35=g) sent from Integral.
4. Trading Session Status (#35=h) with TradSesStatus (#340)=2 (Open) sent from maker on price session.
5. Logon (#35=A) sent from maker on order session.
6. Logon response (#35=A) on order session from Integral.
7. Trading Session Status Request (#35=g) sent from Integral.
8. 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.

For the ESP workflow, the API currently supports trading in FX spot only.

The Executable Streaming Prices (ESP) workflow involves both price and order sessions. For more information about session types, see Sessions.

The customer requests market data in a price session and receives executable quotes on the same price session. Then in an order session the customer sends an order. For previously quoted orders (OrdType (#40)=D), the order refers to the originating price’s QuoteEntryID (#299). For limit orders (OrdType (#40)=2), the order must include the requested price and size (Price (#44) and OrderQty (#38)). For market orders (OrdType (#40)=1), the order must include the requested size (OrderQty (#38)).

ESP trading workflow: previously quoted order

ESP trading workflow: limit order

ESP trading workflow: market order

The following trading messages are applicable to the ESP workflow:

ESP trading messages

The Market Data Snapshot/Full Refresh message contains the latest market price for a currency pair. The API supports three types of ESP quotes: single price, multi-tiered, and multi-price.

The Market Data Snapshot/Full Refresh contains one pair of bid and offer prices for a currency pair with each market data update.

• NoMDEntries (#268) = 2 (a single pair of bid and offer prices)
• MDEntryType (#269) = The message includes a bid entry and an offer entry.
• MDEntryPositionNo (#290) = 0

The Market Data Snapshot/Full Refresh contains multi-tiered quotes for each amount level. For example, 1.2345/46 for amounts to 5M, 1.2344/47 for amounts to 10M, 1.2343/48 for amounts to 15M.

• NoMDEntries (#268) = 2 times the number of tiers. In the above example, the NoMDEntries (#268) value would be 6.
• MDEntryType (#269) = Typically the message includes an equal number of bid/offer prices. The number of bid and offer price can become uneven if the maker performs dynamic liquidity regeneration.
• MDEntryPositionNo (#290) = The value indicates the tier position of the bid and offer prices. In the first tier, prices have a value of 1. Second tier prices have a value of 2 and so on.

For previously quoted orders, the customer must refer to the quote ID in the QuoteID (#117) field of the New Order – Single message.

For limit orders, the order price and size (Price (#44), OrderQty (#38)) must match the tier price and size of the quote in the MDEntryPx (#270) and MDEntrySize (#271) fields of the Market Data Snapshot/Full Refresh message. The maker should reject an order if the amount of the order and the price tier do not match. The order amount is filled to the offered amount.

For market orders, the order price and size (Price (#44), OrderQty (#38)) must match the tier price and size of the quote in the MDEntryPx (#270) and MDEntrySize (#271) fields of the Market Data Snapshot/Full Refresh message. The maker should reject an order if the amount of the order and the price tier do not match. The order amount is filled to the offered amount.

The Market Data Snapshot/Full Refresh contains the entire depth of the book with multiple independent prices (typically from an order book). A customer can sweep the entire book and get multiple fills at each price level.

• NoMDEntries (#268): Any number depending on the number of prices in the book
• MDEntryType (#269): The number of bid and offer prices is typically not even.
• MDEntryPositionNo (#290): 0 (each price is independent)

To remove or pull a price, you need to send a new Market Data Snapshot/Full Refresh message in the currency pair with the QuoteCondition (#276) field set to B (Closed / Inactive) or with a MDEntrySize (#271) value of 0 (zero).

Your organization can provide multiple streams and assign each stream to a customer category. You and Integral must agree on an ID for each stream.

Integral sends the stream ID in the Market Data Request message in the Stream ID (#7540) custom field. The stream ID is optional. If your organization does not support multiple streams of prices, the Stream ID (#7540) field is left empty.

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

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

The FIX Maker ESP API supports orders with the following TimeInForce (#59) values:

Order expiry

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 the OrderQty (#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 state transitions

Order status

The FIX Maker ESP API offers the following order workflow features to makers:

• Order submission
• Order execution reports for accept/acknowledge, reject, trade execution, and partial fill events

The API order workflow supports the following FIX messages types:

Supported message types

(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

(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

The messages in this section are used to access the ESP workflow (see Executable streaming prices (ESP) workflow).

(Integral to Maker)

Integral sends one Market Data Request message per currency pair per price stream (across all customers) to initiate trading in the ESP workflow with the maker. If a customer subscribes to five currency pairs in a price stream, the maker receives five Market Data Request messages. For two price streams with five unique currency pairs each across multiple customers, the maker receives ten Market Data Request messages. The subscription is sent when the first customer set up for a currency pair on the stream subscribes. Because a subscription is already sent, when a subsequent customer requests prices for the same currency pair on the stream, no further subscription is sent to the maker.

Integral also sends a single Market Data Request message on behalf of a customer to unsubscribe from all rates. The unsubuscription message is sent per currency pair per price stream and is sent only when the last customer receiving pricing for the currency pair per stream no longer needs it. See Executable streaming prices (ESP) workflow for information.

Market Data Request message fields

(Maker to Integral)

The maker sends a Market Data Snapshot/Full Refresh message to Integral in response to a Market Data Request message for each currency pair stream.

The API maintains a one-to-one relationship between customers, currency pairs, and Market Data Snapshot/Full Refresh message targets. Integral sends Market Data Snapshot/Full Refresh messages for each customer and each currency pair stream in the ESP workflow.

The Market Data Snapshot/Full Refresh message may contain multiple rates. The NoMDEntries (#268) field indicates the number of rates in the message. If you want to send multi-tier or multi-price quotes, see Quote type. The customer receives the fully qualified customer rate and associated limits. The customer rate is specified by the MDEntryPx (#270) field.

Each rate consists of a repeating group of fields, as indicated by arrows in the table below.

Market Data Snapshot/Full Refresh message fields

(Maker to Integral)

The maker sends a Market Data – Incremental Refresh message to Integral in response to a successful Market Data Request message for a currency pair. The Market Data Request message must have the MDUpdateType (#265) field set to 1 (one).

The Market Data – Incremental Refresh message may contain one or more rates. The NoMDEntries (#268) field indicates the number of rates in the message.

Each rate consists of a repeating group of fields, as indicated by arrows in the table below.

Only new rate entries (MDUpdateAction (#279)=0) include currency pair and bid/offer information for the entry. Subsequent updates to and deletion of the rate refer to the rate’s MDEntryID (#278) and do not include fields like Currency (#15) and MDEntryType (#269).

Market Data – Incremental Refresh message fields

(Maker to Integral)

The maker sends a Market Data Request Reject message to Integral in response to an unsuccessful Market Data Request message.

Market Data Request Reject message fields

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

(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

(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:

1. Execution Report (pending cancel): ExecType (#150)=6 and OrdStatus (#39)=6
2. Execution Report (canceled): ExecType (#150)=4 and OrdStatus (#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

(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

(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

(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

(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.
• 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

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=159| 35=V| 34=5| 49=demo.fxgrid| 52=20250518-21:51:48.272| 56=price.MakerOrg| 262=FXLP71300517de30117| 263=1| 264=0| 265=0| 7540=Stream1| 146=1| 55=EUR/USD| 460=4| 267=2| 269=0| 269=1| 10=183|

8=FIX.4.3| 9=132| 35=Y| 34=579967| 49=price.MakerOrg| 52=20250629-09:07:10.231| 56=demo.fxgrid| 58=USD/NOK is not supported| 262=FXLP130d828bd0c155| 10=041|

8=FIX4.3| 9=1962| 35=X| 34=459648| 49=price.MakerOrg| 52=20250705-06:59:59.640| 56=demo.fxgrid| 268=29| 279=0| 269=0| 55=GBP/USD| 461=RCSXXX| 270=1.46934| 271=20000000| 63=0| 279=0| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47084| 271=20000000| 63=0| 279=0| 269=0| 55=GBP/USD| 461=RCSXXX| 270=1.46929| 271=25000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47034| 271=10000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47034| 271=10000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47039| 271=15000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47044| 271=20000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47044| 271=12000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47044| 271=12000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47049| 271=17000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47054| 271=22000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47054| 271=14000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47054| 271=14000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47059| 271=19000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47064| 271=24000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47064| 271=16000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47064| 271=16000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47069| 271=21000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47074| 271=26000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47074| 271=18000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47074| 271=18000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47079| 271=23000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47084| 271=28000000| 63=0| 279=2| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47084| 271=20000000| 63=0| 279=0| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47089| 271=25000000| 63=0| 279=0| 269=0| 55=GBP/USD| 461=RCSXXX| 270=1.46924| 271=30000000| 63=0| 279=0| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47094| 271=30000000| 63=0| 279=0| 269=0| 55=GBP/USD| 461=RCSXXX| 270=1.46934| 271=20000000| 63=0| 279=0| 269=1| 55=GBP/USD| 461=RCSXXX| 270=1.47084| 271=20000000| 63=0| 10=027|

8=FIX.4.3| 9=505| 35=W| 34=4| 49=price.MakerOrg| 52=20250518-21:51:53.884| 56=demo.fxgrid| 55=EUR/USD| 262=FXLP71300517de30117| 268=6| 269=0| 270=1.403| 15=EUR| 271=1000000| 276=A| 282=1| 299=26 903010307270408449| 290=0| 269=0| 270=1.4046| 15=EUR| 271=5000000| 276=A| 282=1| 299=27 221090307220403130| 290=0| 269=0| 270=0| 15=EUR| 271=0| 276=A| 282=1| 299=28 4| 290=0| 269=1| 270=1.4074| 15=EUR| 271=1000000| 276=A| 282=1| 299=26 783080909280801987| 290=0| 269=1| 270=0| 15=EUR| 271=0| 276=A| 282=1| 299=27 3| 290=0| 269=1| 270=0| 15=EUR| 271=0| 276=A| 282=1| 299=28 5| 290=0| 460=4| 10=045|

8=FIX.4.3| 9=505| 35=W| 34=4| 49=price.MakerOrg| 52=20250518-21:51:53.884| 56=demo.fxgrid| 55=EUR/USD| 262=FXLP71300517de30117| 268=6| 269=0| 270=1.403| 15=EUR| 271=1000000| 276=A| 282=1| 299=26 903010307270408449| 290=0| 269=0| 270=1.4046| 15=EUR| 271=5000000| 276=A| 282=1| 299=27 221090307220403130| 290=0| 269=0| 270=0| 15=EUR| 271=0| 276=A| 282=1| 299=28 4| 290=0| 269=1| 270=1.4074| 15=EUR| 271=1000000| 276=A| 282=1| 299=26 783080909280801987| 290=0| 269=1| 270=0| 15=EUR| 271=0| 276=A| 282=1| 299=27 3| 290=0| 269=1| 270=0| 15=EUR| 271=0| 276=A| 282=1| 299=28 5| 290=0| 460=4| 10=045|

8=FIX.4.3| 9=587| 35=W| 34=211847| 49=price.MakerOrg| 52=20250530-15:00:00.511| 56=demo.fxgrid| 55=USD/JPY| 262=PROVIDER1303fbc1e6211| 460=4| 541=20250601| 268=6| 269=0| 270=80.919| 15=USD| 271=1000000| 276=A| 282=PROVIDER| 299=151675397639\_B| 290=1| 269=1| 270=80.928| 15=USD| 271=1000000| 276=A| 282=PROVIDER| 299=151675397639\_O| 290=1| 269=0| 270=80.92| 15=USD| 271=3000000| 276=A| 282=PROVIDER| 299=151675397639\_B1| 290=2| 269=0| 270=80.91| 15=USD| 271=5000000| 276=A| 282=PROVIDER| 299=151675397639\_B2| 290=3| 269=1| 270=80.93| 15=USD| 271=3000000| 276=A| 282=PROVIDER| 299=151675397639\_O1| 290=2| 269=1| 270=80.94| 15=USD| 271=5000000| 276=A| 282=PROVIDER| 299=151675397639\_O2| 290=3| 10=161|

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=750000| 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|

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