Order Entry

• Body encoding OE (See BTP Body Encoding).
• Requires a login (See Login).
• Sends market state updates (See Market State).

Order Entry IDs

• orderId: A customer-defined, per connectionId, unique order identifier. This ID stays the same across subsequent modifications of the specific order.

• modifyId: A customer-defined, per orderId, unique modify identifier. This ID must be different across subsequent modifications of the specific order.

• ackId: A matching engine-defined, per engine instance, unique identifier for messages successfully applied to the order book. This ID includes Ack, Fill, and Closed messages but excludes Reject messages.

• The (ackId, orderId) pair uniquely identifies an order accepted by the matching engine and applied to the order book.

• The (ackId, orderId, modifyId) triplet uniquely identifies a modify to the respective order.

Order Condition

From BTP version 4, Open, Attributed Open, and Modify requests carry a one-byte orderCondition field:

Any other value fails to parse and the connection is disconnected with reason 0x05 (Failed to parse message). The condition applies to the individual request and is not stored on the resting order, so a Modify must re-assert the condition just as an Open does.

Order Entry Request

Open

Order types: All orders are limit orders. We do not support market orders, stops, stop limits, etc. We support Day and IOC orders for Time in Force.

BTP v2/v3 body:

BTP v4 body:

Attributed Open

An Attributed Open is an Open that specifies which clearing account the order belongs to. This allows a single connection to submit orders on behalf of multiple clearing accounts associated with the connection's clearing firm. The accountId is the textual account code assigned by the clearing firm and is scoped to the clearingMemberFcmCode.

From BTP version 4, an Attributed Open may also carry a per-order Customer Type Indicator (CTI) code in the cti field. A non-zero cti value applies to the attributed order instead of the CTI configured for the connection's clearing account; a 0 value means the configured CTI applies. In earlier protocol versions the CTI cannot be specified per order and the configured CTI always applies. See Rule 511 for CTI code definitions.

BTP v2/v3 body:

BTP v4 body:

Replies follow the same Ack, Reject, Closed, and Fill messages as Open. An accountId that cannot be resolved against the connection's clearing firm produces a Reject with reason 0x01 (Account not found).

Modify

Cancels: A modify with a quantity less than or equal to the order's fill quantity cancels the order. A modify that changes the price and sets the quantity to less than or equal to the order's fill quantity cancels the order and the price change is ignored. A quantity = 0 will short circuit the price limit rules. A modify order with quantity > 0 must conform to the price limit rules regardless of order cancellation.

BTP v2/v3 body:

BTP v4 body:

Note: NULL is indistinguishable from 0 in the case of modifyId. It is highly recommended to not use 0 as a modifyId to avoid this ambiguity.

Order Entry Reply

Ack

BTP v2/v3 body:

BTP v4 body:

From BTP version 4, acks echo the authoritative state of the order after the acked request. For an open ack, quantity is the quantity as submitted and filled is always 0. For a modify ack, quantity is the post-modify quantity, clamped down to filled if the modify reduced the quantity to or below the filled quantity — so quantity == filled (zero leaves) on a modify ack indicates the order is closed.

Reject

Reject Reason

Request processing, and respective reject precedence, is as follows:

1. Connection state (ex: enabled/disabled)
2. Order state (ex: order closed)
3. Quantity (a modify with a closing quantity is processed regardless of an invalid price modification)
4. Price

Closed

A closed message will be sent when the order state cannot be inferred from the normal request-reply flow. This happens when an IOC is finished matching, self-match is prevented, or a customer cancels an order outside the order entry gateway connection.

A closed message will not be sent when an order is fully filled or a modify is acked, closing the order. For example, if an IOC misses or is partially filled, a closed message will be sent. If the IOC is fully filled, a closed message will not be sent.

BTP v2/v3 body:

BTP v4 body:

From BTP version 4, closed messages echo the closed order's product, side, and resting price so the closure can be attributed without local order state.

Close Reason

Fill

BTP v2 body:

BTP v3 body:

From BTP version 3, fills carry the productId of the filled order.

BTP v4 body:

From BTP version 4, fills additionally carry the cumulative filled quantity of the order after this fill, so leaves can be tracked without counting fills locally.

When dealing with calendar spreads, 3 Fill messages are sent for each match. One will have either A or R liquidity corresponding to the spread contract itself. Then there will be one Fill message for each leg with S liquidity and 0 quantity which have the implied price. The order of these fills is guaranteed, where the spread fill is always immediately followed by the leg 1 fill and the leg 2 fill in that order.

Message Rate Throttling

Order entry requests are limited using a sliding window throttle. Unless otherwise stated or negotiated, order entry gateways have a 500 message per 3 seconds messaging rate. Cancels are always allowed past the messaging rate throttle. Rejects are sent in response to messages exceeding the message rate limit with a reason code 0x10 (Message rate exceeded).