# Cboe Titanium Cboe Futures Exchange BOEv3 Specification

Version 1.1.33 · June 29, 2026

## Introduction

This document describes Binary Order Entry, version 3 (BOEv3), the CBOE proprietary order entry protocol used by a Trading Privilege Holder (TPH) to send orders and quotes to the Cboe Futures Exchange (CFE) in futures and options products. Features only applicable to Options on Futures will be notated with (Options Only).

Where applicable, the terminology (e.g., time in force) used in this document is similar to that used by the FIX protocol to allow those familiar with FIX to more easily understand BOEv3. This document assumes the reader has basic knowledge of the FIX protocol.

BOEv3 fulfills the following requirements:

- CPU and memory efficiency. Message encoding, decoding, and parsing are simpler to code and can be optimized to use less CPU and memory at runtime.
- Application level simplicity. State transitions are simple and unambiguous. They are easy to apply to a TPH's representation of an order.
- Session level simplicity. The session level protocol (login, sequencing, replay of missed messages, logout) is simple to understand.

While CFE strives to preserve feature parity between FIX and BOEv3 where possible, some features may only be available in one protocol or the other.

Note that while FIX is an ASCII based protocol, BOE is binary based, providing for efficiencies that can allow for reduced latency. Additionally, FIX and BOEv2 messages pass through an additional process not applicable to BOEv3 messages before being ordered for processing by receipt time at the BOEv3 order handler, which can allow for reduced latency for BOEv3 messages relative to FIX/BOEv2 messages.

All binary values are in little-endian (as used by Intel x86 processors), and not network byte order.

Each message is identified by a unique message type. A listing of the supported message types is provided in Session Message Types and Application Message Types.

All communication is via standard TCP/IP.

### Differences with prior versions of BOE

Notable differences between BOEv3 and the prior major version of BOE (BOEv2) include:

1. BOEv3 has statically sized messages except when sizing variability is required due to (statically sized) repeating groups of fields. Consequently, BOEv3 does not support optional fields on input nor bitfield-specified optional return fields. This provides a more consistent and predictable experience for all users.
2. Connectivity is now managed as a port specific to a matching unit. Consequently, separate ports will be required for access to each matching unit.
3. The `Logout Response` message no longer returns the LastReceivedSequenceNumber, nor the highest available sequence numbers of the matching unit(s).
4. There is no longer a systematically enforced limit on the number of open orders or quotes a firm may have entered on the exchange.
5. BOEv3 requires that the EFID (ClearingFirm) be specified on all `Cancel Order` and `Modify Order` messages (either via Port default or by specifying in the message). This differs from prior versions of BOE where this was only required of service bureau TPHs.
6. If CustOrderHandingInst is not specified on a `Modify Order` message the port default will be applied. In prior versions of BOE, the CustOrderHandingInst would have been carried forward from the current version of the order.
7. When logging in, TPHs may specify a behavior of "Fail" for unspecified matching units (fail the login if a matching unit was not specified). This in addition to the "Skip" and "Replay" behaviors, as detailed in Login, Replay, and Sequencing.
8. The `Cancel Order` message type now cancels a single order. A new message type `Mass Cancel Order` provides all multi-order cancellation requests.
9. There no longer exists a condition where a TPH would send a `Modify Order` followed immediately by a `Cancel Order` message and it was not deterministic as to which OrigClOrdId value was correct on the `Cancel Order` message. In BOEv3, the OrigClOrdId on a cancel should be the ClOrdId sent on the most recent `Modify Order` (or `New Order` if no modifies have been sent), even if the corresponding response has not yet been seen. CancelOrigOnReject should be set to `Y` to ensure that a rejected `Modify Order` does not leave behind a live order.
10. TPH risk trips and self-imposed lockouts are now required to be reset using the `Reset Risk` message. They can no longer be reset via the `New Order` message.
11. BOEv3 `Trade Cancel or Correct` messages are not suppressible by port parameter.
12. Added requirement for TPHs to record and connect to secondary IP in event of failover to secondary port in the primary, Secaucus Datacenter as detailed in Failover and Disaster Recovery (DR).
13. Risk resets on a BOEv3 port only apply for the unit associated with that port. In BOEv2 and FIX, risk resets apply to all units.
14. Unlike BOEv2, BOEv3 does not support sequenced messages from TPH to CFE with a sequence number of zero. A sequenced BOEv3 message sent from TPH to CFE having a sequence number of zero will disconnect the port.
15. BOEv3 introduces a number of changes to the information returned to the member in the Application Messages:
  1. MaturityDate will return with all zeros (i.e. blank) if it is all zeros on input.
  2. TimeInForce will no longer be included on `Order Modified`, as this field is unmodifiable.
  3. `Order Acknowledgment` will no longer include the fields DayOrderQty, DayCumQty, AvgPx, and DayAvgPx as they have limited use in an order ack.
  4. QuoteRejectReason will no longer be included on the `Quote Update Acknowledgment` message since all rejects of an entire message block are reported via the `Quote Update Rejected` message.
  5. In the `Order Rejected` message, the optional fields from BOEv2 which echoed back fields of the rejected order are no longer supported; only ClOrdId and ClearingFirm are included on the rejection message.
  6. In the `Order Modified` message, several optional fields supported under BOEv2 are not included in BOEv3 in the interest of message brevity: Side, OrdType, TimeInForce, MinQty, Symbol, Capacity, Account, ClearingAccount, PreventMatch, MaturityDate, OpenClose, ExpireTime, CmtaNumber, CtiCode, OEOID.
  7. In the `Order Cancelled` and `Cancel Rejected` messages, none of BOEv2 the optional fields are included.
  8. In the `Order Executed` message, the BOEv2 field ContraBroker has been removed (it was always `CFE`).
  9. In the `Order Executed` message, several BOEv2 optional fields are no longer included in this message in the interest of message brevity: Price, PrdType, TimeInForce, MinQty, Capacity, Account, ClearingAccount, OrderQty, PreventMatch, OpenClose, ExpireTime, StopPx, CmtaNumber, CtiCode, ManualOrderIndicator, OEOID, TradeDate, CumQty, DayOrderQty, DayCumQty, AvgPx, DayAvgPx.
  10. In the `TAS Restatement` message, several BOEv2 optional fields are no longer included in the BOEv3 message in the interest of message brevity: OrdType, TimeInForce, MinQty, Capacity, Account, ClearingFirm, ClearingAccount, PreventMatch, MaturityDate, OpenClose, OrigClOrdId, StopPx,CmtaNumber, CritCode, ManualOrderIndicator, OEOID, FrequentTraderId, CustOrderHandlingType.
  11. In the `Order Cancelled` message, none of the optional BOEv2 fields are present in the BOEv3 version of the message.
  12. A new field, RequestReceivedTime, has been added to the `Order Acknowledgement`, `Quote Update Acknowledgement`, `Order Modified`, `Order Cancelled`, and `Mass Cancel Acknowledgment` messages. This will inform the TPH of the earliest timestamp, with nanosecond precision, recorded by CFE of the corresponding inbound message being acknowledged. This will be the timestamp as received in turn by the process providing all Unit Ports for the matching unit (BOEv3 ports are provided per matching unit).

### BOEv3 Message Format Versioning and Nomenclature

Since BOEv3 uses a more rigidly structured message format than prior versions of BOE, message types may be introduced when new fields cannot be accommodated by utilizing reserve bytes in the existing message specification. In such cases, when a new message type is introduced, it will be documented as a distinct message type in this document. Application layer message types are named using the following pattern:

| Application Layer Message Type | General Type | Market | Version |
|---|---|---|---|
| `NewOrderUSFuturesV1` | `New Order` | `USFutures` | `V1` |

This allows for ease of distinction between similar message types between markets (for example, US Futures compared to US Options), and the handling of new versions of the message (V1, V2, etc).

When application layer message types are discussed in this document, they are being referred to using their general type name unless their specific version is relevant to the documentation.

During any time when multiple versions of messages from CFE to TPH are supported concurrently, the configuration of the port determines which message version may be sent by CFE.

### Introduction of New Fields in Existing BOEv3 Messages

Existing message fields will not change in length. Fields currently identified as "Reserved" may be redefined, in part or in whole, as new specified fields. New fields may be introduced at the end of any message that does not have a repeating group of fields; consequently, TPHs must check the length of messages received from CFE and treat any additional bytes present as undefined values.

### Failover and Disaster Recovery (DR)

Each BOEv3 session assigned to a TPH will have three total ports available for the TPH’s use:

- Secaucus Primary port (A)
- Secaucus Secondary port (B)
- Chicago DR port (C)

All three ports will have distinct IP addresses assigned. During normal operation, only the primary port in Secaucus (port A) will accept a login request and order/quote traffic. Port B will not accept any login attempts until it is promoted to a primary state due to the failure of Port A. As a result of this design, TPHs may design their system to try to connect to either Port A or Port B and can be confident that the port that accepts their connection is the current primary. Port A and Port B will share common sequences, and in the event of a failover to Port B a TPH should expect sequencing to continue from where it left off on Port A.

The DR port (Port C) will accept login attempts during normal trading operations but will reject all orders and quotes. This means that this port should not be included in a list that the TPH uses for round-robin login attempts on a normal trading day. Port C will reject all orders and quotes until CFE promotes its disaster recovery site to be the primary site. While this may occur intraday, it will only occur only after CFE has provided notification to TPHs. Port C will not share common sequences with Ports A and B. As a result, in the event that a DR failover to the secondary site is performed TPHs should expect all unit sequences to be zero.

To reduce possibility of a single NIC software issue impacting both primary and secondary BOE3 processes Cboe will, by default, configure Port B and C with some features disabled so that a zero value is returned for RequestReceivedTime when Port B or C is promoted to primary state due to the failure of Port A.

### Certification Requirement

All customers must complete a formal certification in the appropriate Cboe Certification test environment before production orders or quotes will be accepted by Cboe. Formal certification scripts can be found in the Cboe Customer Web Portal. Customers may complete the formal certification using the Certification Tool app and selecting the applicable certification script. Customers are advised to test all functionality they plan to use in production in the Cboe Certification test environment.

### Hours of Operation

Refer to the website for the CFE Hours and Holidays.

CFE trading hours vary by product and for expiring and non-expiring contracts. See the product contract specifications for details on trading hours for each product. The simulated Pre-Open period for ZVXT will begin within the same randomized three second time range during which VXT will go into a Pre-Open state.

BOEv3 sessions are available for connection on Sunday starting by 10:30 a.m. CT. BOE sessions will disconnect each day between 4:05 and 4:45 p.m. CT for the daily restart. This will reset all sequences to zero in preparation for the next trading segment. BOE sessions will disconnect on Friday at around 4:05 p.m. CT but will remain available for connectivity testing (telnet testing) until startup on the following Sunday.

### Submission Time Frames for Holidays

The chart below sets forth certain time frames for the submission of quotes and orders (including `Order Cancel Request` messages and `Order Cancel/Replace` messages) for products that are open for trading in connection with a holiday. All times referenced are Central Time.

| Time Frame | CFE Trading System State | What May be Submitted to CFE’s Trading System |
|---|---|---|
| From the close of a product's trading session to five minutes after the latest-product closing of that session. | Cancel-Only Period | Cancels for all persisted orders and quotes.1 |
| From the end of the cancel-only period to system start/restart (which occurs sometime between 10:00 a.m. CT and 10:15 a.m. CT on a Sunday and sometime between 4:05 p.m. CT and 4:30 p.m. CT on a weekday). | Suspended | Nothing |
| From approximately 10 minutes prior to product's pre-open to beginning of pre-open. | Suspended | Cancels for persisted Good-'til-Cancel (GTC) and Good-'til-Date (GTD) Orders from prior trading date and Cancels for persisted Day Quotes and Orders from same trading date (if applicable) |
| See Product Trading Hours2 | Pre-Open | Quotes and Orders (except Market, Immediate or Cancel (IOC), and Fill or Kill (FOK) Orders)3 |
| Trading hours during a holiday trading session. | Extended Trading Hours | Quotes and Orders (except Market Orders). |

1The Cancel-Only Period begins immediately following the end of trading in each product and will continue for 5 minutes after the end of trading in the latest-closing product within that segment.

2The pre-open period at the beginning of a business day or holiday trading session for Trade-At-Settlement (TAS) single leg contract expirations and TAS spreads commences at the referenced start time for the pre-open period plus a randomized time period from 0 to 3 seconds. The pre-open period at the beginning of a business day or holiday trading session for non-TAS single leg contract expirations and non-TAS spreads commences at the referenced start time for the pre-open period plus a randomized time period from 3 to 6 seconds.

3Orders permitted to be submitted to the CFE trading system during these times are not executable until extended trading hours next commence.

### Session Disconnect for Holidays

A session disconnect will occur during the suspended state between two segments of a holiday trading session. This disconnect will not cause any orders or quotes to cancel due to Cancel on Disconnect. As a general rule, Cancel on Disconnect is not in effect between the end of the cancellation period and the system restart. TPHs may refer to the FIX and BOE specifications for further information on how to configure Cancel on Disconnect settings.

### Data Types

The following data types are used by BOEv3. The size of some data types varies by message. All data types have default values of binary zero, in both TPH to CFE and CFE to TPH contexts.

- Binary: Little Endian byte order, unsigned binary value. The number of bytes used depends on the context.
  - One byte: `FE` = 254
  - Four bytes: `64 00 00 00` = 100
- Signed Binary: Little Endian byte order, signed two's complement, binary value. The number of bytes used depends on the context.
  - One byte: `DF` = -33
  - Four bytes: `64 00 00 00` = +100
- Binary Price: Little Endian byte order value, signed two's complement, eight bytes in size, with four implied decimal places. So, if the value is -123,400, the actual value taking into account implied decimal places is -12.34.
  - `08 E2 01 00 00 00 00 00` = 123,400/10, `000` = 12.34
  - `F8 1D FE FF FF FF FF FF` = -123,400/10, `000` = -12.34
- Alpha: ASCII uppercase letters (A-Z) and lowercase letters (a-z) only. ASCII NUL (0x00) filled on the right, if necessary. The number of bytes used depends on the context.
- Alphanumeric: ASCII uppercase letters (A-Z), lowercase letters (a-z) and numbers (0-9) only. ASCII NUL (0x00) filled on the right, if necessary.
- Text: Printable ASCII characters only (binary values in the inclusive range 0x20 through 0x7E). ASCII NUL (0x00) filled on the right, if necessary.
- DateTime: 8 bytes. The date and time, in UTC, represented as nanoseconds past the UNIX epoch (00:00:00 UTC on 1 January 1970). The nanoseconds portion is used on the RequestReceivedTime field only and set to 0 by the exchange in all other fields.
  - `E0 FE 20 F7 36 71 F8 11F` = 1,294,909,373,757,324, `000` = 2011-01-13 09:02:53.757324 UTC
- Date: Little Endian byte order, unsigned binary value, 4 bytes in size. The YYYYMMDD expressed as an integer.
  - `A7 3C 34 01` = 20200615 = June 15, 2020
- Reserved: sequence of ASCII NUL (0x00) values when sent by the TPH. May contain any values when sent by the exchange, and should be ignored by the TPH.

### Protocol Features

The exchange does not guarantee messages sent by Members/TPHs to the exchange, including through protocols such as TCP. Members/TPHs are responsible to monitor the status of the messages they send to the exchange.

#### Message in Flight Settings

The maximum number of messages in flight between a FIX or BOE order handler and a CFE matching engine is 64. In addition, when the total number of unacknowledged messages between an order handler and all CFE matching engines exceeds 1024, the order handler will stop reading from the TPH-facing TCP socket. This will cause the order handler to stop removing bytes from the TCP receive buffer and will prevent the TPH from sending more TCP data through the order handler once the TPH's own configured send buffer is full.

When the total number of unacknowledged messages falls below 960, the order handler will resume reading from the TPH-facing TCP socket.

Messages in flight are defined as messages that have been sent by an order handler to a CFE matching engine that have not yet been acknowledged. Each application message sent by a CFE TPH (e.g., a new order, quote update, cancel/replace, cancel, or purge message) counts as one message for this purpose. An order handler includes a CFE FIX or unitized BOE order or quoting match capacity allocation or purge port.

CFE may update either the message in flight or the total number of unacknowledged messages settings with notice. Changes to reduce either limit will be made with a notice period of at least two weeks. CFE reserves the ability to increase either limit immediately with notice.

#### Carried Order and Quote Restatements

Good ‘til Cancel (GTC) orders, Good ‘til Date-Time (GTD) orders, and Day orders or quotes entered during partial holiday sessions can result in orders persisting between trading sessions. The CFE BOEv3 protocol provides a mechanism for clients to receive restatements for orders that have been carried forward from the previous business day trading session or prior holiday trading segment. See Port Attributes for information on available port attributes, including Carried Order Restatements. Be advised that BOEv3 ports that are enabled for Quote Updates are required to have the Carried Order Restatements port attribute enabled, and this port attribute cannot be disabled on these sessions.

When enabled, Carried Order Restatements are sent to connected clients for each product on the CFE for which orders or quotes have been carried forward from the previous business day trading session or holiday trading segment. Carried Order Restatements are generated by a given matching unit when the matching unit starts up. TPHs connected to BOEv3 ports will receive the restatements at that time. Persisted orders will be added back into the order book starting at approximately 10 minutes prior to the scheduled queuing time for each futures root. TPHs that are not connected at start up time may retrieve any Carried Order Restatements using the standard BOE replay functionality described in Login, Replay, and Sequencing.

Carried Order Restatements are represented using `Order Acknowledgement` messages with the following attributes:

- BaseLiquidityIndicator = A (Added Liquidity)
- SubLiquidityIndicator = C (Carried)

To receive Carried Order Restatements on BOEv3 sessions that are not enabled for Quote Updates, the Carried Order Restatement port attribute must be enabled (contact CFE Trade Desk). In addition, since the Carried Order Restatement messages are usually delivered to the session handler before the TPH connects, replay must be requested by setting the ReplayUnspecifiedUnit parameter of the `Login Request` message Unit Sequence Parameter Group to R (Replay) or specifically set the UnitSequence to zero in the associated unit param group to ensure replay is not suppressed.

Note that no notification is provided at the end of a trading session to indicate when GTC, GTD, or Day orders/quotes on partial holiday sessions are persisted to carry over to the next trading session. Instead, TPHs can use Carried Order Restatements to be notified of orders/quotes that have persisted from the previous session.

The number of GTC/GTD orders in test classes that can be carried over from the prior business day will be limited to three GTC/GTD orders per session per matching unit, for a total of six GTC/GTD orders per BOEv3 session group.

#### Quotes Carried Across Multiple Sessions

Quotes cannot be marked as GTC or GTD, but Day quotes can persist across multiple sessions in the case of a holiday. The same Carried Order Restatement logic applies to quotes, which means that quotes will be restated with `Order Acknowledged` messages containing the OrderId from the original `Quote Update Acknowledgement`. Quotes that are carried across multiple sessions may only be modified or cancelled by using a `Quote Update` message on the quote port where the quote originated. TPHs may determine which restatements are quotes by matching the OrderId received on a carried order restatement (`Order Acknowledgement`) to the OrderId received in the original `Quote Update Acknowledgement`.

#### Cancellation of Carried Orders or Quotes Between Sessions

GTC and GTD orders persist within CFE's trading system between CFE business days. By default, GTC, GTD, and Day orders/quotes persist between multiple trading sessions on the same business day in connection with a holiday. Persisted orders/quotes can be cancelled while the associated product is in a suspended state and during other trading states as described above.

At the end of the scheduled Cancel-Only Period for a product, cancellation requests for persisted orders/quotes in that product will be rejected with reason `O` = Order known, but cannot be canceled at this time until after the next trading segment when persisted orders/quotes are reloaded on the book. After the orders/quotes are reloaded on the book, they can be cancelled from that time until the end of the scheduled Cancel-Only Period for a product. In other words, the period of time in which persisted orders/quotes cannot be canceled starts at the end of the scheduled Cancel-Only Period for the associated product and ends after the persisted orders/quotes are reloaded on the book, after the system restarts.

Note that port Cancel on Disconnect behavior is in effect from the time persisted orders are reloaded to the book to the end of the Cancel-Only period. Clients may modify this port attribute via the logical port request tool available on the customer web portal.

The Multi-Segment Holiday Day Order Handling port attribute will enable TPHs to designate if Day orders and quotes are cancelled or preserved across holiday trading segments comprising a single business date.

**Table 1. Regular Trading Example**

| Period | Description | Time |
|---|---|---|
| System Start | System starts up but no new orders, modifies, nor cancellations are accepted. | ~10:00 a.m. CT on Sunday |
| Pre-Open and Regular Trading | New orders may be entered. Existing persisted orders may be modified or cancelled starting approximately 10 minutes before Pre-Open period begins for each product | Time varies by product |
| Product Close (PITCH status S) | Day orders are cancelled. | Time varies by product |
| Cancel-Only Period | Orders and quotes can be cancelled during a product's cancel-only period. GTC and GTD orders are persisted to the next trading date at the end of the cancel-only period. | From product close to 4:05 p.m. CT on Monday |
| System Restart1 | System starts up but no new orders, modifies, nor cancellations are accepted. | 4:05 p.m. - 4:30 p.m. CT on Monday |

**Table 2. Monday Holiday Example**

| Period | Description | Time |
|---|---|---|
| System Start | System starts up but no new orders, modifies, nor cancellations are accepted. | ~10:00 a.m. CT on Sunday |
| Pre-Open and Regular Trading for Segment 1 | New orders may be entered. Existing persisted orders may be modified or cancelled starting approximately 10 minutes before Pre-Open period begins for each product | Time varies by product |
| Product Close for Segment 1 (PITCH status S) | No new orders are accepted. | 10:30 a.m. CT on Monday |
| Cancel-Only Period | Orders and quotes can be cancelled during a product's cancel-only period. Live GTC and GTD orders are persisted to segment 2. Day Order persistence is dependent on port attribute2 | 10:30 a.m. - 10:35 a.m. CT on Monday |
| System Restart1 | System starts up but no new orders, modifies, nor cancellations are accepted. Segment 2 will begin after system restart. | 4:05 p.m. - 4:30 p.m. CT on Monday |

**Table 3. Tuesday Half-Day Followed By Wednesday Holiday Example**

| Period | Description | Time |
|---|---|---|
| Tuesday Half-Day |  |  |
| System Start | System starts up but no new orders, modifies, nor cancellations are accepted. | 4:05 p.m. - 4:30 p.m. CT on Monday |
| Pre-Open and Regular Trading | New orders may be entered. Existing persisted orders may be modified or cancelled starting approximately 10 minutes before Pre-Open period begins for each product | Time varies by product |
| Product Close (PITCH status S) | Day orders are cancelled. | Time varies by product |
| Cancel-Only Period | GTC and GTD orders may be cancelled. Remaining GTC and GTD orders are persisted to the next trading date. | From product close to 12:20 p.m. CT on Tuesday |
| Wednesday Holiday |  |  |
| System Restart1 | System starts up but no new orders, modifies, nor cancellations are accepted. | 4:05 p.m. - 4:30 p.m. CT on Tuesday |
| Pre-Open and Regular Trading for Segment 1 | New orders may be entered. Existing persisted orders may be modified or cancelled starting approximately 10 minutes before Pre-Open period begins for each product. | Time varies by product |
| Product Close for Segment 1 (PITCH status S) | No new orders are accepted. | 10:30 a.m. CT on Wednesday |
| Cancel-Only Period | Orders and quotes may be cancelled. Live GTC and GTD orders are persisted to segment 2. Day Order persistence is dependent on port attribute2 | 10:30 a.m. - 10:35 a.m. CT on Wednesday |
| System Restart1 | System starts up but no new orders, modifies, nor cancellations are accepted. Segment 2 begins after system restart. | 4:05 p.m. - 4:30 p.m. CT on Wednesday |

1The disconnect/reconnect sequence of a system restart generally take less than ten minutes and could occur anytime between 4:05 p.m. and 4:30 p.m. CT.

2See the Multi-Segment Holiday Day Order Handling port attribute.

#### Post-Settlement Execution Restatements

`Order Execution` messages received at the time of the trade in Trade-At-Settlement (TAS) products (i.e. VXT, VXMT, etc.) should be considered initial notification of trade. In all of these products, information available only after the settlement time of the associated contract is required before the trade can be cleared. The following describes the post-settlement processing required for each applicable product:

TAS Execution prices of TAS trades represent an offset to the end-of-day settlement price of the associated futures contract. For example, a trade executed at 0.02 in a VXT contract is an agreement to buy and sell VX contracts of the same expiration at a price that is 2-cents above the end-of-day settlement price, which is available after 3:00 p.m. CT. When VX end-of-day settlements are available, TAS trades executed during the business date are resolved by updating the execution price and changing the symbol to the associated futures contract. TAS trades are cleared as regular futures contract (i.e. VX) trades.

Trades executed intraday are acknowledged back to participants using `Order Execution` messages. The `Order Execution` message received in these products is considered a Pending trade. As a convenience to customers, an optional value PendingStatus is provided on the Order Execution message. CFE follows up each initial (i.e., pending) TAS future execution with post-settlement `TAS Restatement`. The following summarizes the restatement details for each product:

TAS Trades in these symbols are restated with the same ExecId and ClOrdId as the original trade. The as-executed symbol, price and size are maintained in the Symbol, LastPx and LastShares fields of the `TAS Restatement` message, respectively. The symbol into which the TAS execution will clear (for example, the VX or VXM symbol with the same expiration as the as-executed VXT or VXMT symbol, respectively) is contained in the ClearingSymbol field. The price with which the TAS execution will clear (i.e., the execution price offset with the contract settlement price) is contained in the ClearingPrice field.

See TAS Restatement for details on the `TAS Restatement` messages used to restate TAS trades.

#### Spread Instruments and Signed Prices

All price fields in the CFE BOE protocol are signed values to accommodate spread instruments and TAS prices that can be negative (see Data Types for a description and an example of using the Binary Price type, which is little-endian byte order value, signed two's complement, eight bytes in size, with four implied decimal places). This section presents negative price scenarios introduced by Spread instruments.

Spreads instruments trade on CFE in a well-defined universe of two, three and four legged spreads with a restricted set of ratios and buy/sell conventions as shown in the table below. The notation S(1):B(1) means sell the first (earliest) expiration and buy the second (latest) expiration. The parenthesized numbers are the leg ratios. For S(1):B(1) the ratios of each leg are 1, which means one unit of the spread contract is equivalent to selling 1 unit of the first expiration and buying 1 unit of the second expiration.

| Legs | Spreads (B=Buy, S=Sell, ()=Ratio) |
|---|---|
| 2 | S(1):B(1), B(1):B(1), S(1):B(2), S(2):B(1) |
| 3 | B(1):B(1):B(1), B(1):S(2):B(1) |
| 4 | B(1):B(1):B(1):B(1), B(1):S(1):B(1):S(1), B(1):S(1):S(1):B(1) |

The bold 2-leg spread in the above table - S(1):B(1) - is a special spread that always exists in the CFE system. As new contracts are listed, the S(1):B(1) two leg spread instruments are automatically created between the new contract and all existing active contracts.

Spread instruments can result in executions where the buyer gets paid and the seller pays. This can be non-intuitive in all but the simplest spreads. Consider the two leg S(1):B(1) spread VX1:VX2 comprising selling 1 unit of the VX1 contract and buying 1 unit of the VX2 contract. To illustrate how buyers can get paid and sellers can pay, we examine spread pricing in Contango and Backwardation price environments.

Contango S(1):B(1) spread price example illustrates spread pricing in a Contango price environment in which the price of the early expiration contract is lower than the later expiration contract. In this example the Bid/Offer of the VX1 simple contract is 15.00 x 15.50 and the Bid/Offer for the VX2 contract is 16.50 x 16.75. The synthetic market for the VX1:VX2 spread (i.e., the Bid/Offer implied by the leg markets) is 1.00 x 1.75. The bid of 1.00 derives from the fact that the offer on the VX1 leg is 15.50 and the bid on the VX2 leg is 16.50 and the net of the two is 1.00 net debit (i.e., buyer pays). Figure 1 shows the implied spread market in italics. This is the normal intuitive situation where the spread buyer pays and seller gets paid.

_(Figure: Figure 1. Contango S(1):B(1) spread price example)_

Next, consider the same example in the context of a Backward, or Inverted, market in which the price of the early expiration is higher than the price of the later expiration. Backwardation (Inverted) S(1):B(1) spread price example below illustrates spread pricing in a Backward price environment. The Bid/Offer of the VX1 simple contract Is 16.50 x 17.00 and the Bid/Offer for the VX2 contract is 15.50 x 15.75. The synthetic market for the VX1:VX2 spread is -1.50 x -0.75. The bid of -1.50 derives from the fact that the offer on the VX1 leg is 17.00 and the bid on the VX2 leg is 15.50 and the net of the two is 1.50 net credit (i.e., buyer gets paid).

_(Figure: Figure 2. Backwardation (Inverted) S(1):B(1) spread price example)_

Spread pricing requires thinking of instrument prices on the entire real number line and not just positive numbers. In the example above the bid is less than the offer as its left of the offer on the real number line. One can buy at the offer (paying -0.75 = receiving 0.75) and subsequently sell back at the bid (receiving -1.50 = paying 1.50), giving up the bid/offer spread (0.75) in the process; the same as positive prices. This concept generalizes to two and three leg spreads and unequal ratios; prices can just as easily be negative as positive as a result of the pricing environment (i.e., shape of the price curve vs. expiration date) and the spread definition (which legs bought/sold and ratios).

For Options only, TPHs can create new options on futures complex instruments via the `New Complex Instrument` message. The complex instrument must contain a minimum of 2 and maximum of 16 legs.

#### OCC Clearing Reference

The following table can be used to assist firms in mapping values sent in BOE to their associated field names at the OCC. Note that ClearingAccount is not sent to the OCC.

| BOE Field Name | FIX Tag | OCC Mapping |
|---|---|---|
| ClearingFirm | 115 | Exec Broker |
| Account | 1 | The first ten characters will appear in the Account # field. The entire 16 character string will appear in the optional CM Data field. |
| ExecId | 17 | Trade Id |
| OrderId | 37 | Exchange Data |
| ClOrdId | 11 | Order Id |
| CMTANumber | 439 | CMTA CM# |
| ClearingAccount | 440 | Not sent to the OCC. |

#### Port Types

All BOE port types may be ordered through the Customer Web Portal using the Logical Port Request form tool. Changes to port attributes may be requested through the same tool by submitting a `Modify`request for one or more existing BOE ports.

##### BOE Unit Order Ports

BOE Unit Order Ports (also referred to as order unit match capacity allocations) support simple and complex/spread futures and options order entry as well as resetting TPH risk trips but do not support the usage of the following message types: `Quote Update, Purge Orders`. The attempted usage of any of these message types on standard BOE order ports will result in a rejection of the disallowed message type.

BOE Unit Order Ports are specific to a particular matching unit. Only messages having symbols mapped to the matching unit will be accepted.

BOE Unit Order Ports are limited to 3,000 inbound messages per second. Once the inbound limit is reached new orders are rejected, modifies are handled as cancels, and cancels are processed normally. BOE Unit Order Ports are limited to one inbound message per second on CFE Test Products.

`Mass Cancel Order` messages received on a BOE Unit Order Port will only cancel orders or quotes for symbols which are mapped to the matching unit associated with this port.

`Risk Reset` messages received on a BOE Unit Order Port will only reset risk for symbols which are mapped to the matching unit associated with this port.

##### BOE Unit Quoting Ports

BOE Unit Quoting Ports (also referred to as quoting unit match capacity allocations) are intended for use by firms quoting large numbers of simple futures or options contracts. BOE Unit Quoting Ports do not support the `Purge Orders` message type. This requires a separate BOE Unit Purge Port.

BOE Unit Quoting Ports are specific to a particular matching unit. Only messages having symbols mapped to the matching unit will be accepted.

Match Trade Prevention is only available if defaulted at the port level. For BOE Unit Quoting Ports, only Cancel Newest, Cancel Oldest, or Cancel Both are permitted. If a BOE Unit Quoting port is not configured with both a default MTP Modifier and Unique Id Level, Match Trade Prevention will be disabled.

| Message | Simple/Complex | Accepted over Unit Quoting Port? | Other Conditions |
|---|---|---|---|
| `Quote Update` | Simple | Yes |  |
| `Quote Update` | Complex | No |  |
| `New Order` | Simple/Complex | Yes | Must have a TimeInForce value of Day, GTD, GTC, IOC, or FOK. |
| `Purge Orders` | Simple/Complex | No |  |
| `Reset Risk` |  | Yes |  |

##### BOE Unit Purge Ports

BOE Unit Purge Ports support two message types: `Purge Orders` and `Risk Reset`. Members may use this port type to request a cancellation of groups of orders, including orders across multiple BOE/FIX Order or BOE Quoting ports.

BOE Unit Purge Ports are specific to a particular matching unit. Only messages having symbols mapped to the matching unit will be accepted. Only orders and quotes for symbols mapped to the matching unit may be purged.

#### CFE Unit/Product Distribution

The following table describes the CFE symbol distribution across units.

**Table 1. CFE Production/Certification Environment - Unit/Product Distribution**

| Symbol Range | Unit |
|---|---|
| UX, VX, VXT, VXM, VXMT | 1 |
| IBHY, IBIG, IBGO, IBYO, IEMD, MGTN, VA, XBTF | 2 |
| FBT, FET, PBT, PET | 3 |
| N/A | 4 |

Note - CFE reserves the right to add units and/or change symbol distribution with 48 hours of notice and no migration period. Notice will be given that the distribution will change on a certain date. Care should be taken to support mappings in these tables via software configuration.

#### Options Price Validations

Minimum Price Checks:

CFE will reject any complex/spread limit orders that would result in individual leg prints being priced below $0.01 if executed at that limit price in non-TAS products. For example, a complex instrument with a 1:1 ratio containing all buys must have a net limit price of at least $0.02.

CFE will also reject any limit orders where the limit price of the order is less than an exchange determined buffer value for calendar, vertical, diagonal, butterfly, and box spreads. The current default buffer value applied for all spread types and products is zero.

Maximum Price Checks:

CFE will reject any limit orders where the limit price of the order is greater than the intrinsic value of a call or put vertical, butterfly, or box spread plus an exchange determined buffer value. The current buffer applied for this check is 1% of intrinsic value with a minimum of $0.03 and maximum of $0.50.

## Session

### Message Headers

Each message has a twelve byte header. The two initial StartOfMessage bytes are present to aid in message reassembly for network capture purposes. The MatchingUnit field is only populated on sequenced, non-session level messages sent from CFE to the TPH. Messages from TPH to CFE and all session level messages must always set this value to 0.

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | Number of bytes for the message, including this field but not including the two bytes of the StartOfMessage field. |
| MessageType | 4 | 2 | Binary | Message type |
| MatchingUnit | 6 | 1 | Binary | Matching unit which created this message. Matching units in BOE correspond to matching units on Multicast PITCH. For session level traffic the unit is set to 0. For messages from TPH to CFE, the unit must be 0 or set to the correct unit. |
| Reserved | 7 | 1 | Binary | Must be zero from member. Value unspecified from CFE. |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message. Messages from CFE to TPH are sequenced distinctly per matching unit. Zero for session level traffic. |

#### Handling of Invalid Message Headers

If an invalid message header is encountered, the exchange will disconnect the port. A message header is considered invalid if any of:

- StartOfMessage is not `B0E3`.
- MessageLength is not appropriate for the given message type.
- MessageType is not a documented message type for CFE. Note that the types of application messages accepted may vary between CFE and other BOEv3 exchanges.

### Login, Replay, and Sequencing

Session level messages, both inbound (TPH to CFE) and outbound (CFE to TPH) are unsequenced.

Inbound (TPH to CFE) application messages are sequenced. Upon reconnection, CFE informs the TPH of the last processed sequence number; the TPH may choose to resend any messages with sequence numbers greater than this value. A gap forward in the TPH's incoming sequence number is permitted at any time and is ignored by CFE. Gaps backward in sequence number (including the same sequence number used twice) are never permitted and will always result in a `Logout Response` message being sent and the connection being dropped.

Most (but not all) outbound (CFE to TPH) application messages are monotonically sequenced per matching unit. Each message's documentation will indicate whether it is sequenced or unsequenced. While matching units on BOE correspond directly to matching units on Multicast PITCH, sequence numbers do not.

Upon reconnection, a TPH sends the last received sequence number per matching unit in a `Login Request` message. CFE will then respond with any missed messages.

The ReplayUnspecifiedUnit value can be used to control the replay behavior for unknown units. If the flag is set to F (Fail), CFE will send a `Login Response` and close the connection if there are any messages to replay from any unspecified unit. If the flag is set to S (Skip), CFE will exclude messages from unspecified matching units during replay. If the flag is set to R (Replay), CFE will send messages from unspecified units during replay. CFE will send a `Replay Complete` message when replay is finished. If there are no messages to replay, a `Replay Complete` message will be sent immediately after a `Login Response` message. CFE will reject all orders and all quote updates during replay.

When connecting to unit ports (Unit Order Ports, Unit Quoting Ports, or Unit Purge Ports), ReplayUnspecifiedUnits will be processed per the above description if the local unit number is not present in any instance of the UnitSequence field.

Assuming a TPH has requested replay messages using a properly formatted `Login Request` after a disconnect, any unacknowledged orders remaining with the TPH after the `Replay Complete` message is received should be assumed to be unknown to CFE.

Unsequenced messages will not be included during replay.

A session is identified by the SessionId and SessionSubId (both supplied by CFE). Only one concurrent connection per username and session sub-identifier is permitted per matching unit.

If a login is rejected, an appropriate `Login Response` message will be sent and the connection will be terminated.

### Sequence Reset

A reset sequence operation is not available for Binary Order Entry. However, a TPH can send a `Login Request` message with ReplayUnspecifiedUnit field set to S (Skip), and NumberOfUnits field set to zero. Then, upon receiving a `Login Response` message from CFE, the TPH can use the field ClientSequence as the sequence starting point for sending future messages.

### Heartbeats

`Client Heartbeat` messages are sent from TPH to CFE and `Server Heartbeat` messages are sent from CFE to TPH if no other data has been sent in that direction for one second. Like other session level messages, heartbeats from CFE to the TPH do not increment the sequence number. If CFE receives no inbound data or heartbeats for five seconds, a `Logout Response` message will be sent and the connection will be terminated. TPHs are encouraged to have a one second heartbeat interval and to perform similar connection staleness logic.

### Logging Out

To gracefully log out of a session, a `Logout Request` message should be sent by the TPH. CFE will finish sending any queued data for that port and will then respond with a `Logout Response` message and close the connection. After receipt of a `Logout Request` message, CFE will ignore all other inbound (TPH to CFE) messages except for `Client Heartbeat`.

## Session Messages

**Table 1. Session Message Types**

| Direction | Message Name | Type | Sequenced |
|---|---|---|---|
| TPH to CFE | Login Request | `01 00` (1) | No |
| TPH to CFE | Logout Request | `02 00` (2) | No |
| TPH to CFE | Client Heartbeat | `03 00` (3) | No |
| CFE to TPH | Login Response | `F5 01` (501) | No |
| CFE to TPH | Replay Complete | `F6 01` (502) | No |
| CFE to TPH | Logout Response | `F7 01` (503) | No |
| CFE to TPH | Server Heartbeat | `F8 01` (504) | No |

### TPH to CFE

#### Login Request

A `Login Request` message must be sent as the first message upon connection.

The message includes a repeating group starting with field UnitNumber which repeats NumberOfUnits times. This can be used to specify the last consumed sequence numbers per matching unit received by the TPH. CFE uses these sequence numbers to determine what outbound (CFE to TPH) traffic, if any, was missed by the TPH. If NumberOfUnits is 0, it is assumed the TPH has not received any messages (e.g., start of day).

The TPH does not need to include a sequence number for a unit if they never received messages from it. If the TPH wishes to send a value for the unit anyway, 0 is the only allowed value.

If the TPH is sending a `Login Request` to a Unit Order Port, Unit Quoting Port, or Unit Purge Port, the only UnitNumber accepted is the number of the port's unit.

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | (30 + 5*NumberOfUnits) |
| MessageType | 4 | 2 | Binary | `01 00` (1) |
| MatchingUnit | 6 | 1 | Binary | Must be zero |
| Reserved | 7 | 1 | Binary | Must be zero |
| SequenceNumber | 8 | 4 | Binary | Must be zero |
| SessionId | 12 | 4 | AlphaNumeric | Session Id as supplied by CFE |
| SessionSubId | 16 | 4 | AlphaNumeric | Session Sub Id as supplied by CFE |
| Password | 20 | 10 | AlphaNumeric | The password associated with the SessionId and SessionSubId. |
| ReplayUnspecifiedUnit | 30 | 1 | Text | Controls replay behavior for unknown units. Must be one of: `F` = fail if unit not specified `R` = replay any unspecified unit from zero `S` = skip replay of unspecified units |
| NumberOfUnits | 31 | 1 | Binary | The number (possibly 0) of unit/sequence pairs to follow, one per unit from which the TPH has received messages over this port. The value must be 0 or 1 since all BOEv3 ports are associated to a single unit. |
| →UnitNumber | 32 | 1 | Binary | A unit number. This must be the unit number of the port. |
| →UnitSequence | 33 | 4 | Binary | Last received sequence number for the unit. |

##### Example Login Request Message

| Field Name | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `B0 E3` | Start of message bytes |
| MessageLength | `23 00` | 35 bytes |
| MessageType | `01 00` | `Login Request` |
| MatchingUnit | `00` | Must be zero |
| Reserved | `00` | Must be zero |
| SequenceNumber | `00 00 00 00` | Must be zero |
| SessionId | `54 45 53 54` | " `TEST`" |
| SessionSubId | `30 30 30 31` | " `0001`" |
| Password | `54 45 53 54 49 4E 47 00 00 00` | " `TESTING`" |
| ReplayUnspecifiedUnit | `46` | " `F`" (Fail) |
| NumberOfUnits | `01` | 1 unit |
| →UnitNumber | `02` | Unit 2 |
| →UnitSequence | `3F 15 00 00` | 5,439 |

#### Logout Request

To end the session, the TPH should send a `Logout Request` message. CFE will finish sending any queued data and finally respond with a `Logout Response` message and close the connection.

A TPH may simply close the connection without logging out, but may lose any queued messages by doing so.

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `0A 00` (10) |
| MessageType | 4 | 2 | Binary | `02 00` (2) |
| MatchingUnit | 6 | 1 | Binary | Must be zero |
| Reserved | 7 | 1 | Binary | Must be zero |
| SequenceNumber | 8 | 4 | Binary | Must be zero |

##### Example Logout Request Message

| Field Name | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `B0 E3` | Start of message bytes |
| MessageLength | `0A 00` | 10 bytes |
| MessageType | `02 00` | `Logout Request` |
| MatchingUnit | `00` | Must be zero |
| Reserved | `00` | Must be zero |
| SequenceNumber | `00 00 00 00` | Must be zero |

#### Client Heartbeat

See Heartbeats for more information about heartbeat and the session level protocol.

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `0A 00` (10) |
| MessageType | 4 | 2 | Binary | `03 00` (3) |
| MatchingUnit | 6 | 1 | Binary | Must be zero |
| Reserved | 7 | 1 | Binary | Must be zero |
| SequenceNumber | 8 | 4 | Binary | Must be zero |

##### Example Client Heartbeat Message

| Field Name | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `B0 E3` | Start of message bytes |
| MessageLength | `0A 00` | 10 bytes |
| MessageType | `03 00` | `Client Heartbeat` |
| MatchingUnit | `00` | Must be zero |
| Reserved | `00` | Must be zero |
| SequenceNumber | `00 00 00 00` | Must be zero |

### CFE to TPH

#### Login Response

`A Login Response` message is sent in response to a `Login Request` message. On a successful login, the LoginResponseStatus will be set to `A`. On a failed login, LoginResponseStatus will be set to a value other than `A`, and LoginResponseText will be set to an appropriate failure description.

Note that the repeating group starting with field UnitNumber provides the highest available CFE to TPH sequence number for the specified unit. Only the unit of the port will populate this group (i.e. NumberOfUnits will be 1).

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | (76 + NumberOfUnits*5) |
| MessageType | 4 | 2 | Binary | `F5 01` (501) |
| MatchingUnit | 6 | 1 | Binary | Will be zero |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | Will be zero |
| LoginResponseStatus | 12 | 1 | Text | Accepted, or the reason for the rejection. `A` = Accepted `B` = Session In Use `D` = Disabled `I` = Invalid Unit `M` = Invalid Message `N` = Not Authorized `Q` = Sequence Ahead `S` = Invalid Session |
| LoginResponseText | 13 | 60 | Text | Human-readable text with additional information about the reason for rejection. ASCII NUL (0x00) filled on the right, if necessary. |
| ClientSequence | 73 | 4 | Binary | Last inbound (TPH to CFE) message sequence number processed by CFE on this port. |
| NumberOfUnits | 77 | 1 | Binary | A number, n, of unit/sequence pairs to follow, one per unit. A pair for every unit will be sent, even if no messages have been sent to this port today. For unsuccessful logins, this will be 0. This value will be 1 since all BOEv3 ports are associated with a single unit. |
| →UnitNumber | 78 | 1 | Binary | A unit number |
| →UnitSequence | 79 | 4 | Binary | Highest available CFE to TPH sequence number for the unit. |

##### Example Login Response Message

| Field Name | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `B0 E3` | Start of message bytes |
| MessageLength | `51 00` | 81 bytes |
| MessageType | `F5 01` | `Login Response` |
| MatchingUnit | `00` | Always zero |
| Reserved | `00` |  |
| SequenceNumber | `00 00 00 00` | Always zero |
| LoginResponseStatus | `41` | " `A`" (Accepted) |
| LoginResponseText | `54 45 53 54 49 4E 47 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` | " `TESTING`" |
| ClientSequence | `01 00 00 00` | 1 |
| NumberOfUnits | `01` | 1 unit |
| →UnitNumber | `02` | Unit 2 |
| →UnitSequence | `3F 15 00 00` | 5,439 |

#### Replay Complete

See Login, Replay, and Sequencing for more information about heartbeats and the session level protocol.

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `0A` (10) |
| MessageType | 4 | 2 | Binary | `F6 01` (502) |
| MatchingUnit | 6 | 1 | Binary | Will be zero |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | Will be zero |

##### Example Replay Complete Message

| Field Name | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `B0 E3` | Start of message bytes |
| MessageLength | `0A 00` | 10 bytes |
| MessageType | `F6 01` | `Replay Complete` |
| MatchingUnit | `00` | Always zero |
| Reserved | `00` |  |
| SequenceNumber | `00 00 00 00` | Always zero |

#### Logout Response

A `Logout Reponse` is usually sent in response to a `Logout Request`. Any queued data is transmitted, a `Logout Reponse` is sent, and CFE will close the connection. However, a `Logout Reponse` may also be sent if the TPH violates the protocol specification (e.g., by moving backwards in sequence number).

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `47 00` (71 ) |
| MessageType | 4 | 2 | Binary | `F7 01` (503) |
| MatchingUnit | 6 | 1 | Binary | Will be zero |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | Will be zero |
| LogoutReason | 12 | 1 | Text | Reason for the logout. `U` = User Requested `A` = Administrative `!` = Protocol Violation |
| LogoutReasonText | 13 | 60 | Text | Human-readable text with additional information about the reason for logout. |

##### Example Logout Response Message

| Field Name | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `B0 E3` | Start of message bytes |
| MessageLength | `47 00` | 71 bytes |
| MessageType | `F7 01` | `Logout Response` |
| MatchingUnit | `00` | Always zero |
| Reserved | `00` |  |
| SequenceNumber | `00 00 00 00` | Always zero |
| LogoutReason | `55` | " `U`" (User Requested) |
| LogoutReasonText | `54 45 53 54 49 4E 47 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` | " `TESTING`" |

#### Server Heartbeat

See Heartbeats for more information about heartbeats and the session level protocol.

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `0A` (10) |
| MessageType | 4 | 2 | Binary | `F8 01` (504) |
| MatchingUnit | 6 | 1 | Binary | Will be zero |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | Will be zero |

##### Example Server Heartbeat Message

| Field Name | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `B0 E3` | Start of message bytes |
| MessageLength | `0A 00` | 10 bytes |
| MessageType | `F8 01` | `Server Heartbeat` |
| MatchingUnit | `00` | Always zero |
| Reserved | `00` |  |
| SequenceNumber | `00 00 00 00` | Always zero |

## Application Messages

Note that if CFE receives a message type not listed in this specification, the connection will be closed. See Handling of Invalid Message Headers for details.

**Table 1. Application Message Types**

| Direction | Message Name | Version | Type | Sequenced |
|---|---|---|---|---|
| TPH to CFE | NewOrderUSFuturesV2 | `V2` | `F0 03` (1008) | Yes |
| TPH to CFE | NewOrderOptionUSFuturesV1 | `V1` | `F1 03` (1009) | Yes |
| TPH to CFE | ModifyOrderUSFuturesV1 | `V1` | `EA 03` (1002) | Yes |
| TPH to CFE | CancelOrderUSFuturesV1 | `V1` | `EB 03` (1003) | Yes |
| TPH to CFE | MassCancelOrderUSFuturesV1 | `V1` | `EC 03` (1004) | Yes |
| TPH to CFE | PurgeOrdersUSFuturesV1 | `V1` | `ED 03` (1005) | Yes |
| TPH to CFE | QuoteUpdateUSFuturesV1 | `V1` | `EE 03` (1006) | Yes |
| TPH to CFE | QuoteUpdateOptionUSFuturesV1 | `V1` | `F2 03` (1010) | Yes |
| TPH to CFE | ResetRiskUSFuturesV1 | `V1` | `EF 03` (1007) | Yes |
| TPH to CFE | NewComplexInstrumentOptionUSFuturesV1 | `V1` | `F3 03` (1011) | Yes |
| CFE to TPH | OrderAcknowledgementUSFuturesV1 | `V1` | `DD 05` (1501) | Yes |
| CFE to TPH | OrderAcknowledgementOptionUSFuturesV1 | `V1` | `F3 05` (1523) | Yes |
| CFE to TPH | OrderRejectedUSFuturesV1 | `V1` | `DE 05` (1502) | No |
| CFE to TPH | OrderModifiedUSFuturesV1 | `V1` | `DF 05` (1503) | Yes |
| CFE to TPH | ModifyRejectedUSFuturesV1 | `V1` | `E0 05` (1504) | No |
| CFE to TPH | OrderExecutionUSFuturesV1 | `V1` | `E1 05` (1505) | Yes |
| CFE to TPH | OrderExecutionOptionUSFuturesV1 | `V1` | `F4 05` (1524) | Yes |
| CFE to TPH | OrderCancelledUSFuturesV1 | `V1` | `E2 05` (1506) | Yes |
| CFE to TPH | CancelRejectedUSFuturesV1 | `V1` | `E3 05` (1507) | No |
| CFE to TPH | MassCancelAcknowledgementUSFuturesV1 | `V1` | `E4 05` (1508) | No |
| CFE to TPH | MassCancelRejectedUSFuturesV1 | `V1` | `E5 05` (1509) | No |
| CFE to TPH | PurgeAcknowledgementUSFuturesV1 | `V1` | `E6 05` (1510) | No |
| CFE to TPH | PurgeRejectedUSFuturesV1 | `V1` | `E7 05` (1511) | No |
| CFE to TPH | TradeCancelCorrectUSFuturesV1 | `V1` | `E8 05` (1512) | Yes |
| CFE to TPH | TradeCancelCorrectOptionUSFuturesV1 | `V1` | `F5 05` (1525) | Yes |
| CFE to TPH | TASRestatementUSFuturesV1 | `V1` | `E9 05` (1513) | Yes |
| CFE to TPH | QuoteUpdateAcknowledgementUSFuturesV1 | `V1` | `EB 05` (1515) | No |
| CFE to TPH | QuoteUpdateRejectedUSFuturesV1 | `V1` | `EC 05` (1516) | No |
| CFE to TPH | QuoteRestatedUSFuturesV1 | `V1` | `ED 05` (1517) | Yes |
| CFE to TPH | QuoteExecutionUSFuturesV1 | `V1` | `EE 05` (1518) | Yes |
| CFE to TPH | QuoteCancelledUSFuturesV1 | `V1` | `EF 05` (1519) | No |
| CFE to TPH | TASQuoteRestatementUSFuturesV1 | `V1` | `F0 05` (1520) | Yes |
| CFE to TPH | ResetRiskAcknowledgementUSFuturesV1 | `V1` | `F2 05` (1522) | No |
| CFE to TPH | New Complex Instrument Accepted (Options Only) | `V1` | `F6 05` (1526) | Yes |
| CFE to TPH | New Complex Instrument Rejected (Options Only) | `V1` | `F7 05` (1527) | No |

### TPH to CFE

#### New Order

`New Order` messages sent from TPH to CFE.

##### NewOrderUSFuturesV2

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `8D 00` (141) |
| MessageType | 4 | 2 | Binary | `F0 03` (1008) |
| MatchingUnit | 6 | 1 | Binary | Must be zero or correct unit |
| Reserved | 7 | 1 | Binary | Must be zero |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message |
| ClOrdId | 12 | 20 | Text | Unique Id chosen by the client. Characters in the ASCII range 33-126 are allowed, except for comma, semicolon, and pipe . If the ClOrdId matches a live order, the order will be rejected as duplicate. A leading tilde (~) cannot be sent on any ClOrdId and will result in a reject. These are reserved for internal use by CFE and could be received as a result of a CFE-generated ClordId . Sent to the OCC in the OrderId field. Note: CFE only enforces uniqueness of ClOrdId values among currently live orders, which includes long-lived GTC and GTD orders. However, using unique ClOrdId values is strongly recommend. |
| Side | 32 | 1 | Text | `1` = Buy `2` = Sell |
| OrderQty | 33 | 4 | Binary | Order quantity. System limit is 999,999 contracts. |
| ClearingFirm | 37 | 4 | Alpha | EFID that will clear the trade. Port attribute value of 'Default EFID' is used if not provided. Sent to OCC in Exec Broker field. |
| ClearingAccount | 41 | 4 | Text | Supplemental identifier. Recorded and made available in execution reports. Available via Drop feeds. This field can be blank or populated with an optional four character string, except for comma, semicolon, and pipe . This field is not sent to the OCC. |
| Price | 45 | 8 | BinaryPrice | Limit price. Four implied decimal places. Required for limit orders ( OrdType = 2). If specified on market order ( OrdType = 1), the order will be rejected. Orders will be rejected if Price does not fall on the applicable minimum trading increment. For all contracts other than Trade at Settlement contracts, simple orders will be rejected if Price is less than or equal to zero, or greater than or equal to 100,000. For Trade at Settlement (TAS) contracts, simple orders will be rejected if Price is outside the price limits presented in the contract specification. Spread orders will be rejected if Price is outside the price limits implied by the spread instrument definition and constituent instrument min and max prices. |
| OrdType | 53 | 1 | Text | `1` = Market `2` = Limit (default) `4` = Stop Limit (Futures only) Market implies TimeInForce of IOC (3). Stop Limit orders must have a TimeInForce of DAY (0), GTC (1), or GTD (6). |
| TimeInForce | 54 | 1 | Text | `0` = Day (Expires at the end of the business day). `1` = GTC (Good ‘till Cancel. Order remains until cancelled or contract expires). `3` = IOC (Portion not filled immediately is cancelled. Market orders are implicitly IOC). `4` = FOK (An IOC where the entire size must be filled, else the order will be cancelled back). `6` = GTD (Good ‘till Date-Time Expires at the date-time specified in the ExpireTime field). |
| MinQty | 55 | 4 | Binary | Minimum fill quantity for IOC orders. Ignored for other Simple instrument orders. Not supported for Spread instruments. Spread instrument orders with specified MinQty will be rejected. |
| Symbol | 59 | 8 | Alphanumeric | Simple Instruments can be specified by providing the mapped symbol format in the Symbol field or by providing the product name (e.g., "VX") in the Symbol field and maturity date in the MaturityDate field. Responses to the TPH will contain the instrument specification in the manner that was provided on the associated new order specification (e.g., either Symbol Id or Product and MaturityDate). The Symbol field for Spread instrument related messages will always contain mapped symbol Id as product and maturity date does not completely specify the Spread instrument. |
| Capacity | 67 | 1 | Text | `C` = Customer `F` = Firm The Capacity refers to the OCC account type. A value of "C" denotes an account that clears in the Customer range at OCC. A value of "F" denotes an account that clears in the Clearing Firm range at OCC. |
| Account | 68 | 16 | Text | Unique account identifier associated with an order. This field will be reflected back on execution reports associated with this order. The first 10 characters are sent to the OCC in the Account # field. The entire 16 character string will appear in the optional CM Data field. Valid characters include ASCII 32-126. |
| PreventMatch | 84 | 3 | Text | Three characters: 1 st character - MTP Modifier: `N` = Cancel Newest `O` = Cancel Oldest `B` = Cancel Both 2 nd character - Unique Id Level: `F` = Prevent Match at Firm(TPH) Level `M` = Prevent Match at EFID Level `N` = None (do not prevent match at any level) 3 rd character - Trading Group Id (optional): TPH specified alphanumeric value 0-9, A-Z, or a-z. The unique Id level (character 2) of both orders must match to prevent a trade. If specified on both orders, Trading Group Id (character 3) must match to prevent a trade. Note that in the event of a Spread order match with a Simple order, the Spread order will always be cancelled irrespective of the 1 st character value. On New Orders, an empty PreventMatch string (NUL filled) results in default Port Attribute settings applied. |
| ExpireTime | 87 | 8 | DateTime | Required for TimeInForce = 6 orders, specifies the date-time (in UTC) that the order expires. |
| MaturityDate | 95 | 4 | Date | When specifying the Symbol for a `New Order` message the user can specify the mapped symbol identifier in the Symbol field. Alternatively, the product class (e.g., "VX", "VXT", etc.) can be supplied for the Symbol field and the MaturityDate field is used to specify the expiration date of the symbol within the specified product class. If a value is provided for MaturityDate , the Symbol field must correspond to a valid product or the order will be rejected with reason code C (Unknown Product Name). If an invalid MaturityDate is provided, the order will be rejected with reason code B (Unknown Maturity Date). |
| OpenClose | 99 | 1 | Text | Indicates status of client position in a trade resulting from the order. `O` = Open `C` = Close `N` = None NUL (0x00) = None |
| CMTANumber | 100 | 4 | Binary | CMTA Number of the firm that will clear the trade. Must be specified for CMTA orders and left unspecified for non-CMTA orders. Sent to the OCC in the CMTA CM# field. |
| StopPx | 104 | 8 | BinaryPrice | Stop price. Required if OrdType = 4 (Stop Limit). Stop Limit orders will only be triggered off Last Sale Eligible trades. |
| CustomGroupId | 112 | 2 | Binary | Used to group orders for use in mass cancels where multiple orders can be cancelled by specifying a list of CustomGroupIds. A zero value is treated as "no CustomGroupIds". |
| CtiCode | 114 | 1 | Text | Valid values: 1, 2, 3, 4 `1` = CTI 1: Transactions initiated and executed by an individual TPH for the TPH’s own account, for an account the TPH controls, or for the account in which the TPH has an ownership or financial interest. `2` = CTI 2: Transactions executed for the proprietary account of a clearing TPH or non-clearing TPH. `3` = CTI 3: Transactions where an individual TPH or authorized trader executes for the personal account of another individual TPH, for an account the other individual TPH controls or for an account in which the other individual TPH has an ownership or financial interest. `4` = CTI 4: Any transaction not meeting the definition of CTI 1, 2 or 3. (These should be non-TPH customer transactions). |
| ManualOrderIndicator | 115 | 1 | Text | `Y` = Manual order entry `N` = Automated order entry |
| OEOID | 116 | 18 | Text | Identifies the Order Entry Operator responsible for this message. Min length 3, max length 18. Values in ASCII range 33-126 except comma, semicolon, and pipe are permissible. |
| FrequentTraderId | 134 | 6 | Alphanumeric | Supplemental customer identifier used for billing related programs. |
| CustOrderHandlingInst | 140 | 1 | Text | Execution source code provided during order entry to describe broker service. A default value can be set using the ‘Default Customer Order Handling Instruction’ port attribute. `W` = Desk (high touch) `Y` = Electronic `C` = Vendor-provided platform, billed by Executing Broker `G` = Sponsored Access via Exchange API or FIX, provided by executing broker `H` = Premium algorithmic trading provider, billed by executing broker `D` = Other, including other-provided screen NUL (0x00) = Apply port default (initially 'Y') |
| CountryCode | 141 | 2 | Text | Identifies the country code of the person or system submitting the order using the ISO 3166 two-character code (must be entered using uppercase letters only). An order with a country code for a comprehensively sanctioned country will be rejected. |

##### NewOrderOptionUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | (142 + LegCnt) |
| MessageType | 4 | 2 | Binary | `F1 03` (1009) |
| MatchingUnit | 6 | 1 | Binary | Must be zero or correct unit |
| Reserved | 7 | 1 | Binary | Must be zero |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message |
| ClOrdId | 12 | 20 | Text | Unique Id chosen by the client. Characters in the ASCII range 33-126 are allowed, except for comma, semicolon, and pipe . If the ClOrdId matches a live order, the order will be rejected as duplicate. A leading tilde (~) cannot be sent on any ClOrdId and will result in a reject. These are reserved for internal use by CFE and could be received as a result of a CFE-generated ClordId . Sent to the OCC in the OrderId field. Note: CFE only enforces uniqueness of ClOrdId values among currently live orders, which includes long-lived GTC and GTD orders. However, using unique ClOrdId values is strongly recommend. |
| Side | 32 | 1 | Text | `1` = Buy `2` = Sell |
| OrderQty | 33 | 4 | Binary | Order quantity. System limit is 999,999 contracts. |
| ClearingFirm | 37 | 4 | Alpha | EFID that will clear the trade. Port attribute value of 'Default EFID' is used if not provided. Sent to OCC in Exec Broker field. |
| ClearingAccount | 41 | 4 | Alpha | Supplemental identifier. Recorded and made available in execution reports. Available via Drop feeds. This field can be blank or populated with an optional four character string, except for comma, semicolon, and pipe . This field is not sent to the OCC. |
| Price | 45 | 8 | BinaryPrice | Limit price. Four implied decimal places. Required for limit orders ( OrdType = 2). If specified on market order ( OrdType = 1), the order will be rejected. Orders will be rejected if Price does not fall on the applicable minimum trading increment. For all contracts other than Trade at Settlement contracts, simple orders will be rejected if Price is less than or equal to zero, or greater than or equal to 100,000. For Trade at Settlement (TAS) contracts, simple orders will be rejected if Price is outside the price limits presented in the contract specification. Spread orders will be rejected if Price is outside the price limits implied by the spread instrument definition and constituent instrument min and max prices.. |
| OrdType | 53 | 1 | Text | `1` = Market `2` = Limit (default) `4` = Stop Limit (Futures only) Market implies TimeInForce of IOC (3). Stop Limit orders must have a TimeInForce of DAY (0), GTC (1), or GTD (6). |
| TimeInForce | 54 | 1 | Text | `0` = Day (Expires at the end of the business day). `1` = GTC (Good 'till Cancel. Order remains until cancelled or contract expires). `3` = IOC (Portion not filled immediately is cancelled. Market orders are implicitly IOC). `4` = FOK (An IOC where the entire size must be filled, else the order will be cancelled back). `6` = GTD (Good 'till Date-Time Expires at the date-time specified in the ExpireTime field). |
| Symbol | 55 | 8 | Alphanumeric | Simple Instruments can be specified by providing the mapped symbol format in the Symbol field or the Options on Futures identifier name (e.g. "UX1A/K4 C2000") in the SecurityDesc field. If SecurityDesc is provided this field should be blank. Responses to the TPH will contain both the Symbol and SecurityDesc fields populated for simple instruments. The Symbol field for Spread instrument related messages will always contain mapped symbol Id. |
| SecurityDesc | 63 | 16 | Text | Simple Instruments can be specified by providing the mapped symbol format in the Symbol field or the Options on Futures identifier name (e.g. "UX1A/K4 C2000") in the SecurityDesc field. If Symbol is provided this field should be blank. Responses to the TPH will contain both the Symbol and SecurityDesc fields populated for simple instruments. The Symbol field for Spread instrument related messages will always contain mapped symbol Id, and this field should be blank. |
| Capacity | 79 | 1 | Text | `C` = Customer `F` = Firm The Capacity refers to the OCC account type. A value of "C" denotes an account that clears in the Customer range at OCC. A value of "F" denotes an account that clears in the Clearing Firm range at OCC. |
| Account | 80 | 16 | Text | Unique account identifier associated with an order. This field will be reflected back on execution reports associated with this order. The first 10 characters are sent to the OCC in the Account # field. The entire 16 character string will appear in the optional CM Data field. Valid characters include ASCII 32-126. |
| PreventMatch | 96 | 3 | Text | Three characters: 1st character - MTP Modifier: `N` = Cancel Newest `O` = Cancel Oldest `B` = Cancel Both 2nd character - Unique Id Level: `F` = Prevent Match at Firm (TPH) Level `M` = Prevent Match at EFID Level `N` = None (do not prevent match at any level) 3rd character - Trading Group Id (optional): TPH specified alphanumeric value 0-9, A-Z, or a-z. The unique Id level (character 2) of both orders must match to prevent a trade. If specified on both orders, Trading Group Id (character 3) must match to prevent a trade. Note that in the event of a Spread order match with a Simple order, the Spread order will always be cancelled irrespective of the 1st character value. On New Orders, an empty PreventMatch string (NUL filled) results in default Port Attribute settings applied. |
| ExpireTime | 99 | 8 | DateTime | Required for TimeInForce = 6 orders, specifies the date-time (in UTC) that the order expires. |
| OpenClose | 107 | 1 | Text | Indicates status of client position in a trade resulting from the order. `O` = Open `C` = Close `N` = None NUL (0x00) = None |
| CMTANumber | 108 | 4 | Binary | CMTA Number of the firm that will clear the trade. Must be specified for CMTA orders and left unspecified for non-CMTA orders. Sent to the OCC in the CMTA CM# field. |
| CustomGroupId | 112 | 2 | Binary | Used to group orders for use in mass cancels where multiple orders can be cancelled by specifying a list of CustomGroupIds. A zero value is treated as "no CustomGroupIds". |
| CtiCode | 114 | 1 | Text | Valid values: 1, 2, 3, 4 `1` = CTI 1: Transactions initiated and executed by an individual TPH for the TPH’s own account, for an account the TPH controls, or for the account in which the TPH has an ownership or financial interest. `2` = CTI 2: Transactions executed for the proprietary account of a clearing TPH or non-clearing TPH. `3` = CTI 3: Transactions where an individual TPH or authorized trader executes for the personal account of another individual TPH, for an account the other individual TPH controls or for an account in which the other individual TPH has an ownership or financial interest. `4` = CTI 4: Any transaction not meeting the definition of CTI 1, 2 or 3. (These should be non-TPH customer transactions). |
| ManualOrderIndicator | 115 | 1 | Text | `Y` = Manual order entry `N` = Automated order entry |
| OEOID | 116 | 18 | Text | Identifies the Order Entry Operator responsible for this message. Min length 3, max length 18. Values in ASCII range 33-126 except comma, semicolon, and pipe are permissible. |
| FrequentTraderId | 134 | 6 | Alphanumeric | Supplemental customer identifier used for billing related programs. |
| CustOrderHandlingInst | 140 | 1 | Text | Execution source code provided during order entry to describe broker service. A default value can be set using the 'Default Customer Order Handling Instruction' port attribute. `W` = Desk (high touch) `Y` = Electronic `C` = Vendor-provided platform, billed by Executing Broker `G` = Sponsored Access via Exchange API or FIX, provided by executing broker `H` = Premium algorithmic trading provider, billed by executing broker `D` = Other, including other-provided screen NUL (0x00) = Apply port default (initially 'Y') |
| CountryCode | 141 | 2 | Alphanumeric | Identifies the country code of the person or system submitting the order using the ISO 3166 two-character code (must be entered using uppercase letters only). An order with a country code for a comprehensively sanctioned country will be rejected. |
| LegCnt | 143 | 1 | Binary | For complex orders, the number of legs of the complex instrument |
| → LegPositionEffect | 144 | 1 | Text | Indicates status of client position in the option for this leg. `O` = Open `C` = Close `N` = None |

#### Modify Order

Request to modify an order. The order attributes which may be adjusted are Price, OrderQty, OrdType, StopPx, ManualOrderIndicator, CustOrderHandlingInst, and OEOID. Modifies will result in a loss of time priority unless (1) they have no change in Price and also reduce OrderQty or (2) they change the StopPx for a stop order that has not been elected. OrdType may be adjusted from Limit to Market.

Time priority is maintained on a replace/modify order in the following cases:

- A decrease in OrderQty with no other changes
- A decrease in OrderQty, a change to the OEOID and/or the ManualOrderIndicator, and no other changes
- A decrease in OrderQty and/or a change to the StopPx on an unelected stop order with no other changes
- A decrease in the OrderQty and/or a change to the StopPx on an unelected stop order, a change to the OEOID and/or the ManualOrderIndicator, and no other changes.

Changes in OrderQty result in an adjustment of the current order's OrderQty. The new OrderQty does not directly replace the current order's LeavesQty. Rather, a delta is computed from the current OrderQty and the replacement OrderQty. This delta is then applied to the current LeavesQty. If the resulting LeavesQty is less than or equal to zero, the order is cancelled. This results in safer behavior when the modification request overlaps partial fills for the current order, leaving the TPH in total control of the share exposure of the order.

A `Modify Order` may be issued before the acknowledgement for the previous `New Order` or `Modify Order` message is received. The OrigClOrdId on the overlapping modify should reference the ClOrdId of the last message that was sent and not the last acknowledged message. `Modify Order` requests that merely reduce OrderQty may be overlapped and the existing ClOrdId may be reused. This is the only case where reuse of the ClOrdId is allowed.

A maximum of 1,679,615 `Modify Order` requests may be made to a single order each trading day. Once the 1,679,615th modification is made, then the next user-generated message on the order should be a `Cancel Order` request.

The `Modify Order` message can be used to modify either futures or options orders.

##### ModifyOrderUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` |
| MessageLength | 2 | 2 | Binary | `66 00` (102) |
| MessageType | 4 | 2 | Binary | `EA 03` (1002) |
| MatchingUnit | 6 | 1 | Binary | Must be zero or correct unit |
| Reserved | 7 | 1 | Binary | Must be zero |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message |
| ClOrdId | 12 | 20 | Text | Unique Id chosen by the client. Characters in the ASCII range 33-126 are allowed, except for comma, semicolon, and pipe . If the ClOrdId matches a live order, the order will be rejected as duplicate. A leading tilde (~) cannot be sent on any ClOrdId and will result in a reject. These are reserved for internal use by CFE and could be received as a result of a CFE-generated ClordId . Sent to the OCC in the OrderId field. Note: CFE only enforces uniqueness of ClOrdId values among currently live orders, which includes long-lived GTC and GTD orders. However, using unique ClOrdId values is strongly recommend. |
| OrigClOrdId | 32 | 20 | Text | The ClOrdId of the original order. |
| ClearingFirm | 52 | 4 | Alpha | EFID that will clear the trade. Port attribute value of ‘Default EFID’ is used if not provided. Sent to OCC in Exec Broker field. |
| OrderQty | 56 | 4 | Binary | Order quantity. System limit is 999,999 contracts. |
| Price | 60 | 8 | BinaryPrice | Limit price. Four implied decimal places. Required for limit orders ( OrdType = 2). If specified on market order ( OrdType = 1), the order will be rejected. Orders will be rejected if Price does not fall on the applicable minimum trading increment. For all contracts other than Trade at Settlement contracts, simple orders will be rejected if Price is less than or equal to zero, or greater than or equal to 100,000. For Trade at Settlement (TAS) contracts, simple orders will be rejected if Price is outside the price limits presented in the contract specification. Spread orders will be rejected if Price is outside the price limits implied by the spread instrument definition and constituent instrument min and max prices. |
| OrdType | 68 | 1 | Text | `1` = Market `2` = Limit (default) `4` = Stop Limit (Futures only) Market implies TimeInForce of IOC (3). Stop Limit orders must have a TimeInForce of DAY (0), GTC (1), or GTD (6). |
| CancelOrigOnReject | 69 | 1 | Text | `N` = Leave original order alone. `Y` = Cancel original order if modification fails. |
| StopPx | 70 | 8 | BinaryPrice | Stop price. Required if OrdType = 4 (Stop Limit). Stop Limit orders will only be triggered off Last Sale Eligible trades. |
| ManualOrderIndicator | 78 | 1 | Text | `Y` = Manual order entry `N` = Automated order entry |
| OEOID | 79 | 18 | Text | Identifies the Order Entry Operator responsible for this message. Min length 3, max length 18. Values in ASCII range 33-126 except comma, semicolon, and pipe are permissible. |
| FrequentTraderId | 97 | 6 | Alphanumeric | Supplemental customer identifier used for billing related programs. |
| CustOrderHandlingInst | 103 | 1 | Text | Execution source code provided during order entry to describe broker service. A default value can be set using the 'Default Customer Order Handling Instruction' port attribute. `W` = Desk (high touch) `Y` = Electronic `C` = Vendor-provided platform, billed by Executing Broker `G` = Sponsored Access via Exchange API or FIX, provided by executing broker `H` = Premium algorithmic trading provider, billed by executing broker `D` = Other, including other-provided screen NUL (0x00) = Apply port default (initially 'Y') |

#### Cancel Order

Request to cancel a single order or quote (see Mass Cancel Order for the cancellation of multiple orders and/or quotes).

- Time priority is maintained on a cancel order in the following cases:
  - A decrease in OrderQty with no other changes
  - A decrease in OrderQty, a change to the OEOID and/or the ManualOrderIndicator, and no other changes
  - A decrease in OrderQty and/or a change to the StopPx on an unelected stop order with no other changes
  - A decrease in the OrderQty and/or a change to the StopPx on an unelected stop order, a change to the OEOID and/or the ManualOrderIndicator, and no other changes.

The `Cancel Order` message can be used to cancel either futures or options orders.

##### CancelOrderUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `35 00` (53) |
| MessageType | 4 | 2 | Binary | `EB 03` (1003) |
| MatchingUnit | 6 | 1 | Binary | Must be zero or correct unit |
| Reserved | 7 | 1 | Binary | Must be zero |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message |
| OrigClOrdId | 12 | 20 | Text | The OrigClOrdId on a cancel should be the ClOrdId sent on the most recent modify (or new order if no modifies have been sent), even if the corresponding response has not yet been seen. |
| ClearingFirm | 32 | 4 | Alpha | EFID that will clear the trade. Port attribute value of 'Default EFID' is used if not provided. Sent to OCC in Exec Broker field. |
| ManualOrderIndicator | 36 | 1 | Text | `Y` = Manual order entry `N` = Automated order entry |
| OEOID | 37 | 18 | Text | Identifies the Order Entry Operator responsible for this message. Min length 3, max length 18. Values in ASCII range 33-126 except comma, semicolon, and pipe are permissible. |

#### Mass Cancel Order

A `Mass Cancel Order` message is a request to cancel a group of orders or quotes. A `Mass Cancel Order` message sent to a Unit port will only cancel orders on that port's unit.

Mass cancellation of a group of orders or quotes requires sending MassCancelInst which comprises filters used to specify the set of orders to cancel.

- If the Clearing Firm Filter is set to `F`, the ClearingFirm optional field must not be blank or the Cancel Order request will be rejected.
- If the Acknowledgement Style is set to `S` or `B`, or in combination with `M`, the MassCancelId must not be blank or the `Mass Cancel Order` request will be rejected.
- If the ProductName field is not blank then only orders for instruments associated with the product (e.g., `VX`) are cancelled.
- If Lockout Instruction is set to `L` and the ProductName optional field is not specified, a Firm-level Risk Reset is required to clear the Lockout condition. If Lockout Instruction is set to `L` and the ProductName optional field is specified, a Product level reset is required. Effective 08/24/26, Mass Cancel messages with Lockout Instruction = L will be rejected.
- Lockout will apply to all `New Order` and `Modify Order` messages for the ClearingFirm (and ProductName if specified), regardless of other filtering in the cancel order request message.

Any self-imposed lockout at the Firm/EFID or CustomGroupId level sent on a BOEv3 `Mass Cancel Order` message will only apply to the port’s matching unit and will not apply across all units.

The system limits the rate at which identical `Mass Cancel Order` and `Purge Orders` requests can be submitted to the system. Requests are restricted to twenty (20) messages per second per port.

An identical mass cancel message is defined as a message having all of the same CustomGroupId, Symbol, Clearing Firm, Instrument Type Filter and GTC Order Filter field values, as a previously received message.

##### MassCancelOrderUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `4B 00` (75) |
| MessageType | 4 | 2 | Binary | `EC 03` (1004) |
| MatchingUnit | 6 | 1 | Binary | Must be zero or correct unit |
| Reserved | 7 | 1 | Binary | Must be zero |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message |
| MassCancelId | 12 | 20 | Text | User-defined identifier of the mass cancel or purge request. |
| ClearingFirm | 32 | 4 | Alpha | EFID that will clear the trade. Port attribute value of 'Default EFID' is used if not provided. Sent to OCC in Exec Broker field. |
| ProductName | 36 | 6 | Text | Used to specify product class (e.g., "VX", "VA", etc.) for `Purge Orders` and `Cancel Order` message cancel by product functionality. If an unrecognized ProductName is provided, the associated request will be rejected with reason code C (Unknown Product Name). |
| MassCancelInst | 42 | 16 | Text | Corresponds to MassCancelInst (7700) in CFE FIX. Used for specification of `Purge Orders` functionality and optionally used for specification of Mass Cancel functionality associated with the `Cancel Order` message. At least one character must be provided (Clearing Firm Filter). Contiguous characters must be specified up to total length. Truncated/unspecified characters will default to values indicated (D) below. 1st Character : Clearing Firm Filter `A` = No filtering by clearing firm relationship is performed. `F` = All orders that were sent under the clearing relationship specified in ClearingFirm optional field. If "F" specified and ClearingFirm not provided, the Mass Cancel or Purge request will be rejected. 2nd Character : Acknowledgement Style `M` = (D) Order Cancelled messages are sent for each cancelled order. If "M" is set, any MassCancelId value is ignored. `S` = A single Mass Cancel Acknowledgement message is sent once all cancels have been processed. The MassCancelId optional field must be specified or the Mass Cancel or Purge Request will be rejected. `B` = Both individual Order Cancelled and Mass Cancel Acknowledgement messages will be sent. Also requires MassCancelId optional field to be specified or the Mass Cancel or Purge request will be rejected. 3rd Character : Lockout Instruction `N` = (D) No lockout `(Effective 08/24/26, this instruction will be required for all Mass Cancel messages)` `L` = Lockout until corresponding Reset Risk received. Lockout can be used only with Clearing Firm Filter set to "F", otherwise the Mass Cancel or Purge request will be rejected. Lockout will apply to all New Order, Quote Update, and Modify Order messages for the ClearingFirm (and ProductName or CustomGroupIds , if specified), regardless of other filtering in the Purge Orders or Cancel Order message. Effective 08/24/26, Mass Cancel messages with Lockout Instruction = L will be rejected. 4th Character : Instrument Type Filter `B` = (D) Cancel both Simple and Complex orders `S` = Cancel Simple orders only `C` = Cancel Spread orders only 5th Character : GTC Order Filter `C` = (D) Cancel GTC and GTD orders `P` = Don’t cancel (preserve) GTC and GTD orders 6th Character : Security Type `F` = Cancel orders (Futures only) `O` = Cancel orders (Options only) `A` = (D) Cancel All Futures and Options orders If ProductName optional field is specified, it must contain a valid futures root symbol (e.g., "VX"), in which case only orders/quotes associated with the specified product will be cancelled. A self-imposed lockout can be released using the Reset Risk message. An appropriate reset is required to be sent for each lockout type in order to resume trading. For example, a product-level lockout requires a product-level reset. For more information, refer to the CFE Risk Management Specification. |
| ManualOrderIndicator | 58 | 1 | Text | `Y` = Manual order entry `N` = Automated order entry |
| OEOID | 59 | 18 | Text | Identifies the Order Entry Operator responsible for this message. Min length 3, max length 18. Values in ASCII range 33-126 except comma, semicolon, and pipe are permissible. |

#### Purge Orders

Request to cancel a group of orders or quotes across all the TPH's sessions for that port's matching unit. This differs from a mass cancel request sent via a `Mass Cancel Order` message as the purge request is applied across all of the TPH's sessions, not just the session on which the `Mass Cancel Order` was received. In addition, the `Purge Orders` message accepts a list of CustomGroupIds as part of the order matching filter.

Any self-imposed lockout at the Firm/EFID or CustomGroupId level sent on a BOEv3 `Purge Orders` message will only apply to the port’s matching unit and will not apply across all units.

- `Purge Orders` requires sending MassCancelInst bitfield.
- Optionally ProductName, ClearingFirm, MassCancelId and list of CustomGroupId may also be sent (if non-blank).
- ProductName and CustomGroupId are mutually exclusive. Messages containing both will be rejected.
- A maximum of 10 CustomGroupId may be sent in one message.
- A `Purge Acknowledgment` message may be requested by setting the Acknowledgement Style value in the required `optional` field MassCancelInst to `S` or `B`or in combination with `M`. In these cases, the Purge Orders request will be rejected if the MassCancelId optional field is not provided.
- Individual `Order Cancelled` or `Quote Cancelled` messages are requested by setting the Acknowledgement Style value of the required `optional` field MassCancelInst to `M` or `B`.

The system limits the rate at which identical `Mass Cancel Order` and `Purge Orders` requests can be submitted to the system. Requests are restricted to twenty (20) messages per second per port.

An identical `Purge Orders` message is defined as a message having all of the same CustomGroupId, Symbol, Clearing Firm, Lockout Instruction, Instrument Type Filter and GTC Order Filter field values, as a previously received message.

##### PurgeOrdersUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | (76 + CustomGroupIdCnt*2) |
| MessageType | 4 | 2 | Binary | `ED 03` (1005) |
| MatchingUnit | 6 | 1 | Binary | Must be zero or correct unit |
| Reserved | 7 | 1 | Binary | Must be zero |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message |
| MassCancelId | 12 | 20 | Text | User-defined identifier of the mass cancel or purge request. |
| ClearingFirm | 32 | 4 | Alpha | EFID that will clear the trade. Port attribute value of 'Default EFID' is used if not provided. Sent to OCC in Exec Broker field. |
| ProductName | 36 | 6 | Text | Used to specify product class (e.g., "VX", "VA", etc.) for `Purge Orders` and `Cancel Order` message cancel by product functionality. If an unrecognized ProductName is provided, the associated request will be rejected with reason code C (Unknown Product Name). |
| MassCancelInst | 42 | 16 | Text | Corresponds to MassCancelInst (7700) in CFE FIX. Used for specification of `Purge Orders` functionality and optionally used for specification of Mass Cancel functionality associated with the `Cancel Order` message. At least one character must be provided (Clearing Firm Filter). Contiguous characters must be specified up to total length. Truncated/unspecified characters will default to values indicated (D) below. 1st Character : Clearing Firm Filter `A` = No filtering by clearing firm relationship is performed. `F` = All orders that were sent under the clearing relationship specified in ClearingFirm optional field. If "F" specified and ClearingFirm not provided, the Mass Cancel or Purge request will be rejected. 2nd Character : Acknowledgement Style `M` = (D) Order Cancelled messages are sent for each cancelled order. If "M" is set, any MassCancelId value is ignored. `S` = A single Mass Cancel Acknowledgement message is sent once all cancels have been processed. The MassCancelId optional field must be specified or the Mass Cancel or Purge Request will be rejected. `B` = Both individual Order Cancelled and Mass Cancel Acknowledgement messages will be sent. Also requires MassCancelId optional field to be specified or the Mass Cancel or Purge request will be rejected. 3rd Character : Lockout Instruction `N` = (D) No lockout `L` = Lockout until corresponding Reset Risk received. Lockout can be used only with Clearing Firm Filter set to "F", otherwise the Mass Cancel or Purge request will be rejected. Lockout will apply to all New Order, Quote Update, and Modify Order messages for the ClearingFirm (and ProductName or CustomGroupIds , if specified), regardless of other filtering in the Purge Orders or Cancel Order message. 4th Character : Instrument Type Filter `B` = (D) Cancel both Simple and Complex orders `S` = Cancel Simple orders only `C` = Cancel Spread orders only 5th Character : GTC Order Filter `C` = (D) Cancel GTC and GTD orders `P` = Don’t cancel (preserve) GTC and GTD orders 6th Character : Security Type F = Cancel orders (Futures only) `O` = Cancel orders (Options only) `A` = (D) Cancel All Futures and Options orders If ProductName optional field is specified, it must contain a valid futures root symbol (e.g., "VX"), in which case only orders/quotes associated with the specified product will be cancelled. A self-imposed lockout can be released using the Reset Risk message. An appropriate reset is required to be sent for each lockout type in order to resume trading. For example, a product-level lockout requires a product-level reset. For more information, refer to the CFE Risk Management Specification. |
| ManualOrderIndicator | 58 | 1 | Text | `Y` = Manual order entry `N` = Automated order entry |
| OEOID | 59 | 18 | Text | Identifies the Order Entry Operator responsible for this message. Min length 3, max length 18. Values in ASCII range 33-126 except comma, semicolon, and pipe are permissible. |
| CustomGroupIdCnt | 77 | 1 | Binary | Number of repeating CustomGroupId’s included in this message. |
| → CustomGroupId | 78 | 2 | Binary | Used to group orders for use in mass cancels where multiple orders can be cancelled by specifying a list of CustomGroupIds. A zero value is treated as "no CustomGroupIds". |

#### Quote Update

Request to enter or update one or more quotes. `Quote Update` requests will be forwarded in their entirety to the matching engine instance as a single message and will be applied in a single transaction.

All contracts in a single `Quote Update` must trade under a single futures root. Requests which include contracts trading under multiple futures roots will be rejected in their entirety.

A quote is unique per port, EFID, and side. You may quote multiple price levels of depth using either multiple EFIDs on a single port or with the same EFID on multiple ports.

Quote requests are one-sided. The cancellation of quotes can be done by sending a `Quote Update` with a zero size and a SizeModifier of NULL (0x00). The table below describes the possible combinations of zero/non-zero sizes and prices and the resulting behavior. The behavior differs depending on the product type (TAS vs non-TAS) and the value of the SizeModifier field.

`Quote Update` requests sent without any changes to the currently resting quote (no change quotes) will result in a loss of priority and will be reported back with a QuoteResult value of `L` (Modified; loss of priority) in the `Quote Update Acknowledgement` message.

- Time priority is maintained on a replacement quote in the following cases:
  - A decrease in OrderQty with no other changes
  - A decrease in OrderQty, a change to the OEOID and/or the ManualOrderIndicator , and no other changes. Product Type Zero Size Zero Price SizeModifier Result Trade At Settlement ("TAS") Y Y 0 Quote is cancelled Y N 0 Quote is cancelled N Y 0 Quote price updated Y Y R Quote price updated Y N R Quote price updated N Y R Quote size and price updated Standard (non-TAS) Y Y 0 Quote is cancelled Y N 0 Quote is cancelled N Y 0 Quote is cancelled Y Y R Quote is cancelled Y N R Quote price updated N Y R Quote is cancelled

Quotes may be for simple instruments only; complex/spread quotes may not be submitted.

All quotes will be automatically cancelled at the end of the trading day.

If a quote modification is rejected, the resting quote being modified is also cancelled.

Executions, unsolicited cancels, and unsolicited modification response messages from the exchange are different from those for orders. They are optimized for efficiency and contain some different data elements (e.g., QuoteUpdateId) than the respective messages for orders.

Match Trade Prevention is only available if defaulted at the port level. For BOE Unit Quoting ports, only Cancel Newest, Cancel Oldest, or Cancel Both are permitted. If a BOE Quoting port is not configured with both a default MTP Modifier and Unique Id Level, Match Trade Prevention will be disabled.

To maintain time priority, all attributes of an existing quote must be unchanged except for a reduction in size. Changing any other attribute or increasing size will result in a loss of time priority.

Capacity may not be changed when modifying a quote. To change Capacity of a resting quote, you must first send a quote with zero price and size and then re-enter the quote with the desired Capacity.

`Quote Update` and `New Order` messages submitted through BOE Unit Quoting ports will be available over ODROP.

During the queuing period, a `Quote Update` may only contain a bid and/or offer for a single TAS expiration.

The `Quote Update` message is to be used for Futures only orders. The `Quote Update Option` message is to be used for Options only orders. Both messages are acknowledged with a `Quote Update Acknowledgement` message or rejected with a `Quote Update Rejected` message, i.e. the same return message type applies to both Futures and Options.

##### QuoteUpdateUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | (79 + QuoteCnt*20) |
| MessageType | 4 | 2 | Binary | `EE 03` (1006) |
| MatchingUnit | 6 | 1 | Binary | Must be zero or correct unit |
| Reserved | 7 | 1 | Binary | Must be zero |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message |
| QuoteUpdateId | 12 | 16 | Text | Id chosen by the client. Characters in the ASCII range 33-126 are allowed, except for comma, semicolon, and pipe. All quote response messages will include this identifier. Note: CFE strongly recommends that QuoteUpdateId be kept unique for a trading day across both Futures and Options. |
| ClearingFirm | 28 | 4 | Alpha | EFID that will clear the trade. Port attribute value of 'Default EFID' is used if not provided. Sent to OCC in Exec Broker field. |
| ClearingAccount | 32 | 4 | Text | Supplemental identifier. Recorded and made available in execution reports. Available via Drop feeds. This field can be blank or populated with an optional four character string, except for comma, semicolon, and pipe . This field is not sent to the OCC. |
| CMTANumber | 36 | 4 | Binary | CMTA Number of the firm that will clear the trade. Must be specified for CMTA orders and left unspecified for non-CMTA orders. Sent to the OCC in the CMTA CM# field. |
| Account | 40 | 16 | Text | Unique account identifier associated with an order. This field will be reflected back on execution reports associated with this order. The first 10 characters are sent to the OCC in the Account # field. The entire 16 character string will appear in the optional CM Data field. Valid characters include ASCII 32-126. |
| CustomGroupId | 56 | 2 | Binary | Used to group orders for use in mass cancels where multiple orders can be cancelled by specifying a list of CustomGroupIds. A zero value is treated as "no CustomGroupIds". |
| Capacity | 58 | 1 | Text | `C` = Customer `F` = Firm The Capacity refers to the OCC account type. A value of "C" denotes an account that clears in the Customer range at OCC. A value of "F" denotes an account that clears in the Clearing Firm range at OCC. |
| CtiCode | 59 | 1 | Text | Valid values: 1, 2, 3, 4 `1` = CTI 1: Transactions initiated and executed by an individual TPH for the TPH’s own account, for an account the TPH controls, or for the account in which the TPH has an ownership or financial interest. `2` = CTI 2: Transactions executed for the proprietary account of a clearing TPH or non-clearing TPH. `3` = CTI 3: Transactions where an individual TPH or authorized trader executes for the personal account of another individual TPH, for an account the other individual TPH controls or for an account in which the other individual TPH has an ownership or financial interest. `4` = CTI 4: Any transaction not meeting the definition of CTI 1, 2 or 3. (These should be non-TPH customer transactions). |
| ManualOrderIndicator | 60 | 1 | Text | `Y` = Manual order entry `N` = Automated order entry |
| OEOID | 61 | 18 | Text | Identifies the Order Entry Operator responsible for this message. Min length 3, max length 18. Values in ASCII range 33-126 except comma, semicolon, and pipe are permissible. |
| SizeModifier | 79 | 1 | Text | Controls the behavior of the quote OrderQty field. Using "R" allows for a TPH to ensure that in-flight fills or cancels do not result in unwanted additional size exposure. NULL (0x00) = New quote size will be set to value of OrderQty . `R` = Reduce outstanding size of quote by the OrderQty provided. When using "R", if the resulting size is zero or negative, then the quote is cancelled. TPHs are expected to track the remaining quantity of each quote as resulting size is not included on the `Quote Update Acknowledgement` message. |
| QuoteCnt | 80 | 1 | Binary | Number of repeating groups included in this message. Allowed values are 1-20. |
| → QuoteSymbol | 81 | 6 | Alphanumeric | CFE native identifier of the instrument being quoted. |
| → Side | 87 | 1 | Text | `1` = Buy `2` = Sell |
| → OpenClose | 88 | 1 | Text | Indicates status of client position in a trade resulting from the order. `O` = Open `C` = Close `N` = None NUL (0x00) = None |
| → Price | 89 | 8 | BinaryPrice | Limit price. Four implied decimal places. Required for limit orders ( OrdType = 2). If specified on market order ( OrdType = 1), the order will be rejected. Orders will be rejected if Price does not fall on the applicable minimum trading increment. For all contracts other than Trade at Settlement contracts, simple orders will be rejected if Price is less than or equal to zero, or greater than or equal to 100,000. For Trade at Settlement (TAS) contracts, simple orders will be rejected if Price is outside the price limits presented in the contract specification. Spread orders will be rejected if Price is outside the price limits implied by the spread instrument definition and constituent instrument min and max prices. |
| → OrderQty | 97 | 4 | Binary | Order quantity. System limit is 999,999 contracts. |

##### QuoteUpdateOptionUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | (79 + QuoteCnt*20) |
| MessageType | 4 | 2 | Binary | `F2 03` (1010) |
| MatchingUnit | 6 | 1 | Binary | Must be zero or correct unit |
| Reserved | 7 | 1 | Binary | Must be zero |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message |
| QuoteUpdateId | 12 | 16 | Text | Id chosen by the client. Characters in the ASCII range 33-126 are allowed, except for comma, semicolon, and pipe. All quote response messages will include this identifier. Note: CFE strongly recommends that QuoteUpdateId be kept unique for a trading day across both Futures and Options.). |
| ClearingFirm | 28 | 4 | Alpha | EFID that will clear the trade. Port attribute value of 'Default EFID' is used if not provided. Sent to OCC in Exec Broker field. |
| ClearingAccount | 32 | 4 | Alpha | Supplemental identifier. Recorded and made available in execution reports. Available via Drop feeds. This field can be blank or populated with an optional four character string, except for comma, semicolon, and pipe . This field is not sent to the OCC. |
| CMTANumber | 36 | 4 | Binary | CMTA Number of the firm that will clear the trade. Must be specified for CMTA orders and left unspecified for non-CMTA orders. Sent to the OCC in the CMTA CM# field. |
| Account | 40 | 16 | Text | Unique account identifier associated with an order. This field will be reflected back on execution reports associated with this order. The first 10 characters are sent to the OCC in the Account # field. The entire 16 character string will appear in the optional CM Data field. Valid characters include ASCII 32-126. |
| CustomGroupId | 56 | 2 | Binary | Used to group orders for use in mass cancels where multiple orders can be cancelled by specifying a list of CustomGroupIds. A zero value is treated as "no CustomGroupIds". |
| Capacity | 58 | 1 | Text | `C` = Customer `F` = Firm The Capacity refers to the OCC account type. A value of "C" denotes an account that clears in the Customer range at OCC. A value of "F" denotes an account that clears in the Clearing Firm range at OCC. |
| CtiCode | 59 | 1 | Text | Valid values: 1, 2, 3, 4 `1` = CTI 1: Transactions initiated and executed by an individual TPH for the TPH’s own account, for an account the TPH controls, or for the account in which the TPH has an ownership or financial interest. `2` = CTI 2: Transactions executed for the proprietary account of a clearing TPH or non-clearing TPH. `3` = CTI 3: Transactions where an individual TPH or authorized trader executes for the personal account of another individual TPH, for an account the other individual TPH controls or for an account in which the other individual TPH has an ownership or financial interest. `4` = CTI 4: Any transaction not meeting the definition of CTI 1, 2 or 3. (These should be non-TPH customer transactions). |
| ManualOrderIndicator | 60 | 1 | Text | `Y` = Manual order entry `N` = Automated order entry |
| OEOID | 61 | 18 | Text | Identifies the Order Entry Operator responsible for this message. Min length 3, max length 18. Values in ASCII range 33-126 except comma, semicolon, and pipe are permissible. |
| SizeModifier | 79 | 1 | Text | Controls the behavior of the quote OrderQty field. Using "R" allows for a TPH to ensure that in-flight fills or cancels do not result in unwanted additional size exposure. NULL (0x00) = New quote size will be set to value of OrderQty . `R` = Reduce outstanding size of quote by the OrderQty provided. When using "R", if the resulting size is zero or negative, then the quote is cancelled. TPHs are expected to track the remaining quantity of each quote as resulting size is not included on the `Quote Update Acknowledgement` message. |
| QuoteCnt | 80 | 1 | Binary | Number of repeating groups included in this message. Allowed values are 1-20. |
| → QuoteSymbol | 81 | 6 | Alphanumeric | CFE native identifier of the instrument being quoted. |
| → Side | 87 | 1 | Text | `1` = Buy `2` = Sell |
| → OpenClose | 88 | 1 | Text | Indicates status of client position in a trade resulting from the order. `O` = Open `C` = Close `N` = None NUL (0x00) = None |
| → Price | 89 | 8 | BinaryPrice | Limit price. Four implied decimal places. Required for limit orders ( OrdType = 2). If specified on market order ( OrdType = 1), the order will be rejected. Orders will be rejected if Price does not fall on the applicable minimum trading increment. For all contracts other than Trade at Settlement contracts, simple orders will be rejected if Price is less than or equal to zero, or greater than or equal to 100,000. For Trade at Settlement (TAS) contracts, simple orders will be rejected if Price is outside the price limits presented in the contract specification. Spread orders will be rejected if Price is outside the price limits implied by the spread instrument definition and constituent instrument min and max prices. |
| → OrderQty | 97 | 4 | Binary | Order quantity. System limit is 999,999 contracts. |

#### Reset Risk

Reset or release Firm/EFID, Product, or Custom Group Id level lockout conditions resulting from risk profile trips or self-imposed lockouts issued via `Purge Orders` messages. Risk resets can be performed using this message. New in BOEv3 - risk resets at the Firm/EFID and CustomGroupId levels will only apply to the unit associated with the BOEv3 port that is used.

Only one unique risk reset of a given type (Firm/EFID, Product, CustomGroupId) is allowed per second. Additional resets will be ignored (RiskResetResult = <space>). For example, a customer may reset risk for CustomGroupId = 1 and may not reset risk again for CustomGroupId = 1 until one second has elapsed. This restriction is designed to safeguard the trading platform from excessive risk messaging.

##### ResetRiskUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `2E 00` (46) |
| MessageType | 4 | 2 | Binary | `EF 03` (1007) |
| MatchingUnit | 6 | 1 | Binary | Must be zero or correct unit |
| Reserved | 7 | 1 | Binary | Must be zero |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message |
| RiskStatusId | 12 | 16 | Text | Unique identifier for this Reset Risk request. Response message will have this corresponding identifier. Note: CFE only enforces uniqueness of RiskStatusId values among currently unacknowledged requests. However, we strongly recommend that you keep your RiskStatusId values day-unique. |
| RiskReset | 28 | 8 | Text | Single Character Values (Values may be combined) `S` = Product-level risk/lockout reset (Futures only) `F` = Firm-level risk/lockout reset (Futures only) `C` = CustomGroupId lockout reset (Futures only) `R` = Product-level risk/lockout reset (Options only) `I` = Firm-level risk/lockout reset (Options only) `D` = CustomGroupId lockout reset (Options only) Values may be combined together to allow for resets of multiple risk trips or self-imposed lockouts in a single message. For example, `FS` , `SC` , `FC` , and `SFC` are all acceptable values. The characters may be combined in any order. For example, to "reset all futures", set this field to `SFC` , which is the equivalent to `CFS` . To "reset all options", set this field to `RID` , which is equivalent to `DIR` . To "reset all futures and options" set the field to `SFCRID` , which is equivalent to `DIRCFS` . For more information, refer to the CFE Risk Management Specification. |
| ClearingFirm | 36 | 4 | Alpha | Risk will be reset for this EFID. Resets a self-imposed EFID-level lockout initiated using a purge request. Required on all resets. |
| ProductName | 40 | 6 | Text | Used to specify product class (e.g., "VX", "VA", etc.) for `Purge Orders` and `Cancel Order` message cancel by product functionality. If an unrecognized ProductName is provided, the associated request will be rejected with reason code C (Unknown Product Name). |
| CustomGroupId | 46 | 2 | Binary | Used to group orders for use in mass cancels where multiple orders can be cancelled by specifying a list of CustomGroupIds. A zero value is treated as "no CustomGroupIds". |

#### New Complex Instrument (Options Only)

A `New Complex Instrument` message is used to request that the system create a complex strategy. The resulting symbol (if accepted by the system) will be returned in a `New Complex Instrument Accepted` message. A `New Complex Instrument Rejected` message will be sent if it is not accepted. Complex instruments must contain a minimum of 2 and a maximum of 16 legs. Creating new complex strategies is allowed for Options on Futures only.

##### NewComplexInstrumentOptionUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | (35 + LegCnt * 13) |
| MessageType | 4 | 2 | Binary | `F3 03` (1011) |
| MatchingUnit | 6 | 1 | Binary | Must be zero or correct unit |
| Reserved | 7 | 1 | Binary | Must be zero |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message |
| ClOrdId | 12 | 20 | Text | Unique Id chosen by the client. Characters in the ASCII range 33-126 are allowed, except for comma, semicolon, and pipe . If the ClOrdId matches a live order, the order will be rejected as duplicate. A leading tilde (~) cannot be sent on any ClOrdId and will result in a reject. These are reserved for internal use by CFE and could be received as a result of a CFE-generated ClordId . Sent to the OCC in the OrderId field. Note: CFE only enforces uniqueness of ClOrdId values among currently live orders, which includes long-lived GTC and GTD orders. However, using unique ClOrdId values is strongly recommend. |
| ClearingFirm | 32 | 4 | Alpha | EFID associated with creating the complex instrument. Port attribute value of 'Default EFID' is used if not provided. |
| LegCnt | 36 | 1 | Binary | The number of legs in this complex instrument. Must be a minimum of 2 and maximum of 16 legs. |
| → LegSymbol | 37 | 8 | Alphanumeric | The symbol id for the simple Options on Futures instrument. |
| → LegRatioQty | 45 | 4 | Binary | Ratio of number of contracts in this leg per order quantity. All legs must be reduced (i.e., 2:2 must be sent as 1:1) in order to be accepted by the system when using this message type. Accepted values are 1-99,999 |
| → LegSide | 49 | 1 | Text | `1` = Buy `2` = Sell |

### CFE to TPH

#### Order Acknowledgement

`Order Acknowledgement` messages are sent in response to a `New Order` message. The message corresponds to a FIX Execution Report with ExecType (150) = 0 (New).

##### OrderAcknowledgementUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `AB 00` (171) |
| MessageType | 4 | 2 | Binary | `DD 05` (1501) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message. Distinct per Matching Unit |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| ClOrdId | 20 | 20 | Text | Echoed back from the TPH message |
| OrderId | 40 | 8 | Binary | Order identifier supplied by CFE. This identifier corresponds to the identifiers used in CFE market data products. Sent to the OCC in the Exchange Data field. |
| Side | 48 | 1 | Text | Echoed back from the TPH message |
| Price | 49 | 8 | BinaryPrice | Echoed back from the TPH message |
| OrdType | 57 | 1 | Text | Echoed back from the TPH message |
| TimeInForce | 58 | 1 | Text | Echoed back from the TPH message |
| MinQty | 59 | 4 | Binary | Echoed back from the TPH message |
| Symbol | 63 | 8 | Alphanumeric | Echoed back from the TPH message |
| Capacity | 71 | 1 | Text | Echoed back from the TPH message |
| Account | 72 | 16 | Text | Echoed back from the TPH message |
| ClearingFirm | 88 | 4 | Alpha | Echoed back from the TPH message |
| ClearingAccount | 92 | 4 | Alpha | Echoed back from the TPH message |
| OrderQty | 96 | 4 | Binary | Echoed back from the TPH message |
| PreventMatch | 100 | 3 | Alpha | PreventMatch as accepted by CBOE. Note that an empty field indicates None (Match Trade Prevention not applied). |
| MaturityDate | 103 | 4 | Date | Echoed back from the TPH message |
| OpenClose | 107 | 1 | Text | Echoed back from the TPH message |
| LeavesQty | 108 | 4 | Binary | Quantity still open for further execution. If zero, the order is complete. |
| BaseLiquidityIndicator | 112 | 1 | Text | Indicates whether the trade added or removed liquidity. `A` = Added Liquidity `R` = Removed Liquidity `C` = Market opening / re-opening trade |
| ExpireTime | 113 | 8 | DateTime | Echoed back from the TPH message |
| SubLiquidityIndicator | 121 | 1 | Text | Additional information about the liquidity of an order. CFE may add additional values without notice. TPHs must gracefully ignore unknown values. NULL (0x00) = No Additional Information `C` = Carried Order Indicator `U` = Qualifying Market Turner order |
| StopPx | 122 | 8 | BinaryPrice | Echoed back from the TPH message |
| CMTANumber | 130 | 4 | Binary | Echoed back from the TPH message |
| CtiCode | 134 | 1 | Text | Echoed back from the TPH message |
| ManualOrderIndicator | 135 | 1 | Text | Echoed back from the TPH message |
| OEOID | 136 | 18 | Text | Echoed back from the TPH message |
| CumQty | 154 | 4 | Binary | Echoed back from the TPH message |
| FrequentTraderId | 158 | 6 | Alphanumeric | Echoed back from the TPH message |
| CustOrderHandlingInst | 164 | 1 | Text | Echoed back from the TPH message |
| RequestReceivedTime | 165 | 8 | DateTime | A hardware timestamp, populated with nanosecond precision, that represents when the order handler server NIC observed the inbound message. Populated with zero in event of failover to Port B or Port C. |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

##### OrderAcknowledgementOptionUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | (174 + LegCnt) |
| MessageType | 4 | 2 | Binary | `F3 05` (1523) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message. Distinct per Matching Unit |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| ClOrdId | 20 | 20 | Text | Echoed back from the TPH message |
| OrderId | 40 | 8 | Binary | Order identifier supplied by CFE. This identifier corresponds to the identifiers used in CFE market data products. Sent to the OCC in the Exchange Data field. |
| Side | 48 | 1 | Text | Echoed back from the TPH message |
| Price | 49 | 8 | BinaryPrice | Echoed back from the TPH message |
| OrdType | 57 | 1 | Text | Echoed back from the TPH message |
| TimeInForce | 58 | 1 | Text | Echoed back from the TPH message |
| Symbol | 59 | 8 | Alphanumeric | Echoed back from the TPH message |
| SecurityDesc | 67 | 16 | Text | Echoed back from the TPH message |
| Capacity | 83 | 1 | Text | Echoed back from the TPH message |
| Account | 84 | 16 | Text | Echoed back from the TPH message |
| ClearingFirm | 100 | 4 | Alpha | Echoed back from the TPH message |
| ClearingAccount | 104 | 4 | Alpha | Echoed back from the TPH message |
| OrderQty | 108 | 4 | Binary | Echoed back from the TPH message |
| PreventMatch | 112 | 3 | Alpha | PreventMatch as accepted by CBOE. Note that an empty field indicates None (Match Trade Prevention not applied). |
| OpenClose | 115 | 1 | Text | Echoed back from the TPH message |
| LeavesQty | 116 | 4 | Binary | Quantity still open for further execution. If zero, the order is complete. |
| BaseLiquidityIndicator | 120 | 1 | Text | Indicates whether the trade added or removed liquidity. `A` = Added Liquidity `R` = Removed Liquidity `C` = Market opening / re-opening trade |
| ExpireTime | 121 | 8 | DateTime | Echoed back from the TPH message |
| SubLiquidityIndicator | 129 | 1 | Text | Additional information about the liquidity of an order. CFE may add additional values without notice. TPHs must gracefully ignore unknown values. NULL (0x00) = No Additional Information `C` = Carried Order Indicator `U` = Qualifying Market Turner order |
| CMTANumber | 130 | 4 | Binary | Echoed back from the TPH message |
| CtiCode | 134 | 1 | Text | Echoed back from the TPH message |
| ManualOrderIndicator | 135 | 1 | Text | Echoed back from the TPH message |
| OEOID | 136 | 18 | Text | Echoed back from the TPH message |
| CumQty | 154 | 4 | Binary | Echoed back from the TPH message |
| FrequentTraderId | 158 | 6 | Alphanumeric | Echoed back from the TPH message |
| CustOrderHandlingInst | 164 | 1 | Text | Echoed back from the TPH message |
| CountryCode | 165 | 2 | Text | Echoed back from the TPH message |
| RequestReceivedTime | 167 | 8 | DateTime | The earliest timestamp, populated with nanosecond precision, recorded by CFE of the corresponding inbound message being acknowledged. Populated with zero in event of failover to Port B or Port C. |
| LegCnt | 175 | 1 | Binary | Echoed back from the TPH message |
| → LegPositionEffect | 176 | 1 | Text | Echoed back from the TPH message (repeats LegCnt times) |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

#### Order Rejected

`Order Rejected` messages are sent in response to a `New Order` which must be rejected. This message corresponds to a FIX Execution Report with ExecType (150) = 8 (Rejected). `Order Rejected` messages are unsequenced.

##### OrderRejectedUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `67 00` (103) |
| MessageType | 4 | 2 | Binary | `DE 05` (1502) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | Always zero (unsequenced) |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| ClOrdId | 20 | 20 | Text | Echoed back from the TPH message |
| ClearingFirm | 40 | 4 | Alphanumeric | Echoed back from the TPH message |
| OrderRejectReason | 44 | 1 | Text | See Order Reason Codes. |
| Text | 45 | 60 | Text | Human readable text with more information. |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

#### Order Modified

`Order Modified` messages are sent in response to a `Modify Order` to indicate that the order has been successfully modified.

In some cases, the last message to be received on an order's life cycle will be an `Order Modified` message. The way to know the order is no longer live is to inspect LeavesQty. An example of this would be modification of an order whilst an execution is being generated, resulting in the order being reduced to zero outstanding quantity.

##### OrderModifiedUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `6F 00` (111) |
| MessageType | 4 | 2 | Binary | `DF 05` (1503) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message. Distinct per Matching Unit |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| ClOrdId | 20 | 20 | Text | Echoed back from the TPH message |
| OrigClOrdId | 40 | 20 | Text | The ClOrdId of the original order. |
| OrderId | 60 | 8 | Binary | Order identifier supplied by CFE. This identifier corresponds to the identifiers used in CFE market data products. Sent to the OCC in the Exchange Data field. |
| ClearingFirm | 68 | 4 | Alpha | Echoed back from the TPH message |
| Price | 72 | 8 | BinaryPrice | Echoed back from the TPH message |
| OrdType | 80 | 1 | Text | Echoed back from the TPH message |
| OrderQty | 81 | 4 | Binary | Echoed back from the TPH message |
| LeavesQty | 85 | 4 | Binary | Quantity still open for further execution. If zero, the order is complete. |
| BaseLiquidityIndicator | 89 | 1 | Text | Indicates whether the trade added or removed liquidity. `A` = Added Liquidity `R` = Removed Liquidity `C` = Market opening / re-opening trade |
| StopPx | 90 | 8 | BinaryPrice | Echoed back from the TPH message |
| FrequentTraderId | 98 | 6 | Alphanumeric | Echoed back from the TPH message |
| CustOrderHandlingInst | 104 | 1 | Text | Echoed back from the TPH message |
| RequestReceivedTime | 105 | 8 | DateTime | The earliest timestamp, populated with nanosecond precision, recorded by CFE of the corresponding inbound message being acknowledged. Populated with zero in event of failover to Port B or Port C. |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

#### Modify Rejected

`Modify Rejected` messages are sent in response to a `Modify Order` for an order which cannot be modified. `Modify Rejected` messages are unsequenced.

This message corresponds to a FIX Execution Report with MsgType (35) = 9 (Order Cancel Reject) and CxlRejResponseTo (434) = 2 (Order Cancel/Replace Request).

##### ModifyRejectedUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `7B 00` (123) |
| MessageType | 4 | 2 | Binary | `E0 05` (1504) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | Always zero (unsequenced) |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| ClOrdId | 20 | 20 | Text | Echoed back from the TPH message |
| OrigClOrdId | 40 | 20 | Text | The ClOrdId of the original order. |
| ClearingFirm | 60 | 4 | Alpha | Echoed back from the TPH message |
| ModifyRejectReason | 64 | 1 | Text | See Order Reason Codes. |
| Text | 65 | 60 | Text | Human readable text with more information. |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

#### Order Execution

An `Order Execution` is sent for each fill on an order.

Rather than returning a monetary value indicating the rebate or charge for an execution, the FeeCode is an indication of a fee classification corresponding to an item on the venue's fee schedule.

For executions involving Spread orders, if both sides of a complex/spread trade are on the same order entry session, Cboe does not guarantee that the leg executions will not be interleaved between sides.

##### OrderExecutionUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `65 00` (101) |
| MessageType | 4 | 2 | Binary | `E1 05` (1505) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message. Distinct per Matching Unit |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| ClOrdId | 20 | 20 | Text | The order which was executed |
| ExecId | 40 | 8 | Binary | Sent to the OCC in the Trade Id field. Execution Id. Unique across all matching units on a given day. Note: ExecIds will be represented on ODROP and FIXDROP ports as base 36 ASCII. |
| LastShares | 48 | 4 | Binary | Executed contracts quantity. |
| LastPx | 52 | 8 | BinaryPrice | Price of this fill. Note the use of Price type to represent positive and negative prices, which can occur with spread instruments. |
| LeavesQty | 60 | 4 | Binary | Quantity still open for further execution. If zero, the order is complete. |
| BaseLiquidityIndicator | 64 | 1 | Text | Indicates whether the trade added or removed liquidity. `A` = Added Liquidity `R` = Removed Liquidity `C` = Market opening / re-opening trade |
| SubLiquidityIndicator | 65 | 1 | Text | Additional information about the liquidity of an order. CFE may add additional values without notice. TPHs must gracefully ignore unknown values. NULL (0x00) = No Additional Information `C` = Carried Order Indicator `U` = Qualifying Market Turner order |
| Side | 66 | 1 | Text | Echoed back from the TPH message |
| Symbol | 67 | 8 | Alphanumeric | Echoed back from the TPH message |
| ClearingFirm | 75 | 4 | Alpha | Echoed back from the TPH message |
| MaturityDate | 79 | 4 | Date | Maturity date of the instrument |
| FeeCode | 83 | 2 | Alphanumeric | Indicates fee associated with an execution. Fee codes are published in the pricing schedule. New fee codes may be sent with little or no notice. TPHs are encouraged to code their systems to accept unknown fee codes. |
| TradeDate | 85 | 4 | Date | Business date of the execution. Note that on CFE, business date is not always the same as the calendar date. For example, the VX/VT products open for trading on the calendar day prior to the associated business date. Executions that occur after the open and before midnight will have a TradeDate value that is not the same as the calendar date of the execution. |
| ClearingSize | 89 | 4 | Binary | Size to clear with OCC. Same value as LastShares, except in VA and VAO where ClearingSize is 0 on execution, and the converted clearing size on restatement. |
| PendingStatus | 93 | 1 | Text | Field is provided as a convenience to determine whether an `Order Execution` message is a preliminary notification representing a pending trade. The value `P` indicates that the execution is associated with a product for which the `Order Execution` message is a preliminary notification of an execution and for which a post-settlement restatement will be sent. `N` = Not applicable `P` = Pending |
| MultilegReportingType | 94 | 1 | Text | Present on `Order Execution` and `TAS Restatement` messages representing either Spread orders or Simple orders that are part Spread execution. `1` = Simple instrument execution `2` = Simple instrument execution that is part of a Spread execution `3` = Spread instrument execution |
| SecondaryExecId | 95 | 8 | Binary | Indicates whether an execution is a spread or a simple instrument execution that is part of a spread trade. If SecondaryExecId field is not present, the execution is a simple instrument execution only. If SecondaryExecId is present and is the same as the ExecId required field, the execution represents a spread execution for which associated simple instrument executions will follow. Simple instrument executions associated with a spread execution will contain a SecondaryExecId value that matches the ExecId of the associated spread execution. |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

##### OrderExecutionOptionUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `71 00` (113) |
| MessageType | 4 | 2 | Binary | `F4 05` (1524) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message. Distinct per Matching Unit |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| ClOrdId | 20 | 20 | Text | The order which was executed |
| ExecId | 40 | 8 | Binary | Sent to the OCC in the Trade Id field. Execution Id. Unique across all matching units on a given day. Note: ExecIds will be represented on ODROP and FIXDROP ports as base 36 ASCII. |
| LastShares | 48 | 4 | Binary | Executed contracts quantity. |
| LastPx | 52 | 8 | BinaryPrice | Price of this fill. Note the use of Price type to represent positive and negative prices, which can occur with spread instruments. |
| LeavesQty | 60 | 4 | Binary | Quantity still open for further execution. If zero, the order is complete. |
| BaseLiquidityIndicator | 64 | 1 | Text | Indicates whether the trade added or removed liquidity. `A` = Added Liquidity `R` = Removed Liquidity `C` = Market opening / re-opening trade |
| SubLiquidityIndicator | 65 | 1 | Text | Additional information about the liquidity of an order. CFE may add additional values without notice. TPHs must gracefully ignore unknown values. NULL (0x00) = No Additional Information `C` = Carried Order Indicator `U` = Qualifying Market Turner order |
| Side | 66 | 1 | Text | Echoed back from the TPH message |
| Symbol | 67 | 8 | Alphanumeric | Echoed back from the TPH message |
| ClearingFirm | 75 | 4 | Alpha | Echoed back from the TPH message |
| SecurityDesc | 79 | 16 | Text | Echoed back from the TPH message |
| FeeCode | 95 | 2 | Alphanumeric | Indicates fee associated with an execution. Fee codes are published in the pricing schedule. New fee codes may be sent with little or no notice. TPHs are encouraged to code their systems to accept unknown fee codes. |
| TradeDate | 97 | 4 | Date | Business date of the execution. Note that on CFE, business date is not always the same as the calendar date. For example, the VX/VT products open for trading on the calendar day prior to the associated business date. Executions that occur after the open and before midnight will have a TradeDate value that is not the same as the calendar date of the execution. |
| ClearingSize | 101 | 4 | Binary | Size to clear with OCC. Same value as LastShares, except in VA and VAO where ClearingSize is 0 on execution, and the converted clearing size on restatement. |
| PendingStatus | 105 | 1 | Text | Field is provided as a convenience to determine whether an `Order Execution` message is a preliminary notification representing a pending trade. The value `P` indicates that the execution is associated with a product for which the `Order Execution` message is a preliminary notification of an execution and for which a post-settlement restatement will be sent. `N` = Not applicable `P` = Pending |
| MultilegReportingType | 106 | 1 | Text | Present on `Order Execution` and `TAS Restatement` messages representing either Spread orders or Simple orders that are part Spread execution. `1` = Simple instrument execution `2` = Simple instrument execution that is part of a Spread execution `3` = Spread instrument execution |
| SecondaryExecId | 107 | 8 | Binary | Indicates whether an execution is a spread or a simple instrument execution that is part of a spread trade. If SecondaryExecId field is not present, the execution is a simple instrument execution only. If SecondaryExecId is present and is the same as the ExecId required field, the execution represents a spread execution for which associated simple instrument executions will follow. Simple instrument executions associated with a spread execution will contain a SecondaryExecId value that matches the ExecId of the associated spread execution. |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

#### Order Cancelled

`Order Cancelled` messages indicates an order has been cancelled.

##### OrderCancelledUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `33 00` (51) |
| MessageType | 4 | 2 | Binary | `E2 05` (1506) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message. Distinct per Matching Unit |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| ClOrdId | 20 | 20 | Text | The order which was cancelled. |
| ClearingFirm | 40 | 4 | Alpha | EFID that would clear the trade. |
| CancelReason | 44 | 1 | Text | See Section Order Reason Codes. |
| RequestReceivedTime | 45 | 8 | DateTime | The earliest timestamp, populated with nanosecond precision, recorded by CFE of the corresponding inbound message being acknowledged. Populated with zero in event of failover to Port B or Port C. Note: Value will be 0 if this is not a response to a `Cancel Order` message. |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

#### Cancel Rejected

A `Cancel Rejected` message is sent in response to a `Cancel Order` message to indicate that the cancellation cannot occur. `Cancel Rejected` messages are unsequenced.

##### CancelRejectedUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `67 00` (103) |
| MessageType | 4 | 2 | Binary | `E3 05` (1507) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | Always zero (unsequenced) |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| ClOrdId | 20 | 20 | Text | Echoed back from the TPH message |
| ClearingFirm | 40 | 4 | Alpha | Echoed back from the TPH message |
| CancelRejectReason | 44 | 1 | Text | See Order Reason Codes. |
| Text | 45 | 60 | Text | Human readable text with more information. |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

#### Mass Cancel Acknowledgement

A `Mass Cancel Acknowledgment` is an unsequenced message sent when a `Cancel Order` or `Purge Orders` message requesting a mass cancellation has completed cancelling all individual orders.

##### MassCancelAcknowledgementUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `32 00` (50) |
| MessageType | 4 | 2 | Binary | `E4 05` (1508) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | Always zero (unsequenced) |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| MassCancelId | 20 | 20 | Text | Echoed back from the TPH message |
| CancelledOrderCount | 40 | 4 | Binary | Number of orders cancelled. |
| RequestReceivedTime | 44 | 8 | DateTime | The earliest timestamp, populated with nanosecond precision, recorded by CFE of the corresponding inbound message being acknowledged. Populated with zero in event of failover to Port B or Port C. |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

#### Mass Cancel Rejected

A `Mass Cancel Rejected` message is sent in response to a `Mass Cancel Order` message to indicate that the mass cancellation cannot occur. `Mass Cancel Rejected` messages are unsequenced.

##### MassCancelRejectedUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `63 00` (99) |
| MessageType | 4 | 2 | Binary | `E5 05` (1509) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | Always zero (unsequenced) |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| MassCancelId | 20 | 20 | Text | Echoed back from the TPH message |
| MassCancelRejectReason | 40 | 1 | Text | Reason for the mass cancel rejection. See Order Reason Codes. |
| Text | 41 | 60 | Text | Human readable text with more information. |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

#### Purge Acknowledgement

A `Purge Acknowledgment` is an unsequenced message sent when a `Purge Orders` message requesting an order purge has completed cancelling all individual orders.

##### PurgeAcknowledgementUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `32 00` (50) |
| MessageType | 4 | 2 | Binary | `E6 05` (1510) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | Always zero (unsequenced) |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| MassCancelId | 20 | 20 | Text | Echoed back from the TPH message |
| CancelledOrderCount | 40 | 4 | Binary | Number of orders cancelled. |
| RequestReceivedTime | 44 | 8 | DateTime | The earliest timestamp, populated with nanosecond precision, recorded by CFE of the corresponding inbound message being acknowledged. Populated with zero in event of failover to Port B or Port C. |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

#### Purge Rejected

A `Purge Rejected` message is sent in response to a `Purge Orders` message to indicate that the mass cancellation cannot occur. `Purge Rejected` messages are unsequenced.

##### PurgeRejectedUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `63 00` (99) |
| MessageType | 4 | 2 | Binary | `E7 05` (1511) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | Always zero (unsequenced) |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| MassCancelId | 20 | 20 | Text | Echoed back from the TPH message |
| PurgeRejectReason | 40 | 1 | Text | Reason for the purge rejection. See Order Reason Codes |
| Text | 41 | 60 | Text | Human readable text with more information. |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

#### Trade Cancel or Correct

Used to provide notification that a trade has been cancelled (busted) or corrected (price change only). The CorrectedPrice field will be set to 0 for cancelled trades and to the new trade price for corrected trades.

##### TradeCancelCorrectUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `66 00` (102) |
| MessageType | 4 | 2 | Binary | `E8 05` (1512) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message. Distinct per Matching Unit |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| ClOrdId | 20 | 20 | Text | The order which was executed. |
| ExecRefId | 40 | 8 | Binary | Refers to the ExecId of the fill being cancelled or corrected. |
| Side | 48 | 1 | Text | `1` = Buy `2` = Sell |
| BaseLiquidityIndicator | 49 | 1 | Text | Indicates whether the trade added or removed liquidity. `A` = Added Liquidity `R` = Removed Liquidity `C` = Market opening / re-opening trade |
| ClearingFirm | 50 | 4 | Alpha | EFID that will clear the trade. Port attribute value of 'Default EFID' is used if not provided. Sent to OCC in Exec Broker field. |
| ClearingAccount | 54 | 4 | Text | Supplemental identifier. Recorded and made available in execution reports. Available via Drop feeds. This field can be blank or populated with an optional four character string, except for comma, semicolon, and pipe . This field is not sent to the OCC. |
| LastShares | 58 | 4 | Binary | Executed contracts quantity. |
| LastPx | 62 | 8 | BinaryPrice | Price of this fill. Note the use of Price type to represent positive and negative prices, which can occur with spread instruments. |
| CorrectedPrice | 70 | 8 | BinaryPrice | For trade corrections, this is the new trade price. For trade breaks, this is set to 0. |
| OrigTime | 78 | 8 | DateTime | The date and time of the original trade, in GMT. |
| Symbol | 86 | 8 | Alphanumeric | CFE native identifier of the instrument |
| Capacity | 94 | 1 | Text | `C` = Customer `F` = Firm The Capacity refers to the OCC account type. A value of `C` denotes an account that clears in the Customer range at OCC. A value of `F` denotes an account that clears in the Clearing Firm range at OCC. |
| MaturityDate | 95 | 4 | Date | Maturity date of the instrument |
| OpenClose | 99 | 1 | Text | Indicates status of client position in a trade resulting from the order. `O` = Open `C` = Close `N` = None NUL (0x00) = None |
| CMTANumber | 100 | 4 | Binary | CMTA Number of the firm that will clear the trade. Must be specified for CMTA orders and left unspecified for non-CMTA orders. Sent to the OCC in the CMTA CM# field. |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

##### TradeCancelCorrectOptionUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `72 00` (114) |
| MessageType | 4 | 2 | Binary | `F5 05` (1525) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message. Distinct per Matching Unit |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| ClOrdId | 20 | 20 | Text | The order which was executed. |
| ExecRefId | 40 | 8 | Binary | Refers to the ExecId of the fill being cancelled or corrected. |
| Side | 48 | 1 | Text | `1` = Buy `2` = Sell |
| BaseLiquidityIndicator | 49 | 1 | Text | Indicates whether the trade added or removed liquidity. `A` = Added Liquidity `R` = Removed Liquidity `C` = Market opening / re-opening trade |
| ClearingFirm | 50 | 4 | Alpha | EFID that will clear the trade. Port attribute value of 'Default EFID' is used if not provided. Sent to OCC in Exec Broker field. |
| ClearingAccount | 54 | 4 | Alpha | Supplemental identifier. Recorded and made available in execution reports. Available via Drop feeds. This field can be blank or populated with an optional four character string, except for comma, semicolon, and pipe . This field is not sent to the OCC. |
| LastShares | 58 | 4 | Binary | Executed contracts quantity. |
| LastPx | 62 | 8 | BinaryPrice | Price of this fill. Note the use of Price type to represent positive and negative prices, which can occur with spread instruments. |
| CorrectedPrice | 70 | 8 | BinaryPrice | For trade corrections, this is the new trade price. For trade breaks, this is set to 0. |
| OrigTime | 78 | 8 | DateTime | The date and time of the original trade, in GMT. |
| Symbol | 86 | 8 | Alphanumeric | CFE native identifier of the instrument |
| Capacity | 94 | 1 | Text | `C` = Customer `F` = Firm The Capacity refers to the OCC account type. A value of `C` denotes an account that clears in the Customer range at OCC. A value of `F` denotes an account that clears in the Clearing Firm range at OCC. |
| SecurityDesc | 95 | 16 | Text | The Options on Futures identifier. |
| OpenClose | 111 | 1 | Text | Indicates status of client position in a trade resulting from the order. `O` = Open `C` = Close `N` = None NUL (0x00) = None |
| CMTANumber | 112 | 4 | Binary | CMTA Number of the firm that will clear the trade. Must be specified for CMTA orders and left unspecified for non-CMTA orders. Sent to the OCC in the CMTA CM# field. |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

#### TAS Restatement

A `TAS Restatement` is sent post-settlement time for each TAS (e.g., VXT, VXMT, etc.) execution during the associated business day to communicate the updated Price and Symbol associated with the cleared execution. `TAS Restatement` messages are sent shortly after the VX and VXM contract settlement prices are disseminated.

##### TASRestatementUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `72 00` (114) |
| MessageType | 4 | 2 | Binary | `E9 05` (1513) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message. Distinct per Matching Unit |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| ClOrdId | 20 | 20 | Text | The order being restated |
| ClearingFirm | 40 | 4 | Alpha | EFID that will clear the trade. Port attribute value of 'Default EFID' is used if not provided. Sent to OCC in Exec Broker field. |
| ExecId | 44 | 8 | Binary | Sent to the OCC in the Trade Id field. Execution Id. Unique across all matching units on a given day. Note: ExecIds will be represented on ODROP and FIXDROP ports as base 36 ASCII. |
| Side | 52 | 1 | Text | `1` = Buy `2` = Sell |
| Price | 53 | 8 | BinaryPrice | Limit price of the order. |
| Symbol | 61 | 8 | Alphanumeric | CFE native identifier of the instrument |
| MaturityDate | 69 | 4 | Date | Maturity date of the instrument |
| LastShares | 73 | 4 | Binary | Executed contracts quantity. |
| LastPx | 77 | 8 | BinaryPrice | Price of this fill. Note the use of Price type to represent positive and negative prices, which can occur with spread instruments. |
| FeeCode | 85 | 2 | Alphanumeric | Indicates fee associated with an execution. Fee codes are published in the pricing schedule. New fee codes may be sent with little or no notice. TPHs are encouraged to code their systems to accept unknown fee codes. |
| TradeDate | 87 | 4 | Date | Business date of the execution. Note that on CFE, business date is not always the same as the calendar date. For example, the VX/VT products open for trading on the calendar day prior to the associated business date. Executions that occur after the open and before midnight will have a TradeDate value that is not the same as the calendar date of the execution. |
| ClearingPrice | 91 | 8 | BinaryPrice | Price as sent to clearing after applying post-close conversions to the original LastPx value. |
| ClearingSymbol | 99 | 8 | Alphanumeric | Symbol as sent to clearing; after applying post-close conversions to the original Symbol. |
| MultilegReportingType | 107 | 1 | Text | Present on `Order Execution` and `TAS Restatement` messages representing either Spread orders or Simple orders that are part Spread execution. `1` = Simple instrument execution `2` = Simple instrument execution that is part of a Spread execution `3` = Spread instrument execution |
| SecondaryExecId | 108 | 8 | Binary | Indicates whether an execution is a spread or a simple instrument execution that is part of a spread trade. If SecondaryExecId field is not present, the execution is a simple instrument execution only. If SecondaryExecId is present and is the same as the ExecId required field, the execution represents a spread execution for which associated simple instrument executions will follow. Simple instrument executions associated with a spread execution will contain a SecondaryExecId value that matches the ExecId of the associated spread execution. |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

#### Quote Update Acknowledgement

`Quote Update Acknowledgment` messages are sent in response to a `Quote Update` or `Quote Update Option` message. The effect of each requested update will be found in this response. The ordering between request and response is preserved.

For quotes which are priced at an executable price and which may remove liquidity, a QuoteResult reason of `D` or `d` will be provided. In these cases, executions or cancellations (as needed) will immediately follow as additional messages. In some cases, an execution may not be permitted (e.g., risk management causes cancellation of the targeted order before execution), no additional messages will follow and the quote will post.

In some cases, a new OrderId will be assigned for an existing quote. There are currently two situations where this occurs, but others may be added in the future:

1. A quote which has received a large number of quote updates over its life will be assigned a new OrderId if receiving an update which would cause a loss in priority.
2. A quote update which has had an update to an attribute other than price or size.

If using the OrderId in your system or to correlate with an OrderId on PITCH, always be prepared to receive an update on a `Quote Update Acknowledgment`.

##### QuoteUpdateAcknowledgementUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | (43 + QuoteCnt*10) |
| MessageType | 4 | 2 | Binary | `EB 05` (1515) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | Always zero (unsequenced) |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| QuoteUpdateId | 20 | 16 | Text | Echoed back from the TPH message |
| RequestReceivedTime | 36 | 8 | DateTime | The earliest timestamp, populated with nanosecond precision, recorded by CFE of the corresponding inbound message being acknowledged. Populated with zero in event of failover to Port B or Port C. |
| QuoteCnt | 44 | 1 | Binary | Number of repeating groups included in this message. Allowed values are 1-20. |
| → OrderId | 45 | 8 | Binary | Order identifier supplied by CFE. This identifier corresponds to the identifiers used in CFE market data products. Sent to the OCC in the Exchange Data field. |
| → QuoteResult | 53 | 1 | Text | Result of the quote request. Acceptance: `A` = New Quote `L` = Modified; loss of priority `R` = Modified; retains priority (size reduction) `N` = No change, matches existing quote `D` = New Quote, but may remove liquidity `d` = Modified, but may remove liquidity Cancellation: `U` = User cancelled (zero size/price requested) Rejection: `a` = Admin `O` = Rejected, doesn’t match a known quote `P` = Rejected, can’t post f = Risk management EFID or Custom Group Id level `S` = Rejected, symbol not found `p` = Rejected, invalid price `s` = Risk management product root level `n` = Risk management configuration is insufficient `u` = Rejected, other reason |
| → SubLiquidityIndicator | 54 | 1 | Text | Additional information about the liquidity of an order. CFE may add additional values without notice. TPHs must gracefully ignore unknown values. NULL (0x00) = No Additional Information `C` = Carried Order Indicator `U` = Qualifying Market Turner order |

#### Quote Update Rejected

`Quote Update Rejected` messages are sent in response to a `Quote Update` or `Quote Update Option` message when the entire quote block is rejected by the order handler. No existing quotes are updated or cancelled as a result.

##### QuoteUpdateRejectedUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `23 00` (35) |
| MessageType | 4 | 2 | Binary | `EC 05` (1516) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | Always zero (unsequenced) |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| QuoteUpdateId | 20 | 16 | Text | Echoed back from the TPH message |
| QuoteRejectReason | 36 | 1 | Text | See Quote Reason Codes |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

#### Quote Restated

`Quote Restated` messages are sent to inform the TPH that an order has been asynchronously modified for some reason by CFE. Additional reasons may be added in the future.

In the case where an inbound quote will execute against a resting order or quote, then a `Quote Restated` message will be sent after the `Quote Update Acknowledgement` as a function of normal system behavior. These restatements will contain the RestatementReason of `Q` = Liquidity.

##### QuoteRestatedUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `3E 00` (62) |
| MessageType | 4 | 2 | Binary | `ED 05` (1517) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message. Distinct per Matching Unit |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| QuoteUpdateId | 20 | 16 | Text | Id chosen by the client. Characters in the ASCII range 33-126 are allowed, except for comma, semicolon, and pipe. All quote response messages will include this identifier. Note: CFE strongly recommends that QuoteUpdateId be kept unique for a trading day across both Futures and Options. |
| OrderId | 36 | 8 | Binary | Order identifier supplied by CFE. This identifier corresponds to the identifiers used in CFE market data products. Sent to the OCC in the Exchange Data field. |
| LeavesQty | 44 | 4 | Binary | Quantity still open for further execution. If zero, the order is complete. |
| WorkingPrice | 48 | 8 | BinaryPrice | The price at which the quote is working on the order book. |
| QuoteSymbol | 56 | 6 | Alphanumeric | CFE native identifier of the instrument being quoted. |
| Side | 62 | 1 | Text | `1` = Buy `2` = Sell |
| RestatementReason | 63 | 1 | Text | The reason for this Quote Restated message. `Q` = Liquidity `W` = Wash CFE reserves the right to add new values as necessary without prior notice. |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

#### Quote Execution

A `Quote Execution` message is used to indicate an execution has occurred on a resting quote.

##### QuoteExecutionUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `51 00` (81) |
| MessageType | 4 | 2 | Binary | `EE 05` (1518) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message. Distinct per Matching Unit |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| QuoteUpdateId | 20 | 16 | Text | Echoed back from the most recent Quote Update request for this quote. |
| OrderId | 36 | 8 | Binary | Order identifier supplied by CFE. This identifier corresponds to the identifiers used in CFE market data products. Sent to the OCC in the Exchange Data field. |
| ExecId | 44 | 8 | Binary | Sent to the OCC in the Trade Id field. Execution Id. Unique across all matching units on a given day. Note: ExecIds will be represented on ODROP and FIXDROP ports as base 36 ASCII. |
| QuoteSymbol | 52 | 6 | Alphanumeric | Echoed back from the TPH message |
| ClearingFirm | 58 | 4 | Alpha | EFID that will clear the trade. Port attribute value of 'Default EFID' is used if not provided. Sent to OCC in Exec Broker field. |
| LastShares | 62 | 4 | Binary | Executed contracts quantity. |
| LastPx | 66 | 8 | BinaryPrice | Price of this fill. Note the use of Price type to represent positive and negative prices, which can occur with spread instruments. |
| LeavesQty | 74 | 4 | Binary | Quantity still open for further execution. If zero, the order is complete. |
| Side | 78 | 1 | Text | Echoed back from the TPH message |
| BaseLiquidityIndicator | 79 | 1 | Text | Indicates whether the trade added or removed liquidity. `A` = Added Liquidity `R` = Removed Liquidity `C` = Market opening / re-opening trade |
| SubLiquidityIndicator | 80 | 1 | Text | Additional information about the liquidity of an order. CFE may add additional values without notice. TPHs must gracefully ignore unknown values. NULL (0x00) = No Additional Information `C` = Carried Order Indicator `U` = Qualifying Market Turner order |
| FeeCode | 81 | 2 | Alphanumeric | Indicates fee associated with an execution. Fee codes are published in the pricing schedule. New fee codes may be sent with little or no notice. TPHs are encouraged to code their systems to accept unknown fee codes. |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

#### Quote Cancelled

A `Quote Cancelled` message will be sent to indicate an unsolicited cancellation of a quote entered with a `Quote Update` message. An unsolicited cancellation is used, for example, when a resting quote is cancelled due to MTP with an inbound order or quotes are being cancelled due to a risk trip.

##### QuoteCancelledUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `32 00` (50) |
| MessageType | 4 | 2 | Binary | `EF 05` (1519) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message. Distinct per Matching Unit |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| QuoteUpdateId | 20 | 16 | Text | Echoed back from the most recent `Quote Update` request for this quote. |
| OrderId | 36 | 8 | Binary | Order identifier supplied by CFE. This identifier corresponds to the identifiers used in CFE market data products. Sent to the OCC in the Exchange Data field. |
| QuoteSymbol | 44 | 6 | Alphanumeric | CFE native identifier of the instrument being quoted. |
| Side | 50 | 1 | Text | `1` = Buy `2` = Sell |
| CancelReason | 51 | 1 | Text | See Order Reason Codes. |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

#### TAS Quote Restatement

A `TAS Quote Restatement` is sent post-settlement time for each TAS (VXT, VXMT) quote execution during the associated business day to communicate the updated Price and Symbol associated with the cleared execution. `TAS Quote Restatement` messages are sent shortly after the VX, VXMT contract settlement prices are disseminated (shortly after 3:15 p.m. CT).

##### TASQuoteRestatementUSFuturesV1

| Field Name | Offset | Length | Dta Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `40 00` (64) |
| MessageType | 4 | 2 | Binary | `F0 05` (1520) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message. Distinct per Matching Unit |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| QuoteUpdateId | 20 | 16 | Text | The quote being restated |
| ExecId | 36 | 8 | Binary | Sent to the OCC in the Trade Id field. Execution Id. Unique across all matching units on a given day. Note: ExecIds will be represented on ODROP and FIXDROP ports as base 36 ASCII. |
| QuoteSymbol | 44 | 6 | Alphanumeric | CFE native identifier of the instrument being quoted. |
| ClearingSymbol | 50 | 8 | Alphanumeric | Symbol as sent to clearing; after applying post-close conversions to the original Symbol. |
| ClearingPrice | 58 | 8 | BinaryPrice | Price as sent to clearing after applying post-close conversions to the original LastPx value. |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

#### Reset Risk Acknowledgement

Response to a `Reset Risk` request.

##### ResetRiskAcknowledgementUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `23 00` (35) |
| MessageType | 4 | 2 | Binary | `F2 05` (1522) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | Always zero (unsequenced) |
| RiskStatusId | 12 | 16 | Text | Unique identifier for this Reset Risk request. Response message will have this corresponding identifier. Note: CFE only enforces uniqueness of RiskStatusId values among currently unacknowledged requests. However, we strongly recommend that you keep your RiskStatusId values day-unique. |
| RiskResetResult | 28 | 1 | Text | <space> = Ignored; exceeds 1 reset per second `Y` = Success `F` = Rejected; exceeds firm reset limit `C` = Rejected; exceeds Custom Group Id limit `E` = Rejected; empty ResetRisk field `I` = Rejected; Incorrect data center `S` = Rejected; exceeds product level reset limit `U` = Rejected; invalid RiskRoot `c` = Rejected; invalid EFID/ClearingFirm `y` = Rejected; in replay Additional reject values may be added in the future without notice. |
| RequestReceivedTime | 29 | 8 | DateTime | The earliest timestamp, populated with nanosecond precision, recorded by CFE of the corresponding inbound message being acknowledged. Populated with zero in event of failover to Port B or Port C. |

(New fields may be introduced at the end of this message. Consequently, TPHs must treat any additional bytes present as undefined values.)

#### New Complex Instrument Accepted (Options Only)

The `New Complex Instrument Accepted` message indicates acceptance of a complex strategy. The leg order sent back may differ from the originating request. The TPH can compare the leg order against the original request to determine if the leg order has been altered.

##### NewComplexInstrumentAcceptedOptionUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | (51 + LegCnt * 29) |
| MessageType | 4 | 2 | Binary | `F6 05` (1526) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message. Distinct per Matching Unit |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| ClOrdId | 20 | 20 | Text | Echoed back from the TPH message |
| Symbol | 40 | 8 | Alphanumeric | The complex instrument id. |
| NoOfComplexInstruments | 48 | 4 | Binary | The number of complex instruments created by the TPH in the underlying futures symbol in the current trading session. |
| LegCnt | 52 | 1 | Binary | Number of legs in this complex instrument. |
| → LegSymbol | 53 | 8 | Alphanumeric | The symbol id for the Simple Options on Futures Instrument. |
| → SecurityDesc | 61 | 16 | Text | Options on futures name that refers to the option underlying futures contract, option put/call, options strike price (two implied decimals), and option expiration date (e.g. “UX1A/K4 C2000”). |
| → LegRatioQty | 77 | 4 | Binary | Ratio of number of contracts in this leg per order quantity. |
| → LegSide | 81 | 1 | Text | `1` = Buy `2` = Sell |

#### New Complex Instrument Rejected (Options Only)

The `New Complex Instrument Rejected` indicates that a requested complex strategy has been rejected. `New Complex Instrument Rejected` messages are unsequenced.

##### NewComplexInstrumentRejectedOptionUSFuturesV1

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `B0 E3` (58288) |
| MessageLength | 2 | 2 | Binary | `69 00` (103) |
| MessageType | 4 | 2 | Binary | `F7 05` (1527) |
| MatchingUnit | 6 | 1 | Binary | Matching Unit which created this message. |
| Reserved | 7 | 1 | Binary | Unspecified |
| SequenceNumber | 8 | 4 | Binary | Always zero (unsequenced) |
| TransactionTime | 12 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| ClOrdId | 20 | 20 | Text | Echoed back from the TPH message |
| ClearingFirm | 40 | 4 | Alphanumeric | Echoed back from the TPH message |
| RejectReason | 44 | 1 | Text | See Order Reason Codes. |
| Text | 45 | 60 | Text | Human readable text with more information. |

### Application Message Fields

**Table 1. Application Message Fields**

| Field Name | FIX Field Name | Length | Type | Description |
|---|---|---|---|---|
| Account | 1 | 16 | Alphanumeric | Unique account identifier associated with an order. This field will be reflected back on execution reports associated with this order. The first 10 characters are sent to the OCC in the Account # field. The entire 16 character string will appear in the optional CM Data field. Valid characters include ASCII 32-126. |
| BaseLiquidityIndicator | 9730 | 1 | Alphanumeric | Indicates whether the trade added or removed liquidity. `A` = Added Liquidity `R` = Removed Liquidity `C` = Market opening / re-opening trade |
| CancelledOrderCount | 7696 | 4 | Binary | Number of orders cancelled. |
| CancelOrigOnReject | 9619 | 1 | Alpha | `N` = Leave original order alone. `Y` = Cancel original order if modification fails. |
| CancelReason | 58* | 1 | Text | See Order Reason Codes. |
| CancelRejectReason | 58* | 1 | Text | See Order Reason Codes. |
| Capacity | 47 | 1 | Alphanumeric | `C` = Customer `F` = Firm The Capacity refers to the OCC account type. A value of "C" denotes an account that clears in the Customer range at OCC. A value of "F" denotes an account that clears in the Clearing Firm range at OCC. |
| ClearingAccount | 440 | 4 | Text | Supplemental identifier. Recorded and made available in execution reports. Available via Drop feeds. This field can be blank or populated with an optional four character string, except for comma, semicolon, and pipe . This field is not sent to the OCC. |
| ClearingFirm | 115 | 4 | Alpha | EFID that will clear the trade. Port attribute value of ‘Default EFID’ is used if not provided. Sent to OCC in Exec Broker field. |
| ClearingPrice | 21050 | 8 | BinaryPrice | Price as sent to clearing after applying post-close conversions to the original LastPx value. |
| ClearingSize | 21051 | 4 | Binary | Size to clear with OCC. Same value as LastShares, except in VA and VAO where ClearingSize is 0 on execution, and the converted clearing size on restatement. |
| ClearingSymbol | 21053 | 8 | Alphanumeric | Symbol as sent to clearing; after applying post-close conversions to the original Symbol. |
| ClOrdId | 11 | 20 | Text | Unique Id chosen by the client. Characters in the ASCII range 33-126 are allowed, except for comma, semicolon, and pipe . If the ClOrdId matches a live order, the order will be rejected as duplicate. A leading tilde (~) cannot be sent on any ClOrdId and will result in a reject. These are reserved for internal use by CFE and could be received as a result of a CFE-generated ClordId . Sent to the OCC in the OrderId field. Note: CFE only enforces uniqueness of ClOrdId values among currently live orders, which includes long-lived GTC and GTD orders. However, using unique ClOrdId values is strongly recommend. |
| CMTANumber | 439 | 4 | Binary | CMTA Number of the firm that will clear the trade. Must be specified for CMTA orders and left unspecified for non-CMTA orders. Sent to the OCC in the CMTA CM# field. |
| CorrectedPrice | 9620 | 8 | BinaryPrice | For trade corrections, this is the new trade price. For trade breaks, this is set to 0. |
| CustomGroupID | 7699 | 2 | Binary | Used to group orders for use in mass cancels where multiple orders can be cancelled by specifying a list of CustomGroupIds. A zero value is treated as "no CustomGroupIds". |
| CtiCode | 9702 | 1 | Alphanumeric | Valid values: 1, 2, 3, 4 `1` = CTI 1: Transactions initiated and executed by an individual TPH for the TPH’s own account, for an account the TPH controls, or for the account in which the TPH has an ownership or financial interest. `2` = CTI 2: Transactions executed for the proprietary account of a clearing TPH or non-clearing TPH. `3` = CTI 3: Transactions where an individual TPH or authorized trader executes for the personal account of another individual TPH, for an account the other individual TPH controls or for an account in which the other individual TPH has an ownership or financial interest. `4` = CTI 4: Any transaction not meeting the definition of CTI 1, 2 or 3. (These should be non-TPH customer transactions). |
| CustomGroupIdCnt | 7698 | 1 | Binary | Number of repeating CustomGroupId’s included in this message. |
| CustOrderHandlingInst | 1031 | 1 | Alphanumeric | Execution source code provided during order entry to describe broker service. A default value can be set using the ‘Default Customer Order Handling Instruction’ port attribute. `W` = Desk (high touch) `Y` = Electronic `C` = Vendor-provided platform, billed by Executing Broker `G` = Sponsored Access via Exchange API or FIX, provided by executing broker `H` = Premium algorithmic trading provider, billed by executing broker `D` = Other, including other-provided screen NUL (0x00) = Apply port default (initially 'Y') |
| ExecId | 17 | 8 | Binary | Sent to the OCC in the Trade Id field. Execution Id. Unique across all matching units on a given day. Note: ExecIds will be represented on ODROP and FIXDROP ports as base 36 ASCII. * |
| ExecRefId | 19 | 8 | Binary | Refers to the ExecId of the fill being cancelled or corrected. |
| ExpireTime | 424 | 8 | DateTime | Required for TimeInForce = 6 orders, specifies the date-time (in UTC) that the order expires. |
| FeeCode | 9882 | 2 | Alphanumeric | Indicates fee associated with an execution. Fee codes are published in the pricing schedule. New fee codes may be sent with little or no notice. TPHs are encouraged to code their systems to accept unknown fee codes. |
| FrequentTraderId | 21097 | 6 | Alphanumeric | Supplemental customer identifier used for billing related programs. |
| LastPx | 31 | 8 | BinaryPrice | Price of this fill. Note the use of Price type to represent positive and negative prices, which can occur with spread instruments. |
| LastShares | 32 | 4 | Binary | Executed contracts quantity. |
| LeavesQty | 151 | 4 | Binary | Quantity still open for further execution. If zero, the order is complete. |
| LegCnt | 555 | 1 | Binary | For complex orders, the number of legs of the complex instrument specified in the Symbol field. For simple orders, this should be set to zero and the OpenClose field should be used. |
| LegPositionEffect | 564 | 1 | Text | Indicates status of client position in the option for this leg. `O` = Open `C` = Close `N` = None |
| LegRatioQty | 623 | 4 | Binary | Ratio of number of contracts in this leg per order quantity. Accepted values are 1-99,999 |
| LegSide | 624 | 1 | Text | `1` = Buy `2` = Sell |
| LegSymbol | 600 | 8 | Alphanumeric | The symbol id for the Simple Options on Futures instrument. |
| ManualOrderIndicator | 1028 | 1 | Alpha | `Y` = Manual order entry `N` = Automated order entry |
| MassCancelId | 7695 | 20 | Text | User-defined identifier of the mass cancel or purge request. |
| MassCancelInst | 7700 | 16 | Text | Corresponds to MassCancelInst (7700) in CFE FIX. Used for specification of `Purge Orders` functionality and optionally used for specification of Mass Cancel functionality associated with the `Cancel Order` message. At least one character must be provided (Clearing Firm Filter). Contiguous characters must be specified up to total length. Truncated/unspecified characters will default to values indicated (D) below. 1 st Character : Clearing Firm Filter `A` = No filtering by clearing firm relationship is performed. `F` = All orders that were sent under the clearing relationship specified in ClearingFirm optional field. If "F" specified and ClearingFirm not provided, the Mass Cancel or Purge request will be rejected. 2 nd Character : Acknowledgement Style `M` = (D) Order Cancelled messages are sent for each cancelled order. If "M" is set, any MassCancelId value is ignored. `S` = A single Mass Cancel Acknowledgement message is sent once all cancels have been processed. The MassCancelId optional field must be specified or the Mass Cancel or Purge Request will be rejected. `B` = Both individual Order Cancelled and Mass Cancel Acknowledgement messages will be sent. Also requires MassCancelId optional field to be specified or the Mass Cancel or Purge request will be rejected. 3 rd Character : Lockout Instruction `N` = (D) No lockout `L` = Lockout until corresponding Reset Risk received. Lockout can be used only with Clearing Firm Filter set to "F", otherwise the Mass Cancel or Purge request will be rejected. Lockout will apply to all New Order, Quote Update, and Modify Order messages for the ClearingFirm (and ProductName or CustomGroupIds , if specified), regardless of other filtering in the Purge Orders or Cancel Order message. 4 th Character : Instrument Type Filter `B` = (D) Cancel both Simple and Complex orders `S` = Cancel Simple orders only `C` = Cancel Spread orders only 5 th Character : GTC Order Filter `C` = (D) Cancel GTC and GTD orders `P` = Don’t cancel (preserve) GTC and GTD orders 6 th Character : Security Type `F` = Cancel orders (Futures only) `O` = Cancel orders (Options only) `A` = (D) Cancel All Futures and Options orders If ProductName optional field is specified, it must contain a valid futures root symbol (e.g., "VX"), in which case only orders/quotes associated with the specified product will be cancelled. A self-imposed lockout can be released using the `Reset Risk` message. An appropriate reset is required to be sent for each lockout type in order to resume trading. For example, a product-level lockout requires a product-level reset. For more information, refer to the Cboe Titanium Cboe Futures Exchange Risk Management Specification . |
| MassCancelRejectReason | 58* | 1 | Text | Reason for the mass cancel rejection. See Order Reason Codes. |
| MaturityDate | 200, 205 | 4 | Date | When specifying the Symbol for a `New Order` message the user can specify the mapped symbol identifier in the Symbol field. Alternatively, the product class (e.g., "VX", "VXT", etc.) can be supplied for the Symbol field and the MaturityDate field is used to specify the expiration date of the symbol within the specified product class. If a value is provided for MaturityDate , the Symbol field must correspond to a valid product or the order will be rejected with reason code C (Unknown Product Name). If an invalid MaturityDate is provided, the order will be rejected with reason code B (Unknown Maturity Date). |
| MinQty | 110 | 4 | Binary | Minimum fill quantity for IOC orders. Ignored for other Simple instrument orders. Not supported for Spread instruments. Spread instrument orders with specified MinQty will be rejected. |
| ModifyRejectReason | 103 | 1 | Text | See Order Reason Codes. |
| MultilegReportingType | 442 | 1 | Text | Present on `Order Execution` and `TAS Restatement` messages representing either Spread orders or Simple orders that are part Spread execution. `1` = Simple instrument execution `2` = Simple instrument execution that is part of a Spread execution `3` = Spread instrument execution |
| OEOID | 25004 | 1 | Alphanumeric | Identifies the Order Entry Operator responsible for this message. Min length 3, max length 18. Values in ASCII range 33-126 except comma, semicolon, and pipe are permissible. |
| OpenClose | 77 | 1 | Alphanumeric | Indicates status of client position in a trade resulting from the order. `O` = Open `C` = Close `N` = None NUL (0x00) = None |
| OrderId | 37 | 8 | Binary | Order identifier supplied by CFE. This identifier corresponds to the identifiers used in CFE market data products. Sent to the OCC in the Exchange Data field. |
| OrderQty | 31 |  | Binary | Order quantity. System limit is 999,999 contracts. |
| OrderRejectReason | 103 | 1 | Text | See Order Reason Codes. |
| OrdType | 40 | 1 | Alphanumeric | `1` = Market `2` = Limit (default) `4` = Stop Limit (Futures only) Market implies TimeInForce of IOC (3). Stop Limit orders must have a TimeInForce of DAY (0), GTC (1), or GTD (6). |
| OrigClOrdId | 41 | 20 | Text | The ClOrdId of the original order. |
| OrigTime | 42 | 8 | DateTime | The date and time of the original trade, in GMT. |
| PendingStatus |  | 1 | Text | Field is provided as a convenience to determine whether an `Order Execution` message is a preliminary notification representing a pending trade. The value ‘P’ indicates that the execution is associated with a product for which the `Order Execution` message is a preliminary notification of an execution and for which a post-settlement restatement will be sent. `N` = Not applicable `P` = Pending |
| PreventMatch | 7928 | 3 | Alpha | Three characters: 1 st character - MTP Modifier: `N` = Cancel Newest `O` = Cancel Oldest `B` = Cancel Both 2 nd character - Unique Id Level: `F` = Prevent Match at Firm (TPH) Level `M` = Prevent Match at EFID Level `N` = None (do not prevent match at any level) 3 rd character - Trading Group Id (optional): TPH specified alphanumeric value 0-9, A-Z, or a-z. The unique Id level (character 2) of both orders must match to prevent a trade. If specified on both orders, Trading Group Id (character 3) must match to prevent a trade. Note that in the event of a Spread order match with a Simple order, the Spread order will always be cancelled irrespective of the 1 st character value. On New Orders, an empty PreventMatch string (NUL filled) results in default Port Attribute settings applied. |
| Price | 44 | 8 | BinaryPrice | Limit price. Four implied decimal places. Required for limit orders ( OrdType = 2). If specified on market order ( OrdType = 1), the order will be rejected. Orders will be rejected if Price does not fall on the applicable minimum trading increment. For all contracts other than Trade at Settlement contracts, simple orders will be rejected if Price is less than or equal to zero, or greater than or equal to 100,000. For Trade at Settlement (TAS) contracts, simple orders will be rejected if Price is outside the price limits presented in the contract specification. Spread orders will be rejected if Price is outside the price limits implied by the spread instrument definition and constituent instrument min and max prices. |
| ProductName | 55 | 6 | Text | Used to specify product class (e.g., "VX", "VA", etc.) for `Purge Orders` and `Cancel Order` message cancel by product functionality. If an unrecognized ProductName is provided, the associated request will be rejected with reason code C (Unknown Product Name). |
| PurgeRejectReason | 58* | 1 | Text | Reason for the purge rejection. See Order Reason Codes |
| QuoteCnt | n/a | 1 | Binary | Number of repeating groups included in this message. Allowed values are 1-20. |
| QuoteRejectReason | n/a | 1 | Text | See Section Quote Reason Codes |
| QuoteResult | n/a | 1 | Text | Result of the quote request. Acceptance: `A` = New Quote `L` = Modified; loss of priority `R` = Modified; retains priority (size reduction) `N` = No change, matches existing quote `D` = New Quote, but may remove liquidity `d` = Modified, but may remove liquidity Cancellation: `U` = User cancelled (zero size/price requested) Rejection: `a` = Admin `O` = Rejected, doesn’t match a known quote `P` = Rejected, can’t post `f` = Risk management EFID or Custom Group Id level `S` = Rejected, symbol not found `p` = Rejected, invalid price `s` = Risk management product root level `n` = Risk management configuration is insuffcient `u` = Rejected, other reason |
| QuoteSymbol | 55 | 6 | Alphanumeric | CFE native identifier of the instrument being quoted. |
| QuoteUpdateId | n/a | 1 | Text | Id chosen by the client. Characters in the ASCII range 33-126 are allowed, except for comma, semicolon, and pipe. All quote response messages will include this identifier. Note: CFE strongly recommends that QuoteUpdateId be kept unique for a trading day across both Futures and Options. |
| RequestReceivedTime | n/a | 8 | DateTime | The earliest timestamp, populated with nanosecond precision, recorded by CFE of the corresponding inbound message being acknowledged. Populated with zero in event of failover to Port B or Port C. |
| RestatementReason | n/a | 1 | Text | The reason for this Quote Restated message. `Q` = Liquidity `W` = Wash CFE reserves the right to add new values as necessary without prior notice. |
| RiskStatusId |  | 16 | Text | Unique identifier for this Reset Risk request. Response message will have this corresponding identifier. Note: CFE only enforces uniqueness of RiskStatusId values among currently unacknowledged requests. However, we strongly recommend that you keep your RiskStatusId values day-unique. |
| RiskReset | 7692 | 8 | Text | Single Character Values (Values may be combined) `S` = Product-level risk/lockout reset (Futures only) `F` = Firm-level risk/lockout reset (Futures only) `C` = CustomGroupId lockout reset (Futures only) `R` = Product-level risk/lockout reset (Options only) `I` = Firm-level risk/lockout reset (Options only) `D` = CustomGroupId lockout reset (Options only) Values may be combined together to allow for resets of multiple risk trips or self-imposed lockouts in a single message. For example, "FS", "SC", "FC", and "SFC" are all acceptable values. The characters may be combined in any order. For example, to "reset all futures", set this field to ‘SFC’, which is the equivalent to ‘CFS’. To "reset all options", set this field to ‘RID’, which is equivalent to ‘DIR’. To "reset all futures and options" set the field to ‘SFCRID’, which is equivalent to ‘DIRCFS’. For more information, refer to the Cboe Titanium Cboe Futures Exchange Risk Management Specification . |
| RiskResetResult | n/a | 1 | Text | <space> = Ignored; exceeds 1 reset per second `Y` = Success `F` = Rejected; exceeds firm reset limit `C` = Rejected; exceeds Custom Group Id limit `E` = Rejected; empty ResetRisk field `I` = Rejected; Incorrect data center `S` = Rejected; exceeds product level reset limit `U` = Rejected; invalid RiskRoot `c` = Rejected; invalid EFID/ClearingFirm `y` = Rejected; in replay Additional reject values may be added in the future without notice. |
| SecondaryExecId | 527 | 8 | Binary | Indicates whether an execution is a spread or a simple instrument execution that is part of a spread trade. If SecondaryExecId field is not present, the execution is a simple instrument execution only. If SecondaryExecId is present and is the same as the ExecId required field, the execution represents a spread execution for which associated simple instrument executions will follow. Simple instrument executions associated with a spread execution will contain a SecondaryExecId value that matches the ExecId of the associated spread execution. |
| Side | 54 | 1 | Text | `1` = Buy `2` = Sell |
| SizeModifier |  | 1 | Text | Controls the behavior of the quote OrderQty field. Using "R" allows for a TPH to ensure that in-flight fills or cancels do not result in unwanted additional size exposure. NULL (0x00) = New quote size will be set to value of OrderQty . `R` = Reduce outstanding size of quote by the OrderQty provided. When using "R", if the resulting size is zero or negative, then the quote is cancelled. TPHs are expected to track the remaining quantity of each quote as resulting size is not included on the `Quote Update Acknowledgement` message. |
| StopPx | 8 | 99 | BinaryPrice | Stop price. Required if OrdType = 4 (Stop Limit). Stop Limit orders will only be triggered off Last Sale Eligible trades. |
| SubLiquidityIndicator | 9730* | 1 | Text | Additional information about the liquidity of an order. CFE may add additional values without notice. TPHs must gracefully ignore unknown values. NULL (0x00) = No Additional Information `C` = Carried Order Indicator `U` = Qualifying Market Turner order |
| Symbol | 55 | 8 | Alphanumeric | Simple Instruments can be specified by providing the mapped symbol format in the Symbol field or by providing the product name (e.g., "VX") in the Symbol field and maturity date in the MaturityDate field. Responses to the TPH will contain the instrument specification in the manner that was provided on the associated new order specification (e.g., either Symbol Id or Product and MaturityDate). The Symbol field for Spread instrument related messages will always contain mapped symbol Id as product and maturity date does not completely specify the Spread instrument. |
| Text | 58 | 60 | Text | Human readable text with more information. |
| TimeInForce | 59 | 1 | Text | `0` = Day (Expires at the end of the business day). `1` = GTC (Good ‘till Cancel. Order remains until cancelled or contract expires). `3` = IOC (Portion not filled immediately is cancelled. Market orders are implicitly IOC). `4` = FOK (An IOC where the entire size must be filled, else the order will be cancelled back). `6` = GTD (Good ‘till Date-Time Expires at the date-time specified in the ExpireTime field). |
| TradeDate | 75 | 4 | Date | Business date of the execution. Note that on CFE, business date is not always the same as the calendar date. For example, the VX/VT products open for trading on the calendar day prior to the associated business date. Executions that occur after the open and before midnight will have a TradeDate value that is not the same as the calendar date of the execution. |
| TransactionTime | 60 | 8 | DateTime | The time the event occurred in the CFE Matching Engine (not the time the message was sent). |
| WorkingPrice | n/a | 8 | BinaryPrice | The price at which the quote is working on the order book. |
| CountryCode |  | 2 | Text | Identifies the country code of the person or system submitting the order using the ISO 3166 two-character code (must be entered using uppercase letters only). An order with a country code for a comprehensively sanctioned country will be rejected. |

**Table 2. Application Message Fields Example Conversion**

| Decimal | Base 36 |
|---|---|
| 28294005440239 | A1234B567 |
| 76335905726621 | R248BC23H |
| 728557228187 | 09AP05V2Z |

## Reason Codes

### Order Reason Codes

The following is a list of all reason codes used by CFE. These reason codes are used in a variety of contexts (order cancellations and order rejections). All reasons are not valid in all contexts. The reason code will be followed by free-form text. The specific text the system delivers may vary from the text listed below to provide clarification of the reject reason. CFE may add additional reason codes without notice. Members must gracefully ignore unknown values.

| Code | Description |
|---|---|
| A | Admin |
| B | Unknown maturity date |
| C | Unknown product name |
| D | Duplicate identifier (e.g., ClOrdId) |
| H | Halted |
| I | Incorrect data center |
| K | Order rate threshold exceeded |
| M | Liquidity available exceeds order size |
| N | Ran out of liquidity to execute against |
| O | ClOrdId doesn’t match a known order |
| P | Can’t modify an order that is pending |
| U | User requested |
| V | Would wash |
| X | Order expired |
| Y | Symbol not supported |
| Z | Unforeseen reason |
| c | Only Close transactions accepted |
| f | Risk management EFID level or custom group Id level |
| h | Order persisted |
| m | Market access risk limit exceeded |
| n | Risk management configuration is insufficient |
| o | Max open orders count exceeded |
| s | Risk management product level |
| u | Limit Up Limit Down (LULD) |
| y | Order received by CFE during replay |
| z | Session end |

### Quote Reason Codes

The following is a list of all quote reason codes used by CFE. All reasons are not valid in all contexts. The reason code will be followed by free-form text. The specific text the system delivers may vary from the text listed below to provide clarification of the reject reason. CFE may add additional reason codes without notice. Members must gracefully ignore unknown values.

| Code | Description |
|---|---|
| C | Invalid EFID (ClearingFirm) |
| D | Invalid WashId |
| F | Not enabled for quotes |
| I | Incorrect data center |
| K | Message rate threshold |
| L | Invalid QuoteCnt |
| M | Symbols not on same matching engine |
| O | Invalid ManualOrderIndicator |
| Q | Invalid QuoteUpdateId |
| R | Futures root does not match across quotes |
| S | Symbol not found |
| U | Symbol range unreachable |
| W | Invalid WashPreventType |
| a | Admin |
| c | Invalid Capacity |
| d | Close Only |
| e | Invalid OEOID (Order Entry Operator ID) |
| f | Risk management EFID or Custom Group Id level |
| i | Invalid CtiCode |
| m | Invalid WashMethod |
| n | Exceeds max notional value per order |
| o | Invalid Open/Close |
| r | Invalid Remove |
| s | Invalid Side |
| u | Limit Up Limit Down (LULD) |
| x | Exceeds max size per order |
| y | Quote received by CFE during replay |
| z | Invalid SizeModifier |

## Port Attributes

| Attribute | Default | Description |
|---|---|---|
| Allowed Executing Firm Id(s) | All EFIDs | Executing Firm Id(s) allowed for trading on the port. |
| Default Executing Firm Id | None | Default Executing Firm Id to use if none is sent on a `New Order` or `Quote Update`. |
| Cancel on Disconnect | All | Cancels open orders upon order handler disconnect; both graceful and ungraceful. Cancel on Disconnect behavior is in effect from the time persisted orders are reloaded to the book to the end of the cancel-only period. `All` = Cancel Day, GTC, and GTD orders `Day` = Cancel only Day orders `None` = Disabled BOE Unit Quoting ports require Cancel on Disconnect set to All or Day. Default will be used if not specified. |
| Cancel on Reject1, 3 | No | Cancels an order upon a modify reject for that order. |
| Cancel on ME Disconnect | All | Controls whether orders are cancelled or preserved on a Matching Unit failover and provides for the ability to preserve GTC orders (Day). In any event, if a failover takes longer than 5 minutes, all orders are cancelled (including GTCs). `All` = Cancel Day, GTC, and GTD orders `Day` = Cancel only Day orders `None` = Disabled BOE Unit Quoting ports require Cancel on Disconnect set to All or Day. Default will be used if not specified. |
| Cancel Open Orders on DROP Port Disconnect | No | Only applicable if "Reject Orders on DROP Port Disconnect" has been enabled. When the last Standard FIX DROP port associated with an order handler session has disconnected, open orders, associated with the session are cancelled. `All` = Cancel Day, GTC, and GTD orders `Day` = Cancel only Day orders `None` = Disabled Note this parameter applies to Standard FIX DROP ports and not Order-By-Order DROP ports (ODROP). |
| Carried Order Restatements | Yes | If the Carried Order Restatements port attribute is set, `Order Acknowledgement` messages representing orders carried forward from the previous business date will be sent after the `Login Response` message and before regular session messages for each product. See Carried Order and Quote Restatements for a detailed description of Carried Order Restatements. Carried Order Restatements are required and cannot be disabled on order and quote updates submitted to the CFE system over a BOEv3 session which has been enabled for Quote Updates. Note that any changes made to any port attribute will not be enforced on carried GTC orders. Members who wish to apply updated port attributes to resting GTC orders must cancel those orders, and then resubmit them following the effective time of the port attribute change. |
| Default MTP Value† | None | Specifies default value for PreventMatch. |
| Default Customer Order Handling Instruction | `Y` = Electronic | Sets a default CustOrderHandlingInst (1031) that will be used unless overridden at the individual order level. `W` = Desk (high touch) `Y` = Electronic (default) `C` = Vendor-provided platform, billed by Executing Broker `G` = Sponsored Access via Exchange API or FIX, provided by executing broker `H` = Premium algorithmic trading provider, billed by executing broker `D` = Other, including other-provided screen |
| Maximum Order Size | 25,000 contracts | A system-wide maximum order size limit that is set by the CFE. TPHs may not request a change to this port attribute. |
| Multi-Segment Holiday Day Order Handling | None | Controls whether Day ( TimeInForce (59) = 0 ) orders and quotes are cancelled or preserved across holiday trading segments comprising a single business date. `None` = All Day orders and quotes on the book are carried between trading segments `Cancel` = All Day orders and quotes on the book at the conclusion of the current trading segment are cancelled back |
| Reject Orders on DROP Port Disconnect | No | Allows TPH/Sponsoring Firms to associate DROP port(s) to order entry port(s). If all associated DROP ports experience disconnection, new orders will be rejected until at least one DROP port session has been reestablished. |
| Reject Orders on DROP Port Timeout(s) | 30 seconds | Only applicable if "Reject Orders on DROP Port Disconnect" has been enabled. When the last associated DROP port has disconnected, begin rejecting orders on the associated order entry port(s) if a DROP session has not been reestablished within this timeout. Minimum value allowed is 0 seconds. |
| Port Message Rate Threshold | `Default and Max allowed` = 3,000 msgs/sec for order ports, 10,000 for quote ports. 1 msg/sec for CFE test products. | The maximum allowed message rate on the session. When the first non-administrative message is received, a one second window begins. For example, on an order port during a second no more than 2,999 additional non-administrative messages will be allowed within that window. If the rate is exceeded all new orders in the time window are rejected, modifies are treated as cancels, and cancels are processed. Unit Quote ports will have a default limit of 10,000 messages per second. A message is defined as any individual quote or any order-related message (new, modify, or cancel). If the limit is exceeded on a quote port the behavior for orders described above applies, and all `Quote Update` messages will be rejected unless the `Quote Update` message contains only cancels. |
| quote_country | US | When enabled, the country code on `Quote Update` messages will default to the TPH-specified country code using the ISO 3166 two-character code list (must be entered using uppercase letters only). A `Quote Update` message with a country code for a comprehensively sanctioned country will be rejected. |

* Not available for quotes.

† Port attributes can be overridden on an order-by-order basis

2 Requires certification

3 Not applicable for quotes

## Support

Please direct questions or comments regarding this specification to cfetradedesk@cboe.com.

## Architectural Diagrams

The following architectural diagram is provided to assist TPHs in understanding how messages flow through the CFE system using BOEv3. The lines in the diagrams indicate message flow only and are not intended to accurately depict physical cabling distances. All physical customer connections are latency equalized and internal physical connections use equidistant cable lengths.

A.1 Current Architecture

_(Figure)_

_(Figure)_

## Revision History

| Document Version | Date | Description |
|---|---|---|
| 1.0.0 | 02/04/2021 | Initial version for publication. |
| 1.0.1 | 02/22/2021 | Corrected section 1.4.6.3 to indicate that BOE Unit Purge Ports support both `Purge Orders` and `Risk Reset` message types. |
| 1.0.2 | 03/03/21 | Corrected description for MessageLength on `Login Request` message. Corrected offsets on `Quote Update` message. Added ClearingFirm field to `TAS Restatement` message. Populated Side field offset value on `Variance Restatement` message. |
| 1.0.3 | 03/11/21 | Added ‘n’ rejection in QuoteResult field. |
| 1.0.4 | 04/22/21 | Updated section 1.1.1 with item 14 which identifies BOEv3 requirement for non-zero sequence numbers for sequenced messages sent from TPH to CFE. Corrected section 5.1 by removing 'J' from Order Reason Code list as this value was included in error. Corrected section 5.2 to indicate value for Invalid CtiCode is 'i'. |
| 1.0.5 | 05/10/21 | Clarified language around overlapping modifies in the Modify Order section. Additional language added to describe that RequestReceivedTime will be zero in failover scenarios. Fixed numbering of Appendix sections. |
| 1.0.6 | 05/21/21 | Updated OpenClose and CustOrderHandlingInst field descriptions to address treatment of NUL value. |
| 1.0.7 | 07/12/21 | Matching Unit field on inbound messages to Cboe may be value other than zero. It may also be value of the correct matching unit. |
| 1.0.8 | 12/06/21 | Added CountryCode field to `NewOrderUSFuturesV2` messages to identify the country code of the person or system submitting the order using the ISO 3166 two-character code (available 01/23/22). Added a new Port Attribute "quote_country" (effective 02/27/22). Added sunset date to `NewOrderUSFuturesV1` messages (sunset 02/27/22). |
| 1.0.9 | 01/21/22 | Noted that CFE strongly recommends that QuoteUpdateId be kept unique for a trading day. Removed 'unsequenced' verbiage MessageLength and Sequence Number Message Header descriptions. Updated PreventMatch description to indicate that `N` = None (do not prevent match at any level) and that "On New Orders, an empty PreventMatch string (NUL filled) results in default Port Attribute settings applied." Updated PreventMatch description in OrderAcknowledgementUSFuturesV1 messages to clarify that "PreventMatch as accepted by CBOE." Added MatchingUnit field on CFE to TPH messages. |
| 1.0.10 | 02/28/22 | Updated `Cancel Order` messages verbage to `Mass Cancel Order` messages in section 4.1.5. Noted that for executions involving Spread orders, if both sides of a complex/spread trade are on the same order entry session, Cboe does not guarantee that the leg executions will not be interleaved between sides. |
| 1.0.11 | 03/21/22 | Noted that an order or `Quote Update` message with a country code for a comprehensively sanctioned country will be rejected. |
| 1.0.12 | 05/26/22 | Updated ClearingAccount field to clarify that the field can be populated with an optional four character string, except for comma, semicolon, and pipe. Updated ZVXT Test Product Pre-Open period and maximum number of inbound messages per second on BOE Unit Order Ports for CFE Test Products (effective 06/12/22). Noted the number of allowed GTC/GTD orders in test classes is three per session per matching unit (effective 06/12/22). |
| 1.0.13 | 06/16/22 | Carried Order Restatements port attribute is not configurable on BOEv3 sessions enabled for `Quote Update` messages. Appendix A: Architectural Diagrams cleaned up to reflect sunset of BOEv3 protocol. Added Section 1.3 - Holiday Sessions to provide submission timeframes and session disconnect information for holidays. |
| 1.1.0 | 07/29/22 | Major updates to introduce Options on Futures (effective 07/10/23 04/03/23 ). Re-certification required before TPHs may trade options on the CFE platform (effective 07/10/23 04/03/23 ). |
| 1.1.1 | 08/10/22 | Updated `OrderAcknowledgementOptionUSFuturesV1` MessageLength field description. Clarified `TBD` = Exceeds max notional value per order and `U` = Symbol range unreachable (effective 07/10/23 04/03/23 ). |
| 1.1.2 | 09/09/22 | Updated MessageLength in the `Example Login Request` message. Updated `NewOrderOptionUSFuturesV1` and `OrderAcknowledgementOptionUSFuturesV1` MessageLength field description. Added LegCnt and LegPositionEffect fields to `NewOrderOptionUSFuturesV1` , `OrderAcknowledgementOptionUSFuturesV1` , and section 4.3 (effective 07/10/23 04/03/23 ). Updated `CancelRejectedUSFuturesV1` SequenceNumber field description. Clarified RiskReset description to indicate `R` = Product-level risk/lockout reset and `I` = Firm-level risk/lockout reset (Options only) (effective 07/10/23 04/03/23 ). |
| 1.1.3 | 10/31/22 | Updated `NewOrderOptionUSFuturesV1` Symbol and SecurityDesc descriptions. |
| 1.1.4 | 11/14/22 | Removed "10 msg/sec for CFE test products" statement from the Threshold port attribute. |
| 1.1.5 | 11/16/22 | Removed duplicate sentence. |
| 1.1.6 | 01/19/23 | Updated effective date for Options on Futures (effective 07/10/23). |
| 1.1.7 | 05/08/23 | Updated reject text for persisted orders attempting to be canceled outside of trading hours to more accurately reflect when an order is known but the request is not currently being accepted (effective 05/21/23). |
| 1.1.8 | 06/08/23 | OrdType = `Stop Limit` will not be allowed for Options on Futures orders (effective 07/10/23). |
| 1.1.9 | 06/15/23 | Spaces are not required in Symbol or SecurityDesc fields of `NewOrderOptionUSFuturesV1` message. |
| 1.1.10 | 07/03/23 | Removed "Duplicative Order Protection Order Count Threshold" and "Duplicative Order Protection Action" port attributes. |
| 1.1.11 | 07/31/23 | Updated priority treatment of no-change quotes, added new QuoteResult value of ‘O’, and noted modifications to quotes or orders and order cancellations will result in the same time priority behavior (effective 10/01/23). |
| 1.1.12 | 08/14/23 | Added Quote Reason Code = `n` (exceeds max notional value per order). |
| 1.1.13 | 01/22/24 | Updated MessageType description in `OrderAcknowledgementOptionUSFuturesV1` message. Updated MessageType description in `OrderAcknowledgementOptionUSFuturesV1` message. Added new `New Complex Instrument` , `New Complex Instrument Accepted` , and `New Complex Instrument Rejected` messages (Options Only) (effective 03/25/24). |
| 1.1.14 | 02/02/24 | Updated section 1.5 to include latency expectations as well as Members/TPH's responsibility to monitor the status of the messages they send to the exchange. |
| 1.1.15 | 06/05/24 | Removed references to IBHYT and IBIGT as part of CFE sunsetting TAS functionality for corporate bond index futures. |
| 1.1.16 | 06/28/24 | Updated Symbol and SecurityDesc description examples in the `NewOrderOptionUSFuturesV1` message. |
| 1.1.17 | 08/06/24 | Added new Section 1.2 - Certification Requirement. |
| 1.1.18 | 11/04/24 | Added two new Matching Units (effective 02/03/24). |
| 1.1.19 | 01/15/25 | Added `New Complex Instrument` , `New Complex Instrument Accepted` , and `New Complex Instrument Rejected` to Application Messages . Added SecurityDesc to NewComplexInstrumentAcceptedOptionUSFuturesV1 . Updated with Cboe Titanium branding. |
| 1.1.20 | 01/23/25 | Updated RequestReceivedTime description in `OrderAcknowledgementUSFuturesV1`. |
| 1.1.21 | 01/27/25 | Added FBT and FET to Unit 3 Unit/Product Distribution (effective 06/09/25). |
| 1.1.22 | 04/07/25 | Added XBTF to Unit 2 CFE Unit/Product Distribution (effective 04/28/25). |
| 1.1.23 | 09/09/25 | Added PBT and PET to Unit 3 CFE Unit/Product Distribution (effective 12/15/25 TBD 11/10/25). |
| 1.1.24 | 10/13/25 | Updated to include Cancel-Only Period and Multi-Segment Holiday Day Order Handling port attribute (effective 01/12/26 11/17/25 ). Added Multi-Segment Holiday Day Order Handling port attribute in Port Attributes (effective 01/12/26 11/17/25 ). Updated table to include new Cancel-Only Period (effective 01/12/26 11/17/25 ). |
| 1.1.25 | 10/20/25 | Updated CFE Unit/Product Distribution to include MGTN on Unit 2 (effective 12/08/25) (effective 11/17/25). |
| 1.1.26 | 10/30/25 | Updated PBT and PET effective date to 12/15/25 TBD. |
| 1.1.27 | 11/05/25 | Updated Cancel-Only Period and Multi-Segment Holiday Day Order Handling port attribute effective date to 01/12/26. |
| 1.1.28 | 11/17/25 | Updated PBT and PET effective date to 12/15/25. |
| 1.1.29 | 11/18/25 | Updated MGTN effective date to 12/08/25. |
| 1.1.30 | 01/05/26 | Updated Carried Order and Quote Restatements, Cancellation of Carried Orders or Quotes Between Sessions, and Submission Time Frames for Holidays to reflect the new time that persisted orders are added back into the order book. |
| 1.1.31 | 01/14/26 | Updated Session Disconnect for Holidays and Port Attributes to explain behavior of Cancel on Disconnect with regards to the new cancel-only period. |
| 1.1.32 | 05/04/26 | In Order Reason Codes and Quote Reason Codes , defined `u` as Limit Up Limit Down (LULD). Added information on Message in Flight . |
| 1.1.33 | 06/29/26 | Updated Mass Cancel Order and MassCancelOrderUSFuturesV1 to deprecate Lockout instruction on Mass Cancel messages (effective 08/24/26). |