# FIX Orders API

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

## Implementation details

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

The Integral FIX Orders API only supports messages, component blocks, and fields that are described in this document. All fields not in this document are ignored by Integral, including fields that are required or conditionally required by the FIX protocol.

### Matching engines

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 data center locations

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


#### Connectivity options

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


#### Cross connectivity

* 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](mailto:noc@integral.com?subject=OCX%20Streaming%20Orders%20cross-connect%20setup) 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.


### Order entry sessions

#### Session type

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.

#### Order session availability

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 IntegralTechnical Account Manager to configure weekly sessions.

Session availability 

| Session type | Availability | Session off-line for maintenance |
|  --- | --- | --- |
| Daily (default) | 17:00:10 EST/EDT Sunday through 17:00:00 EST/EDT Friday | Daily from 17:00:00 EST/EDT until 17:00:10 EST/EDT Monday through Thursday. |
| Weekly | 17:00:10 EST/EDT Sunday through 17:00:00 EST/EDT Friday | Weekly sessions do not go offline during the week. |


#### Session start

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

#### Session end

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.

#### Intra-session reconnections

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

### Supported message set

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

Message direction is from the customer's perspective.

Supported session-level messages 

| Direction | Message name  | `MsgType` (#35)  | Message purpose |
|  --- | --- | --- | --- |
| In, Out | Logon | A | Customer initiates a FIX session.
Integral responds to a successful Logon request. |
| In, Out | Logout | 5 | Customer or Integral ends a FIX session. |
| In, Out | Heartbeat | 0 | Customer or Integral signals the status of the communication link. This message should be used when no data has been sent for the number of seconds set by `HeartBtInt` (#108). |
| In, Out | Test Request | 1 | Customer or Integral queries the status of the connection when no data message has been received for twice the number of seconds set by `HeartBtInt` (#108).The receiving party should always send a Heartbeat message in response to a Test Request message.
 |
| In, Out | Session-level Reject | 3 | Customer or Integral cannot process a message. |
| In, Out | Resend Request | 2 | Customer or Integral detects a gap in the number sequence `MsgSeqNum` (#34) and requests retransmission of messages. |
| In, Out | Sequence Reset | 4 | Customer or Integral resets `MsgSeqNum` (#34) after receiving a Resend Request. |


#### Supported business messages

Message direction is from the customer's perspective.

Supported business messages 

| Direction | Message name | `MsgType` (#35)  | Message purpose |
|  --- | --- | --- | --- |
| In | New Order - Single | D | Customer submits an order to Integral. |
| Out | Execution Report | 8 | Integral confirms receipt of an order, confirms changes to an existing order, relays order status information, or relays fill information for working orders. |
| In | Order Cancel Request | F | Customer requests cancellation for all of the remaining quantity of an existing order. |
| Out | Order Cancel Reject | 9 | Integral indicates that the Order Cancel Request or Order Cancel/Replace Request cannot be fulfilled. |
| In | Order Cancel/Replace Request | G | Customer changes the parameters of an existing order. |
| In | Order Status Request | H | Customer checks the status of an order. |
| Out | Business Message Reject | j | Integral indicates that the New Order - Single or Order Cancel/Replace Request message has failed business validation. |


#### Message validation

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 

| Customer message (rejected) | Reject response from Integral |
|  --- | --- |
| Logon (#35=A) | Logout (#35=5) |
| New Order - Single (#35=D) | * Execution Report (#35=8)
* Business Message Reject (#35=j)

 |
| Order Cancel Request (#35=F) | Order Cancel Reject (#35=9) |
| Order Cancel/Replace Request (#35=G) | * Order Cancel Reject (#35=9)
* Business Message Reject (#35=j)

 |
| Order Status Request (#35=H) | Execution Report (#35=8) |


### Session management

#### Connect

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.

#### Heartbeat

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.

#### Disconnect

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.

Integral cancels all open orders on logout. See [Order cancellation](#order-cancellation) for details.

### Orders

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

#### Order 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.


#### Side

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.


#### Minimum order fill

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.

#### Time in force

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.


#### Price bands

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.

### Order management

#### Order states

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 state | `ExecType` (#150) | `OrdStatus` (#39) | Description |
|  --- | --- | --- | --- |
| New | 0 = New | 0 = New | The order has been successfully processed, entered in the order book, and acknowledged by the system. |
| Partially Filled | F = Trade | 1 = Partially Filled | The order has been filled for part of the amount on the order. The remainder of the order is still present in the order book. |
| Filled | F = Trade | 2 = Filled | The full amount on the order has been filled. The order is no longer in the order book. |
| Canceled | 4 = Canceled | 4 = Canceled | The system has successfully processed the cancel request. The order is no longer in the order book. |
| Expired | C = Expired | C = Expired | The order has reached a terminal state and is no longer in the order book. |
| Replaced | 5 = Replace | 5 = Replaced | The replace request has been successfully processed. The existing order has been canceled and a new order was created and is active in the matching engine. |
| Order Rejected | 8 = Rejected | 8 = Rejected | The order was rejected. |
| Undefined order | I = Order Status | U = Undefined | The order for which status has been requested is not present in the order book and cannot be found. Please contact Integral Customer Support. |


#### Order cancellation

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

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


#### Order cancel/replace and amendment

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.

Your organization must be configured to enable the Order Amendment workflow. Contact your Integral Technical Account Manager about amending orders.

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 

| Comparison | Order cancel/replace workflow | Order amendment workflow |
|  --- | --- | --- |
| Availability | Default behavior of the system | Must be configured. Contact your Integral Solutions Manager. |
| Request message sent | Order Cancel/Replace Request (see [Order Cancel/Replace Request](#order-cancelreplace-request)) | Same as cancel/replace. |
| Client order ID (`ClOrdID` (#11)) on request | New | Same as cancel/replace. |
| Request change to size only (see [Amending orders by size](#amending-orders-by-size2))) | Replacement order gets new order ID (loses place in queue) | Replacement order gets old order ID (keeps place in queue) |
| Request change to rate (see [Amending orders by rate](#amending-orders-by-rate)) | Replacement order gets new order ID (loses place in queue) | Same as cancel/replace. |
| Eligible order types | All (stops must not be triggered) | Same as cancel/replace. |
| Eligible order states | * New
* Stopped: If the order is partially filled, the request to cancel/replace is rejected with `CxlRejReason` (#102)=0 (zero) “Too Late To Cancel”.

 | * New
* Partial fill: The replacement order gets a new order ID and joins the end of the queue.
* Stopped: If the order is unfilled and you change only the order size, the replacement order gets the old order ID and retains its place in the queue. If the order is partially filled or if you change the rate, the replacement order gets a new order ID and joins the end of the queue.

 |
| Original order is partially filled | Request to cancel/replace rejected with `CxlRejReason` (#102)=0 (zero) “Too Late To Cancel” | Replacement order gets new order ID (loses place in queue) |


##### Amending orders by size

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.

##### Amending orders by rate

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.

### Common message components

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

#### Terminology

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.


#### Standard header

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 

| Tag  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| 8 | BeginString | Y | FIX4.3 or FIX4.4 | Identifies beginning of new message and protocol version. Must be the first field in the message. The message format must conform to the FIX 4.3 protocol, but the value “FIX4.4” is acceptable. | String(7) |
| 9 | BodyLength | Y | — | Message length (in bytes) forward to the `CheckSum` (#10) field. Must be the second field in the message. | int(6) |
| 35 | MsgType | Y | — | Defines the type of the message. Must be the third field in the message. | String(2) |
| 49 | SenderCompID | Y | — | This value is used to identify the firm sending the message. Should be set with the `SenderCompID` (#49) supplied by Integral for this FIX connection. | String(20) |
| 56 | TargetCompID | Y | — | This value is used to identify the firm receiving the message. Should be set with the `TargetCompID` (#56) supplied by Integral for this FIX connection. | String(20) |
| 34 | MsgSeqNum | Y | — | Integer message sequence number. | SeqNum(9) |
| 43 | PossDupFlag | N | Y=Possible Duplicate
N=Original Transmission | Indicates possible retransmission of message with this sequence number. Must be set to “Y” for messages sent in response to a Resend Request. | Boolean(1) |
| 52 | SendingTime | Y | — | Time the message was transmitted. Always expressed in UTC. | UTCTimestamp(21) |


#### Standard trailer

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 

| Tag  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| 10 | Checksum | Y | — | Three-byte checksum. Always the last tag in the message. Functions as an end-of-message delimiter. | String(3) |


## Administrative messages

### Logon

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 

| Tag  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=A | — |
| 98 | EncryptMethod | Y | 0=None | Always unencrypted | int(1) |
| 108 | HeartBtInt | Y | — | Heartbeat interval in seconds. The customer’s app determines the heartbeat interval. | int(3) |
| 141 | ResetSeqNumFlag | N | Y=Yes, reset sequence numbers
N=No | Indicates that both sides of the FIX session should reset sequence numbers. | Boolean(1) |
| 553 | Username | Y(API) | — | Should be set with the username supplied by Integral for this FIX connection. | String(20) |
| 554 | Password | Y(API) | — | Should be set with the password supplied by Integral for this FIX connection. | String(20) |
| <Standard trailer>  | Y | — | — | — |


### Logout

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 

| Tag  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=5 | — |
| 58 | Text | N | — | The reason for the Logon rejection. Only included for Logout messages in response to an invalid Logon message. | String(150) |
| <Standard trailer>  | Y | — | — | — |


### Heartbeat

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 

| Tag  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=0 | — |
| 112 | TestReqID | C | — | Required if heartbeat message is generated in response to a Test Request message. In this case, this tag must contain the TestReqID that was sent in the Test Request message. | String(20) |
| <Standard trailer>  | Y | — | — | — |


### Test Request

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 

| Tag  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=1 | — |
| 112 | TestReqID | C | — | This identifier should be returned in the Heartbeat response. | String(20) |
| <Standard trailer>  | Y | — | — | — |


### Session-level Reject

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 

| Tag  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=3 | — |
| 45 | RefSeqNum | Y | — | `MsgSeqNum` (#34) of the message being rejected. | SeqNum(9) |
| 371 | RefTagID | N | — | Tag ID of the field being referenced. | int(4) |
| 372 | RefMsgType | Y(API) | — | The `MsgType` (#35) of the FIX message being rejected. | String(2) |
| 373 | SessionRejectReason | Y(API) | 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. | Rejection code. | int(4) |
| <Standard trailer>  | Y | — | — | — |


### Resend Request

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 

| Tag  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=2 | — |
| 7 | BeginSeqNo | Y | — | Message sequence number of the first message in range to be re-sent. | int(9) |
| 16 | EndSeqNo | Y | — | Message sequence number of the last message to be re-sent. | int(9) |
| <Standard trailer>  | Y | — | — | — |


### Sequence Reset

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

Integral FIX Orders API order and market data messages are transient and are not persisted. The Integral FIX Orders API does not retransmit market data messages.

Valid responses 

* None


Message format 

Sequence Reset format 

| Tag  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=4 | — |
| 123 | GapFillFlag | Y | Y | Indicates that the Sequence Reset message is replacing the admin or application messages, which are not re-sent. | Boolean(1) |
| 36 | NewSeqNo | Y | — | New sequence number. This number must be greater than either the `BeginSeqNo` (#16) or the `EndSeqNo` (#7) on the Resend Request message that prompted the sequence number reset. | int(9) |
| <Standard trailer>  | Y | — | — | — |


## Application messages

### New Order – Single

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 

| Tag  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=D | — |
| 11 | ClOrdID | Y | — | Unique identifier for the order assigned by the customer. | String(11) |
| 21 | HandlInst | Y | 1=Automated execution order | Instructions for handling the order. | char(1) |
| 55 | Symbol | Y | — | Currency pair for the order. | String(35) |
| 54 | Side | Y | 1=Buy
2=Sell | 1 (Buy): The customer buys `Currency` (#15).
2 (Sell): The customer sells `Currency` (#15). | char(1) |
| 60 | TransactTime | Y | — | Time this order was initiated by the trading system. | UTCTimestamp(21) |
| 38 | OrderQty | Y | — | Order quantity. Must be a positive number. | Qty(20) |
| 40 | OrdType | Y | 2=Limit
P=Pegged@mid | Type of order. | char(1) |
| 44 | Price | Y | — | Specifies the limit price for limit orders `OrdType` (#40)=2 and Pegged orders `OrdType` (#40)=P. | Price(20) |
| 15 | Currency | Y | — | Identifies currency used for prices. | Currency(3) |
| 18 | ExecInst | Y | B=Match with all available liquidity | Specifies the liquidity that should be used for executing the order. | char(2) |
| 59 | TimeInForce | Y | 0=DAY
1=GTC (Good Till Cancel)
3=IOC (Immediate Or Cancel)
4=FOK (Fill Or Kill) | Specifies how long the order remains in effect. | char(1) |
| 126 | ExpireTime | C | _ | Required when `TimeInForce` (#59) = 6 (GTT/GTD).
The relative or absolute expiry time 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.

 | UTCTimestamp (21) |
| 210 | MaxShow | N | — | Maximum quantity of the order shown to other customers.
If not specified, then the entire order amount is shown to other customers.
The value of this tag must be between 0 (zero) and the value in `OrderQty` (#38). | Qty(20) |
| 110 | MinQty | N | — | Minimum fill quantity. | Qty(20) |
| 167 | SecurityType | N | FOR=Foreign Exchange Contract | Indicates type of security. | String(3) |
| 460 | Product | N | 4=CURRENCY | The asset class. | int(1) |
| <Standard trailer>  | Y | — | — | — |


### Order Cancel Request

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 

| Tag  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=F | — |
| 41 | OrigClOrdID | Y | — | `ClOrdID` (#11) value of the order being canceled | String(11) |
| 11 | ClOrdID | Y | — | Unique identifier for the cancel request assigned by the customer. | String(11) |
| 55 | Symbol | Y(API) | — | Currency pair for the order. | String(35) |
| 54 | Side | Y | 1=Buy
2=Sell | 1 (Buy): The customer buys `Currency` (#15).
2 (Sell): The customer sells `Currency` (#15). | char(1) |
| 60 | TransactTime | Y | — | Time the cancel request was initiated by the customer app. | UTCTimestamp(21) |
| 460 | Product | N | 4=CURRENCY | The asset class. | int(1) |
| <Standard trailer>  | Y | — | — | — |


### Order Cancel/Replace Request

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))


The Order Cancel/Replace Request message should not be used to cancel an existing order without replacement. To cancel an existing order, the Order Cancel Request message should be used.

Valid responses 

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


Message format 

Order Cancel/Replace Request format 

| Tag  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=G | — |
| 37 | OrderID | Y(API) | — | Unique identifier for the order assigned by Integral. | String(20) |
| 41 | OrigClOrdID | Y | — | `ClOrdID` (#11) of the order being canceled or replaced. This order should not be a filled or rejected order. | String(11) |
| 11 | ClOrdID | Y | — | Unique identifier for the cancel/replace request assigned by customer. | String(11) |
| 21 | HandInst | Y | 1 = Automated execution order | Instructions for handling the order. | char(1) |
| 55 | Symbol | Y(API) | — | Currency pair for the order. Must match the original order. | String(35) |
| 54 | Side | Y | 1=Buy
2=Sell | 1 (Buy): The customer buys `Currency` (#15).
2 (Sell): The customer sells `Currency` (#15). | char(1) |
| 60 | TransactTime | Y | — | Time the cancel/replace request was initiated by the customer app. | UTCTimestamp(21) |
| 38 | OrderQty | Y | — | Amount for the new (replaced) order. Must be a positive number. | Qty(20) |
| 40 | OrdType | Y | 2=Limit
P=Pegged@mid | Type of order. Must match the original order. | char(1) |
| 44 | Price | Y | — | Specifies the limit price for limit orders `OrdType` (#40)=2 and Pegged orders `OrdType` (#40)=P. | Price(20) |
| 15 | Currency | Y(API) | — | Identifies currency used for amount. Must match the original order. | Currency(3) |
| 18 | ExecInst | Y | B=Match with all available liquidity | Specifies the liquidity that should be used for executing the order. | char(1) |
| 59 | TimeInForce | Y | 0=DAY
1=GTC (Good Till Cancel)
3=IOC (Immediate Or Cancel)
4=FOK (Fill Or Kill) | Specifies how long the order remains in effect. Must match the original order. | char(1) |
| 210 | MaxShow | N | — | Maximum quantity of the order shown to other customers.
If not specified, then the entire order amount is shown to other customers.
The value of this tag must be between 0 (zero) and the value in `OrderQty` (#38). | Qty(20) |
| 110 | MinQty | N | — | Minimum fill quantity. | Qty(20) |
| 167 | SecurityType | N | FOR=Foreign Exchange Contract | Indicates type of security. | String(3) |
| 460 | Product | N | 4=CURRENCY | The asset class. | int(1) |
| <Standard trailer>  | Y | — | — | — |


### Order Status Request

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 

| Tag  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=H | — |
| 11 | ClOrdID | Y | — | The `ClOrdID` (#11) of the order whose status is being requested. | String(11) |
| 37 | OrderID | Y(API) | — | Unique identifier for the order assigned by Integral. | String(20) |
| 55 | Symbol | Y(API) | — | Currency pair for the order. | String(35) |
| 54 | Side | Y | 1=Buy
2=Sell | 1 (Buy): The customer buys `Currency` (#15).
2 (Sell): The customer sells `Currency` (#15). | char(1) |
| <Standard trailer>  | Y | — | — | — |


### Execution Report

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](#order-create-or-cancelreplace)
* [Fill](#fill)
* [Order reject](#order-reject)
* [Order cancel or expire](#order-cancel-or-expire)
* [Order status](#order-status)


#### Order create or cancel/replace

Execution Report format: create or cancel/replace 

| Tag  |  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=8 | — |
| 37 | OrderID | Y | — | Unique identifier for the order assigned by Integral. For a response to a Cancel/Replace request, this is the new order ID. | String(20) |
| 11 | ClOrdID | Y | — | Unique identifier for the order assigned by the customer. | String(11) |
| 150 | ExecType | Y | 0=New | Describes the purpose of the execution report. | char(1) |
| 39 | OrdStatus | Y | 0=New | char(1) |
| 55 | Symbol | Y | — | Currency pair for the order | String(35) |
| 54 | Side | Y | 1=Buy
2=Sell | 1 (Buy): The customer buys `Currency` (#15).
2 (Sell): The customer sells `Currency` (#15). | char(1) |
| 38 | OrderQty | Y | — | Amount to be traded on the order | Qty(20) |
| 40 | OrdType | Y | 2=Limit | Type of order | char(1) |
| 44 | Price | Y | — | Specifies the limit price for limit orders `OrdType` (#40)=2 and Pegged orders `OrdType` (#40)=P. | Price(20) |
| 15 | Currency | Y(API) | — | Identifies currency used for amount | Currency(3) |
| 167 | SecurityType | N | FOR=Foreign Exchange Contract | Indicates type of security | String(4) |
| 59 | TimeInForce | Y | 0=DAY
1=GTC (Good Till Cancel)
3=IOC (Immediate Or Cancel)
4=FOK (Fill Or Kill) | Specifies how long the order remains in effect | char(1) |
| 31 | LastPx | C | 0 (zero) | Price for the fill. Populated if `ExecType` (#150)=F (Trade), 0 (zero) otherwise. | Price(20) |
| 32 | LastQty | C | 0 (zero) | Quantity for the fill. Populated if `ExecType` (#150)=F (Trade), 0 (zero) otherwise. | Qty(20) |
| 151 | LeavesQty | Y | — | Unfilled amount for the order or quantity available for further execution. | Qty(20) |
| 60 | TransactTime | Y | — | Time the transaction represented by this execution report occurred. | UTCTimestamp(21) |
| 110 | MinQty | N | — | Minimum fill quantity for an order | Qty(20) |
| 210 | MaxShow | N | — | Maximum quantity of the order shown to other customers.
If not specified, then the entire order amount is shown to other customers.
The value of this tag must be between 1 and the value in `OrderQty` (#38). | Qty(20) |
| 460 | Product | N | 4=CURRENCY | Identifies the type of the instrument. | int(1) |
| <Standard trailer>  | Y | — | — | — |


#### Order status

Execution Report format: order status 

| Tag  |  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=8 | — |
| 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. | String(11) |
| 150 | ExecType | Y | I=Order Status | Describes the purpose of the execution report. | char(1) |
| 39 | OrdStatus | Y | 0=New
1=Partially Filled
2=Filled
U=Undefined | Describes the current state of the order. | char(1) |
| 103 | OrdRejReason | C | 5=Unknown Order | Reason the order status report request is being rejected.
Required when `ExecType` (#150)=8 (for example, when an order is rejected). | int(4) |
| 58 | Text | C | — | The rejection reason. Present if the order could not be found. | String(100) |
| 378 | ExecRestatementReason | N | — | Contains the rejection reason when the rejection is caused by an Internal Rejection. | String(100) |
| 55 | Symbol | Y | — | Currency pair for the order | String(35) |
| 54 | Side | Y | 1=Buy
2=Sell | 1 (Buy): The customer buys `Currency` (#15).
2 (Sell): The customer sells `Currency` (#15). | char(1) |
| 38 | OrderQty | Y | — | Amount to be traded on the order | Qty(20) |
| 40 | OrdType | Y | 2=Limit | Type of order | char(1) |
| 44 | Price | N | — | Specifies the limit price for limit orders `OrdType` (#40)=2 and Pegged orders `OrdType` (#40)=P. | Price(20) |
| 15 | Currency | Y(API) | — | Identifies currency used for amount | Currency(3) |
| 167 | SecurityType | N | FOR=Foreign Exchange Contract | Indicates type of security | String(4) |
| 59 | TimeInForce | Y | 0=DAY
1=GTC (Good Till Cancel)
3=IOC (Immediate Or Cancel)
4=FOK (Fill Or Kill) | Specifies how long the order remains in effect | char(1) |
| 151 | LeavesQty | Y | — | Unfilled amount for the order or quantity available for further execution. | Qty(20) |
| 14 | CumQty | Y | — | Currently executed quantity for the order. | Qty(20) |
| 6 | AvgPx | Y | — | Calculated average price for all fills on this order. | Price(20) |
| 60 | TransactTime | Y | — | Time the order status report acknowledgment was generated | UTCTimestamp(21) |
| 110 | MinQty | N | — | Minimum fill quantity for an order | Qty(20) |
| 790 | OrdStatusReqID | N | — | Contains the `ClOrdID` (#11) present in the Order Status Request. | String(11) |
| 210 | MaxShow | N | — | Maximum quantity of the order shown to other customers.
If not specified, then the entire order amount is shown to other customers.
The value of this tag must be between 1 and the value in `OrderQty` (#38). | Qty(20) |
| 460 | Product | N | 4=CURRENCY | Identifies the type of the instrument. | int(1) |
| <Standard trailer>  | Y | — | — | — |


#### Fill

Execution Report format: fill 

| Tag  |  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=8 | — |
| 116 | OnBehalfOfSubID | C | — | Unique identifier of the liquidity provider associated with the fill. Not populated by default. You must contact your Integral Technical Account Manager to enable this field. When enabled, it is populated if `ExecType` (#150)=F (Trade). | String(20) |
| 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. | String(11) |
| 17 | ExecID | Y | — | Unique identifier of execution message as assigned by Integral. Populated if `ExecType` (#150)=F (Trade). | String(20) |
| 375 | ContraBroker | C | — | Identifies the executing broker.
Required if `ExecType` (#150)=F (Trade). | String(20) |
| 150 | ExecType | Y | F=Trade | Describes the purpose of the execution report. | char(1) |
| 39 | OrdStatus | Y | 1=Partially Filled
2=Filled | Identifies if the order is partially filled or completely filled. | char(1) |
| 64 | SettlDate | C | — | Trade settlement date
Required if `ExecType` (#150)=F (Trade). | LocalMktDate(8) |
| 55 | Symbol | Y | — | Currency pair for the order | String(35) |
| 54 | Side | Y | 1=Buy
2=Sell | 1 (Buy): The customer buys `Currency` (#15).
2 (Sell): The customer sells `Currency` (#15). | char(1) |
| 38 | OrderQty | Y | — | Amount to be traded on the order | Qty(20) |
| 40 | OrdType | Y | 2=Limit | Type of order | char(1) |
| 44 | Price | N | — | Specifies the limit price for limit orders `OrdType` (#40)=2 and Pegged orders `OrdType` (#40)=P.
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. | Price(20) |
| 15 | Currency | Y(API) | — | Identifies currency used for amount | Currency(3) |
| 167 | SecurityType | N | FOR=Foreign Exchange Contract | Indicates type of security | String(4) |
| 59 | TimeInForce | Y | 0=DAY
1=GTC (Good Till Cancel)
3=IOC (Immediate Or Cancel)
4=FOK (Fill Or Kill) | Specifies how long the order remains in effect | char(1) |
| 194 | LastSpotRate | N | — | FX spot: Not applicable.
FX outright: Spot rate
FX swap: Near-leg spot rate | Price(20) |
| 31 | LastPx | C | — | Price of this (last) fill. Required if `ExecType` (#150)=F (Trade). | Price(20) |
| 32 | LastQty | C | — | Quantity bought/sold on this (last) fill. Required if `ExecType` (#150)=F (Trade). | Qty(20) |
| 151 | LeavesQty | Y | — | Unfilled amount for the order or quantity available for further execution. | Qty(20) |
| 14 | CumQty | Y | — | Currently executed quantity for the order. | Qty(20) |
| 6 | AvgPx | Y | — | Calculated average price for all fills on this order. | Price(20) |
| 75 | TradeDate | C | — | Indicates the business date for the trade referenced in this message. Required if `ExecType` (#150)=F (Trade). | LocalMktDate(8) |
| 119 | SettlCurrAmt | C | — | Amount of the fill expressed in the settlement currency. Required if `ExecType` (#150)=F (Trade). | Amt(20) |
| 120 | SettlCurrency | N | — | Settlement currency. Required if `ExecType` (#150)=F (Trade). | Currency(3) |
| 60 | TransactTime | Y | — | Time the transaction represented by this execution report occurred. | UTCTimestamp(21) |
| 110 | MinQty | N | — | Minimum fill quantity for an order | Qty(20) |
| 210 | MaxShow | N | — | Maximum quantity of the order shown to other customers.
If not specified, then the entire order amount is shown to other customers.
The value of this tag must be between 1 and the value in `OrderQty` (#38). | Qty(20) |
| 460 | Product | N | 4=CURRENCY | Identifies the type of the instrument. | int(1) |
| <Standard trailer>  | Y | — | — | — |


#### Order reject

Execution Report format: reject 

| Tag  |  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=8 | — |
| 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. | String(11) |
| 150 | ExecType | Y | 8=Rejected | Describes the purpose of the execution report. | char(1) |
| 39 | OrdStatus | Y | 8=Rejected | Describes the current state of the order. | char(1) |
| 103 | OrdRejReason | C | — | Reason the order status report request is being rejected.
Required when `ExecType` (#150)=8 (for example, when an order is rejected). | int(4) |
| 58 | Text | C | — | The rejection reason. | String(100) |
| 378 | ExecRestatementReason | N | — | Contains the rejection reason when the rejection is caused by an Internal Rejection. | String(100) |
| 55 | Symbol | Y | — | Currency pair for the order | String(35) |
| 54 | Side | Y | 1=Buy
2=Sell | 1 (Buy): The customer buys `Currency` (#15).
2 (Sell): The customer sells `Currency` (#15). | char(1) |
| 38 | OrderQty | Y | — | Amount to be traded on the order | Qty(20) |
| 40 | OrdType | Y | 2=Limit | Type of order | char(1) |
| 44 | Price | N | — | Specifies the limit price for limit orders `OrdType` (#40)=2 and Pegged orders `OrdType` (#40)=P. | Price(20) |
| 15 | Currency | Y(API) | — | Identifies currency used for amount | Currency(3) |
| 167 | SecurityType | N | FOR=Foreign Exchange Contract | Indicates type of security | String(4) |
| 59 | TimeInForce | Y | 0=DAY
1=GTC (Good Till Cancel)
3=IOC (Immediate Or Cancel)
4=FOK (Fill Or Kill) | Specifies how long the order remains in effect | char(1) |
| 31 | LastPx | C | 0 (zero) | Price for the fill. Populated if `ExecType` (#150)=F (Trade), 0 (zero) otherwise. | Price(20) |
| 32 | LastQty | C | 0 (zero) | Quantity for the fill. Populated if `ExecType` (#150)=F (Trade), 0 (zero) otherwise. | Qty(20) |
| 151 | LeavesQty | Y | 0 (zero) | Quantity available for further execution. Always 0 (zero) for rejected orders. | Qty(20) |
| 14 | CumQty | Y | 0 (zero) | Currently executed quantity for the order.
Always 0 (zero) for rejected orders. | Qty(20) |
| 6 | AvgPx | Y | 0 (zero) | Calculated average price for all fills on this order.
Always 0 (zero) for rejected orders. | Price(20) |
| 60 | TransactTime | Y | — | Time the transaction represented by this execution report occurred. | UTCTimestamp(21) |
| 110 | MinQty | N | — | Minimum fill quantity for an order | Qty(20) |
| 210 | MaxShow | N | — | Maximum quantity of the order shown to other customers.
If not specified, then the entire order amount is shown to other customers.
The value of this tag must be between 1 and the value in `OrderQty` (#38). | Qty(20) |
| 460 | Product | N | 4=CURRENCY | Identifies the type of the instrument. | int(1) |
| <Standard trailer>  | Y | — | — | — |


#### Order cancel or expire

Execution Report format: cancel or expire 

| Tag  |  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=8 | — |
| 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. | String(11) |
| 150 | ExecType | Y | 4=Canceled
6=Pending Cancel
C=Expired | Describes the purpose of the execution report. | char(1) |
| 39 | OrdStatus | Y | 4=Canceled
6=Pending Cancel
C=Expired | Describes the current state of the order. | char(1) |
| 55 | Symbol | Y | — | Currency pair for the order | String(35) |
| 54 | Side | Y | 1=Buy
2=Sell | 1 (Buy): The customer buys `Currency` (#15).
2 (Sell): The customer sells `Currency` (#15). | char(1) |
| 38 | OrderQty | Y | — | Amount to be traded on the order | Qty(20) |
| 40 | OrdType | Y | 2=Limit | Type of order | char(1) |
| 44 | Price | C | — | Specifies the limit price for limit orders `OrdType` (#40)=2 and Pegged orders `OrdType` (#40)=P.
Required for limit orders (`OrdType` (#40)=2) and optional for Pegged orders (`OrdType` (#40)=P). | Price(20) |
| 15 | Currency | Y(API) | — | Identifies currency used for amount | Currency(3) |
| 167 | SecurityType | N | FOR=Foreign Exchange Contract | Indicates type of security | String(4) |
| 59 | TimeInForce | Y | 0=DAY
1=GTC (Good Till Cancel)
3=IOC (Immediate Or Cancel)
4=FOK (Fill Or Kill) | Specifies how long the order remains in effect | char(1) |
| 151 | LeavesQty | Y | 0 (zero) | Quantity available for further execution. Always 0 (zero) for expired orders. | Qty(20) |
| 14 | CumQty | Y | — | Currently executed quantity for the order. | Qty(20) |
| 6 | AvgPx | Y | — | Calculated average price for all fills on this order. | Price(20) |
| 60 | TransactTime | Y | — | Time the transaction represented by this execution report occurred. | UTCTimestamp(21) |
| 110 | MinQty | N | — | Minimum fill quantity for an order | Qty(20) |
| 210 | MaxShow | N | — | Maximum quantity of the order shown to other customers.
If not specified, then the entire order amount is shown to other customers.
The value of this tag must be between 1 and the value in `OrderQty` (#38). | Qty(20) |
| 460 | Product | N | 4=CURRENCY | Identifies the type of the instrument. | int(1) |
| <Standard trailer>  | Y | — | — | — |


### Order Cancel Reject

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 

| Tag  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=9 | — |
| 37 | OrderID | Y | — | Unique identifier for the order assigned by Integral. If `CxlRejReason` (#102) = Unknown Order, this value will be set to NONE. | String(20) |
| 11 | ClOrdID | Y | — | Unique, customer-assigned identifier for the cancel request or cancel/replace request that is being rejected. | String(11) |
| 41 | OrigClOrdID | Y | — | `ClOrdID` (#11) of the order that could not be canceled. | String(11) |
| 39 | OrdStatus | Y | U=Undefined | The order for which status has been requested is not present in the order book and cannot be found. Please contact Integral Customer Support. | char(1) |
| 58 | Text | N | — | The reason code for the Order Cancel rejection. | String(150) |
| 434 | CxlRejResponseTo | Y | 1=Order Cancel Request
2=Order Cancel/Replace Request | Identifies the type of request the cancel is in response to. | char(1) |
| 102 | CxlRejReason | Y | — | Code to identify reason for cancel rejection. | int(1) |
| <Standard trailer>  | Y | — | — | — |


### Business Message Reject

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 

| Tag  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=j | — |
| 372 | RefMsgType | Y | D=New Order - Single
G=Order Cancel/Replace Request | The `MsgType` (#35) of the message being referenced. | String(2) |
| 379 | BusinessRejectRefID | Y | — | The `ClOrdID` (#11) of the rejected message. | String(11) |
| 380 | BusinessRejectReason | Y | — | Reason code. | String(4) |
| 58 | Text | Y | — | Text description of rejection reason. | String(150) |
| <Standard trailer>  | Y | — | — | — |


## Changes

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

API and document changes 

| Date (document version) | Changes |
|  --- | --- |
| August 2024
(1.0v16)
 | You can now specify relative and absolute expiry times with the `ExpireTime` (#126) field.
In previous releases, only the time portion of the `ExpireTime` (#126) field was processed. In the format *YYYYMMDD-hh:mm:ss.sss* the date portion *YYYYMMDD* was ignored.
The date portion of the `ExpireTime` (#126) field can now be specified to enable GTD (good-til-date) orders:
* Relative expiry: set the date portion to `00000000`. For example, for expiry 30 seconds from receipt, you would specify `126=00000000-00:00:30.000`.
* Absolute expiry (new feature): 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`.

 |
| July 2024
(1.0v15) | First distribution. |