FIX Orders API

The Integral FIX Orders API enables market participants to submit orders into Integral matching engines.

This specification is based on the FIX 4.3 and FIX 4.4 standards (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.

Integral matching engines are located in Equinix’s NY4 data center in New York, LD4 data center in London, and the TY3 data center in Tokyo. The matching engines operate independently and generate their respective market data and mid-point values.

Integral’s trading systems are located in the Equinix NY4, LD4, TY3, and SG1 data centers:

• NY4: 755 Secaucus Road, Secaucus, NJ 07094
• LD4: 2 Buckingham Avenue, Slough, Berkshire, SL1 4NB, United Kingdom
• TY3: 1-9-20, Edagawa, Koto-ku, Tokyo, Japan 135-0051
• SG1: 20 Ayer Rajah Crescent, Singapore, Singapore, 139964

• Local cross-connect to Integral’s ECN cages in NY4, LD4, or TY3 data centers
• Private network connections
• Public Internet connectivity for UAT access and certification only
• All FIX traffic is TCP-based with a unique target (IP port) for each FIX session.
• Multicast traffic does not travel over customer connectivity routes.

• All customer cross-connectivity is 1/10Gpbs Multimode, Single-mode fiber or 1Gps copper.
• Integral issues a Letter of Authorization (LOA) to connect to Integral’s ECN with up to two fiber cross-connects.
• To avoid delays, customers must confirm the correct organization name or third-party agent name to be used in the LOA.
• Send an email to noc@integral.com with information including the name of the cross-connect customer entity.
• Parallel cross-connects are connected to different access switches for redundancy.
• Cross-connects are statically routed at NY4 while BGP is the preferred routing mechanism at LD4.
• Integral can provide or use third-party RFC-1918 IPs for the transit network.
• In NY4, Integral prefers that the customer routes via a globally routable unicast IP-address (non-RFC1918), over the transit network. Integral similarly provides a globally routable unicast network over the transit network. Alternatively, an RFC-1918 address space can be agreed on for routing traffic over the transit network.
• In LD4, Integral accepts a customer’s registered IP address and BGP ASN. If required, Integral assigns the customer’s server-farm IP addresses and BGP ASN.

The Integral FIX Orders API operates on a single order session for placing orders and receiving execution reports. Customers initiate the order session to submit, replace, and cancel orders.

Messages on the order session are transactional and persistent with guaranteed delivery, reflecting their business criticality. The server resends order session messages in response to a resend request from the customer app.

Daily and weekly order sessions are available from 17:00:10 EST/EDT Sunday through 17:00:00 EST/EDT Friday.

Daily sessions are the default session type and are off-line daily for general maintenance from 17:00:00 EST/EDT until 17:00:10 EST/EDT Monday through Thursday.

Weekly sessions do not go offline during the week. Contact your Integral Customer Engineer to configure weekly sessions.

Session availability

FIX sequence numbers for all sessions are reset during general maintenance.

To successfully reconnect at 17:00:10 EST/EDT, you must send a Logon message with a sequence number of “1” (one). Integral’s Logon response also has a sequence number of “1” (one).

Integral sends a Logout message at 17:00:00 EST/EDT every day for daily sessions and Friday for weekly sessions. When you receive this message, you should disconnect by sending a Logout message.

For intra-session disconnections, Integral recommends using the next sequence number.

If a customer app requires sequence numbers reset, the app must send a Logon message with a sequence number of “1” (one) and the ResetSeqNumFlag (#141) set to “Y”. Integral replies with a Logon message with the sequence number set to “1” (one).

The following message types are supported by the Integral FIX Orders API. Any other message types received by Integral are rejected.

Supported session-level messages

Supported business messages

Integral validates all FIX messages to ensure the presence of all mandatory and conditional fields and component blocks.

For messages that fail validation, Integral follows the FIX protocol where possible and responds with the following reject messages by message type:

Corresponding reject message types

The Integral FIX Orders API acts as the acceptor for all FIX sessions. The customer initiates the connection by sending a FIX Logon message. If the connection can be established, Integral responds with a Logon acknowledgment message.

If the Logon fails, Integral responds with a Logout message. The Logout message includes a rejection reason for the failure in the Text (#58) field.

Both the customer's app and Integral send the Heartbeat message to indicate that the connection is active.

The Test Request message forces a heartbeat from the receiving system. The receiving system responds to a Test Request message with a Heartbeat message containing the TestReqID (#112) sent in the Test Request message.

Both the customer's app and Integral can initiate disconnection by sending a Logout message. The other party should acknowledge this message with a Logout acknowledgment message.

The Integral FIX Orders API supports the following order attributes and types.

The order type is specified in the OrdType (#40) of the New Order - Single (#35=D) message.

The Integral FIX Orders API supports the following order types:

• Limit (OrdType (#40)=2): An order to buy or sell at a specified price or better.
• Pegged (OrdType (#40)=P): Only mid-point pegged orders are allowed. The mid-point pegged order is a passive order and floats at the mid-point of the market.

The Side (#54) field specifies the side (buy/sell) of the order from the customer’s perspective and in terms of the dealt currency (Currency (#15)) specified on the order:

• Side (#54)=1 (Buy): The customer buys the dealt currency.
• Side (#54)=2 (Sell): The customer sells the dealt currency.

The MinQty (#110) field specifies the minimum quantity the order should be filled. The first fill for the order must be equal to or greater than the value specified in the MinQty (#110) field.

The order’s lifetime is specified with the TimeInForce (#59) field on the New Order - Single (#35=D) message.

Integral supports the following time-in-force values:

• DAY (TimeInForce (#59)=0): Day order. The order remains active for the entire trading day until the order is completely filled, canceled by the customer, or until the order expires at the end of the trading day at 17:00 EST/EDT.

• GTC (TimeInForce (#59)=1): Good Till Cancel. The order remains active until completely filled or is canceled by the customer.

• GTT/GTD (TimeInForce (#59)=6): Good Till Time/Good Till Date. The order remains active until completely filled, canceled by the customer, or expired. Specify the expiry time with the ExpireTime (#126) field in the format YYYYMMDD-hh:mm:ss.sss.

  Specify a relative or absolute expiry time with the date portion YYYYMMDD:

  • Relative expiry: set the date portion to 00000000.

    For example, for an order that expires 30 seconds from receipt, you would specify 126=00000000-00:00:30.000.

  • Absolute expiry: set both the date and time portions.

    For example, to set the order to expire at 17:00 on August 14th, 2025, you would specify 126=20250814-17:00:00.000.

• IOC (TimeInForce (#59)=3): Immediate or Cancel. If not immediately filled, the order is canceled. Partials fills are possible.

• FOK (TimeInForce (#59)=4): Fill or Kill. If not filled immediately and completely with one fill, the order is canceled. Partials fills are not possible.

In order to ensure market integrity for some customers and markets, Integral has a price-banding algorithm that subjects all orders to price validation and rejects orders outside the band. A proprietary algorithm computes the new high and low price limits at the start of every trading session (17:04:30 EST/EDT daily Monday through Thursday).

Based on market conditions and trading activity, Integral may relax or suspend price-band restrictions.

Integral sends Execution Report messages to notify the submitter on updates to their orders. The various order states can be interpreted using two fields in the Execution Report:

• ExecType (#150): identifies the purpose of the Execution Report.
• OrdStatus (#39): conveys the current state of the order.

A typical order in Integral transitions through several different states during its life cycle.

Order states

Order cancellation can occur in the scenarios outlined below for an order that was previously accepted by Integral:

1. Solicited order cancel.

The cancel request is initiated by the customer app and the order can be successfully canceled (the order has not been filled).

2. Unsolicited order cancel.

   • Unfilled FOK orders.
   • Unfilled or partially filled IOC orders.
   • Integral cancels all orders when the customer app disconnects from Integral for any reason, intraday or end of day.

If market conditions or your business needs change, you may want to modify an existing order. Typically, this involves the Order Cancel/Replace workflow (cancelling the original order and submitting a replacement order).

When multiple orders have the same rate, orders that are submitted first to the order queue are filled first. with the replacement order falling to the bottom of the queue. The Integral also provides the Order Amendment workflow that allows you to amend an unfilled order’s size and keep its place in the order queue.

With the Order Cancel/Replace workflow, you must cancel the original order and submit a replacement order with a new client order ID (ClOrdID (#11)) using the Order Cancel/Replace Request message and workflow. The system assigns a new order ID (OrderID (#37)) to the replacement order and it joins the back of the queue. If the original order is partially filled, then the request is rejected with an Order Cancel Reject Message with the CxlRejReason (#102) field set to 0 (zero) “Too Late To Cancel”.

With the Order Amendment workflow enabled, you use the same Order Cancel/Replace Request message and provide a new client order ID (ClOrdID (#11)). If the original order is unfilled and if you only change the order size, the replacement order keeps the same order ID (OrderID (#37)) and keeps its place in the queue. However, if the original order is partially filled or if you change the order rate, then the replacement order gets a new order ID (OrderID (#37)) and joins the end of the queue.

Order cancel/replace compared to order amendment

Amending an order by size preserves its place in the order queue. The date/time and order ID (ClOrdID (#11)) of the replacement order is the same as the original order. When you amend an order by amount, all parameters on the Order Cancel/Replace message, except the amount, must be the same as the original order.

An order amended by rate loses its place in the queue. The date/time of the replacement order is updated to the date/time of the amend request and the replacement order gets a new order ID (ClOrdID (#11)). The amend message must match the original order in all parameters except the rate.

This section describes the features common to each message format in the Integral FIX Orders API.

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

Each message type sent over the Integral FIX Orders API has a standard header component as described below. The header is abbreviated as <Standard header> in this document.

Standard header format

Each message type sent over the Integral FIX Orders API also has a standard trailer component as described below. The header is abbreviated as <Standard trailer> in this document.

Standard trailer format

The customer sends a Logon message to establish a FIX session with Integral. If the Logon fails, Integral responds with a Logout message. The Text (#58) field of the Logout message contains the reason for the rejection of the Logon message.

Valid responses

• Logon (#35=A)
• Logout (#35=5)

Message format

Logon format

The customer sends a Logout message to end a session. Integral sends a single Logout message in response when all Logout related actions have been completed by Integral.

Valid responses

• Logout (#35=5)

Message format

Logout format

Integral and the customer send a Heartbeat message in response to a Test Request message to ensure connectivity. The Heartbeat message includes the TestReqID (#112) value from the received Test Request.

Valid responses

• None

Message format

Heartbeat format

Integral and the customer send a Test Request message to force a heartbeat from the receiving app. The receiving app responds with a Heartbeat message that includes the TestReqID (#112) value from the received Test Request.

Valid responses

• Heartbeat (#35=0)

Message format

Test Request format

A Session-level Reject message is sent by Integral when a message is received but cannot be processed.

Valid responses

• None

Message format

Session-level Reject format

The receiving app sends a Resend Request message to initiate the retransmission of messages, typically when it detects a gap in the message sequence number. The sender can request a single message or a range of messages.

The Resend Request message applies only to persistent sessions.

Valid responses

• Various

Message format

Resend Request format

The sequence reset messages forces the synchronization of sequence numbers on the sending and receiving sides in the event of lost messages.

Valid responses

• None

Message format

Sequence Reset format

Customers use the New Order - Single message to submit orders in Integral.

Valid responses

• Execution Report (#35=8)
• Business Message Reject (#35=j)

Message format

New Order – Single format

Customers send the Order Cancel Request message to request cancellation for all of the remaining quantity of an existing order.

Integral accepts the request only if the order can be successfully canceled.

Valid responses

• Execution Report (#35=8)
• Order Cancel Reject (#35=9)

Message format

Order Cancel Request format

Customers can use the Order Cancel/Replace Request message to modify or replace an existing order with an entirely new order. Integral handles this process in a single transaction from the order workflow perspective: The replacement order is not created unless and until the original order is successfully canceled.

When Integral receives an order cancel/replace request, Integral cancels the original order, replaces it with the modified order, and sends the confirmation of the new, modified order (with the new Integral-assigned order ID) to the customer. This new order ID must be used in the OrderID (#37) for subsequent modification operations.

Customers can use the Order Cancel/Replace Request message to modify the following order parameters:

• Quantity (OrderQty (#38))
• Price (Price (#44))
• Side (Side (#54))
• Maximum amount to be shown (MaxShow (#210))

Valid responses

• Execution Report (#35=8)
• Order Cancel Reject (#35=9)
• Business Message Reject (#35=j)

Message format

Order Cancel/Replace Request format

The customer sends the Order Status Request message to request the status of a working order (for example, unfilled or partially filled).

Valid responses

• Execution Report (#35=8)

Message format

Order Status Request format

Integral sends an Execution Report message to:

• Confirm the receipt of an order
• Confirm changes to an order
• Send order status information
• Send fill information on working orders
• Reject orders

Each Execution Report contains two fields that communicate both the current state of the order (OrdStatus (#39)) and the purpose of the message (ExecType (#150).)

Valid responses

• None

Message formats

• Order create or cancel/replace
• Fill
• Order reject
• Order cancel or expire
• Order status

Execution Report format: create or cancel/replace

Execution Report format: order status

Execution Report format: fill

Execution Report format: reject

Execution Report format: cancel or expire

Integral sends the Order Cancel Reject message to notify the customer app of a rejected Order Cancel Request or Order Cancel/Replace Request message.

Valid responses

• None

Message format

Order Cancel Reject format

Integral sends the Business Message Reject message to notify the customer app of a rejected New Order - Single or Order Cancel/Replace Request message.

Valid responses

• None

Message format

Business Message Reject format

The following table lists API changes and significant changes to this document.

API and document changes