# Cboe Titanium U.S. Options BOEv3 Specification

Version 1.1.21 · August 17, 2026

## Overview

This document describes Binary Order Entry, version 3 (BOEv3), the Cboe proprietary order entry protocol used by members to send orders, quotes, and purges to Cboe.

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 member’s representation of an order.
- Session level simplicity. The session level protocol (login, sequencing, replay of missed messages, logout) is simple to understand.

While Cboe 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.

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 List of 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.
  1. A "convenience" BOEv3 port will be made available which will allow for a single connection to interact with all matching units. Note that using a convenience port will incur an incremental latency cost due to the additional communication layer.
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 from a unitized port.
5. BOEv3 requires 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 members.
6. When logging in, members 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.
7. Logging in may specify a "deep replay" mode, available on the inactive session. See Failover and Disaster Recovery (DR).
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 member 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. Member 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. An in flight field has been added to most return messages, informing the member of the total number of messages received by the BOE3 order handler which have not yet been acknowledged by the matching engine(s).
12. A ScratchPad field has been added to messages sent from the Member to Cboe. This two byte field is located at or near the end of the message structure and can be used for a Member’s own internal purposes.
13. BOEv3 `Trade Cancel` or `Correct`messages are not suppressible by port parameter.
14. Added requirement for members 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)
15. Risk resets on a BOEv3 unitized port only apply for the unit associated with that port. BOEv2, BOEv3 convenience, and FIX ports risk resets may optionally apply to all units.
16. In many of the messages from Cboe to Member, the fixed set of fields in the response will be fewer than the total number of fixed and optional fields available over BOEv2.
17. For sequenced messages from Member to Cboe, a sequence number of `0` will always be accepted and is treated as if it were the next expected sequence number.
18. Symbol Order Rate threshold is no longer an available risk port attribute for BOEv3.
19. The Complex Instrument Accepted message does not provide an indication as to whether or not legs have been reordered relative to the original request. Members should always assume reordering has occurred (or compare against a cached copy of their request).

### BOEv3 Message Format Versioning and Nomenclature

Message types may be introduced when new fields cannot be accommodated by utilizing reserved 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:

**Table 1. BOEv3 Message Format**

| Application Layer Message Type | General Type | Market | Version |
|---|---|---|---|
| NewOrderUSOptionsV1 | `New Order` | US Options | V1 |

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

When application layer message types are discussed in this document, they are 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 Cboe to Member are supported concurrently, the port configuration determines which message version may be sent by Cboe.

### 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, members must check the length of messages received from Cboe and treat any additional bytes present as undefined values.

### Failover and Disaster Recovery (DR)

#### BOEv3 Unitized (BOEv3u) (BZX Only)

Each BOEv3u session assigned to a member will have three total ports available per unit for the member’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 order/quote traffic. Sequence numbers are unified across all three unitized ports for a given session. Telnet connectivity testing can be done at any time (24/7).

Deep Replay Logins

Active Primary (A) and Secondary (B) BOEv3u ports support a limited message replay facility. (see Login, Replay, and Sequencing). To facilitate the occasional need for a deep replay of messages, BOEv3 logins support a specialized ReplayInstruction = `D`(Deep Replay) on inactive ports. Deep replay logins can only be used for deep replay. On a successful deep replay login, after Cboe has sent the requested messages, clients should logout and disconnect; otherwise Cboe will send a LogoutResponse and disconnect the port after an idle period of 30 seconds. Any order/quote traffic on a deep replay login will not be accepted and the session will be immediately disconnected.

Under normal operations, the active port will be the primary port (A) and the inactive ports are secondary (B) and DR (C). Upon promotion of either port to "active", any deep replay logins will be immediately terminated.

Order Handler Redundancy

Port B and C will only accept deep replay logins (ReplayInstruction = `D`), unless promoted to active. All other login attempts will be rejected. As a result of this design, customers may design their system to attempt to connect with regular logins (i.e. ReplayInstuction value other than `D`) to Port A, B, or C and can be confident that the port that accepts their login is the current primary.

Disaster Recovery Data Center

While DR activation may occur intraday, it will only occur only after Cboe has provided notification to customers.

#### BOEv3 Convenience (BOEv3c)

Order Handler Redundancy in Primary Data Center

There are no explicit separate BOEv3c address, port or credentials. Cboe will activate a replacement order handler when necessary using the same address, port and credentials. Sequences on an activated replacement will match primary, less anything very recent lost during failover. Please note that there is no way to communicate with dormant backup port before it is activated.

Disaster Recovery Data Center

Cboe configures an order handler session in DR data center (Chicago for US) for each primary site order handler session. Members are able to connect, login, and heartbeat to the DR session at any time during trading operations. Unless the DR data center has been activated all application-level messages (orders, quotes) will be rejected.

Login credentials are the same as the primary site.

The DR sessions have independent sequence numbering, and will not support the replay of messages from the primary data center.

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

### Document Format

Blue highlighted sections highlight key differences between the Cboe US Options Exchanges (BZX Options Exchange BZX only, Cboe Options Exchange C1 only, C2 Options Exchange C2 only, and EDGX Options Exchange EDGX only).

### Hours of Operation

All times noted are Eastern Time (ET).

See the respective exchange websites for holiday schedules.

Cboe Options Exchanges support a Pre-Market Queuing Session that allows orders to be entered and queued prior to the start of the Global Trading Hours (GTH) session and the Regular Trading Hours (RTH) session. The GTH Queuing session allows GTH-eligible Product orders marked as both GTH and RTH only order to be entered and queued. C1 also supports a Curb session in addition to GTH and RTH sessions.

For information on the Cboe Opening Process, please refer to the Cboe Titanium U.S. Options Opening Process specification.

Cboe Options Exchanges do not support a closing auction, but do support extended trading for options on select ETF and index products. All orders remaining after the Regular Trading Session that are not eligible for Extended Trading will be cancelled automatically. All orders remaining after the Extended session will be cancelled automatically. Members will receive `Order Cancelled` messages for all automatically cancelled orders.

Product and session trading hours can be found on the Cboe website.

#### Holiday Sessions (C1 Only)

On certain U.S.-centric holidays, where European and/or Asian markets are open, trading is suspended for RTH and Curb but continues for GTH products eligible to trade on holidays, resulting in two sets of non-contiguous GTH sessions before RTH.

_(Figure: Figure 1. U.S. Holiday Trading Hours)_

On days where the market closes early, RTH will conclude at 1:15 p.m. ET and there will not be a subsequent Curb session. The market will remain closed until the next GTH session.

On certain International Holidays (i.e., New Year's Day) there is no GTH or RTH trading and the C1 Options market is closed. Notice is sent prior to holidays communicating the specific hours and sessions that will be available.

### 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 Member to Cboe and Cboe to Member 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
- 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 considering implied decimal places is 12.3400.
  - 08 E2 01 00 00 00 00 00 = 123,400/10, 000 = 12.3400
  - F8 1D FE FF FF FF FF FF = -123,400/10, 000 = -12.3400
- Short Binary Price: Little Endian byte order value, signed two's complement, four bytes in size, with four implied decimal places. So, if the value is 123,400, the actual value considering implied decimal places is 12.3400.
  - 08 E2 01 00 = 123,400/10, 000 = 12.3400
  - F8 1D FE FF = -123,400/10, 000 = -12.3400
- 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. The number of bytes used depends on the context.
- DateTime: Little Endian byte order, unsigned binary value, 8 bytes in size. The date and time, in UTC, represented as nanoseconds past the UNIX epoch (00:00:00 UTC on 1 January 1970). This field is populated using nanoseconds.
  - E0 FE 20 F7 36 71 F8 11 = 1,294,909,373,757,325, 000 = 2011-01-13 09:02:53.757325 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 member. May contain any values when sent by the exchange and should be ignored by the member.

Blank Alpha and Text fields (entirely filled with ASCII NUL (0x00)) are eligible to be populated with a port default value. See Port Attributes for eligible port parameters.

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

#### Architecture and Message in Flight Settings

Each BOE order handler port will allow a single TCP connection from a member. Connection attempts from unknown source IP ranges will be blocked to prevent unauthorized access to BOE ports. The Cboe NOC should be contacted in the event that a Member desires to connect from a new source IP range.

The connections between BOE order handlers and matching units are governed by an internal flow control mechanism to control burst rates.

The number of messages in flight between an order handler and a matching engine is 128. In addition, when the total number of unacknowledged messages exceeds 1,024, the BOE order handler will stop reading from the member-facing TCP socket. This will cause the order handler to stop removing bytes from the TCP receive buffer, and will prevent the member from sending more TCP data once the member’s send buffer is full.

When the total number of unacknowledged messages falls below 960, the reading of the member facing TCP socket will be resumed.

For message in flight counting purposes the following logic will be used:

- A new order message will count as one message.
- A new complex order with up to 100 legs will count as one message.
- A new order cross or new complex order cross auction message with one agency side and up to 10 contra parties will count as one message.
- A quote update with up to 20 individual quote sides will count as one message.
- In contrast, a single TCP segment sent by a member containing two quote update messages, each with five quote sides, will count as two messages.

Cboe may either update the message in flight or the total number of unacknowledged messages settings with notice. Changes to reduce either limit will be made only with two weeks’ notice. Cboe reserves the ability to increase either limit immediately with notice.

#### Complex Instruments and Signed Prices

All price fields in the BOE protocol are signed values capable of accommodating complex instruments that can be negative (See Data Types for a description and an example of using the Binary Price type with a negative price). For an example of the Binary Price type with a negative price value in an application message, see NewComplexOrderUSOptionsV2 (Effective TBD).

#### Done For Day Restatements

Good ‘Til Cancel (GTC) and Good ‘Til Day (GTD) orders can result in order persisting between sessions. The Cboe BOE protocol provides a mechanism for clients to request end-of-day restatement of GTC/GTD orders that will be persisted to the next trading session.

Done For Day Restatement messages are sent to connected clients after the trading session ends, for each order that will persist to the next trading session. Any time prior to the cutoff, customers may send `Cancel Order` messages for any open GTC and GTD orders.

Done For Day Restatements are represented using the `Done For Day` message.

#### Carried Order Restatements

GTC, GTD, and DAY orders entered during partial holiday sessions can also persist between multiple trading sessions. The Cboe BOE protocol provides a mechanism for clients to request restatement of orders that have been carried forward from the previous business day trading session.

Carried Order Restatements are sent to connected clients for each product on the Options Exchange for which orders have been carried forward from the previous business day trading session. Persisted orders are added back into the order book starting at approximately 15 minutes prior to the scheduled queuing time for each underlying symbol, after connection establishment and before regular trading activity messages on a per-product basis.

Carried Order Restatements are represented using the `Carried Restatement` message.

#### Cancellation of Carried Orders Between Trading Sessions

GTC and GTD orders persist within the Cboe Options Exchanges between business days. On BZX, EDGX, and C2 the latest time when GTC/GTD orders may be cancelled is 4:45 p.m. ET.

On C1 Options the latest time when GTC/GTD orders may be cancelled is 5:15 p.m. ET (15 minutes following the close of the latest Curb Session).

GTC, GTD, and Day orders for GTH products eligible to trade on holidays also persist between multiple GTH trading sessions on the same business day in connection with a holiday. On US holidays, `Cancel Order` messages for GTC orders may be issued until 11:45 a.m. ET, which is 15 minutes after the first GTH session ends. After the cancellation period, cancellation requests will be rejected with reason `O: Order known, but cannot be canceled at this time` until after the system restart completes and persisted orders are reloaded into the system. The Multi-Segment Holiday Day Order Handling port attribute will enable Members to designate if Day orders are cancelled or preserved across holiday trading segments comprising a single business date. See Port Attributes for information on available port attributes.

#### Display Indicator Features

Orders are eligible for all of the sliding features described below. Quotes are eligible for the sliding behaviors described below if they are received with a price that locks the NBBO and with a PostingInstruction eligible for price sliding. Quotes that also cross the NBBO or displayed Cboe book will be accepted if within a configurable buffer range through the NBBO or displayed Cboe book. The buffer is set to 5% with a minimum of $0.05 and a maximum of $1.00.

For BZX only, quotes and orders marked as Post Only will execute against resting liquidity as a remover and be charged applicable removal fee codes if the amount of price improvement of the removal execution exceeds the expected rebate that the order or quote would have received if it had posted at its limit price.

Display-Price Sliding (BZX Only)

If the original limit price of the unexecuted remainder of a day order does not lock or cross the NBBO then Cboe works the order at the original limit price while displayed at the nearest permissible quoting increment. If the original limit price does lock or cross the NBBO then Cboe makes available Display-Price Sliding.

Display-Price Sliding adjusts the original limit price on entry to the locking price of the NBBO. It will be ranked and worked at a price locking the NBBO but will temporarily adjust the displayed price to the nearest permissible quoting increment. When the NBBO widens, the display price will be readjusted to the adjusted limit price. The display price may be temporarily less aggressive than the adjusted limit price or working price.

Multiple Display-Price Sliding does not permanently adjust the original limit price on entry, but allows for Display-Price slid orders to continue to have their display and working prices adjusted towards their original limit price based on changes to the prevailing NBBO.

Contra-side Post Only orders received when a Display-Price Slide order is working at a locking price with the NBBO will not result in a reject of a contra-side Post Only order but will instead result in the working price of the Display-Price Slid order to be repriced to one penny away from the locking price.

Price Adjust

If the limit price of an order does not lock or cross the NBBO, then the order will be ranked and displayed at the nearest permissible quoting increment.

If the limit price of a Price Adjust eligible order locks or crosses the NBBO, the limit price will be adjusted on entry to the locking price of the NBBO, while the displayed price and ranked price will be temporarily adjusted to the nearest permissible quoting increment. Price Adjust orders will never be ranked at the locking price or at a non-displayable price increment. If the NBBO widens, the displayed price and ranked price will be readjusted to the adjusted limit price.

The limit price of a Multiple Price Adjust order will not be permanently adjusted on entry if the limit price crosses the NBBO. The displayed price and ranked price will be the nearest permissible quoting increment and will be adjusted towards the original limit price based on changes in the prevailing NBBO.

NoRescrapeAtLimit (BZX Only)

Applicable only to fully routable IOC orders (9303 = R and 59 = 3). After walking the price down to the limit, there will be no final scrape at Cboe and the cancel code will state `X`=Expired rather than `N`=No Liquidity.

#### Default Exchange Risk Protections

##### Market Order NBBO Width Protection for Simple Orders

Market Orders are rejected if the NBBO width is greater than 100% of the midpoint (with a minimum value of $5.00 and maximum value of $10.00).

Example

- NBBO = $1.00 x $4.00
- Midpoint = $2.50 x 100% = $2.50 (min of 5.00 is used instead)
- NBBO Width = $4.00 - $1.00 = $3.00

Even though the width is greater than 100% of the midpoint, Market Orders entered are accepted since the $5.00 minimum applies in this example.

##### Drill-Through Protection for Simple Orders

Each simple limit order will be assigned a drill-through price that allows simple orders to be executed up to an initial capped price through the contra side NBBO at time of order entry. For information on how this drill-through behavior is leveraged within a separate protection feature, see Wide Market Protection.

The drill-through mechanism will then repeatedly post the order at a more aggressive price. If the order reaches its limit price at any time during the iterative drill-through process, the order will remain at its limit price and the drill-through protection mechanism will not continue. The preset duration is 200 ms for C1 Proprietary Index Products and 1 second for all other products on BZX, C1, C2, and EDGX. Effective 08/24/26, the preset duration will be 100 ms for all products on all Exchanges.

Adjustments that would lock or invert an away displayed market will initiate a SUM auction.

Market orders submitted with a TimeInForce (FIX Tag 59) of `Day` along with elected stop orders are eligible for iterative drill-through price protection.

- Sell market orders will drill-through down to the minimum tick for the class where they will rest until cancelled or executed in full.
- Buy market orders will drill-through to the maximum allowable price for the class where they will rest until cancelled or executed in full.
- Market orders submitted with a TimeInForce of `IOC` will trade on arrival, capped at the first drill-through price level.

Separate stop and stop limit orders elected as a result of the same election trigger (NBBO update or last sale) will all use the same drill-through reference price. This may include orders with multiple stop prices if the election trigger covers multiple price levels. When multiple stop orders are elected as a result of the same election trigger, they are sequenced in time priority based on their order entry time.

- If an iterative drill-through protection is in progress, newly-elected stop and stop limit orders will join the current drill-through price. The newly-elected stop and stop limit orders will be prioritized behind orders already in drill-through.
- If no iterative drill-through is in progress, the initial drill-through reference price for stop and stop limit orders elected by the same market data event will be set to the contra side NBBO.

Triggered Market-On-Close and Limit-On-Close orders are handled the same as elected stop and stop limit orders with respect to drill-through reference price and priority.

- Existing market-width checks prevent market orders from executing if the bid/ask width is wider than a specified amount. This protection will be bypassed for triggered Market-On-Close orders and triggered stop orders.
- Existing Fat Finger limit price reasonability checks reject limit orders priced at an overly-aggressive level. Such protections will be bypassed for triggered Limit-On-Close orders and triggered stop limit orders.

The Drill-Through Price is calculated by taking the NBB or NBO and subtracting or adding, respectively, the Drill-Through Amount from the Drill-Through Price table. Calculated drill-through prices at an invalid pick increment for the class will be widened to the next valid tick.

**Table 1. Drill-Through Price**

| NBBO Price | Drill-Through Amount (All Symbols) |
|---|---|
| $0.00 - $5.00 | $0.10 |
| $5.01 - $20.00 | $0.20 |
| $20.01 - $50.00 | $0.30 |
| $50.01 - $100.00 | $0.40 |
| $100.01 & Above | $0.50 |

##### Wide Market Protection (C1 only)

Wide market protection (WMP) initiates a pause on inbound orders and elected stop/stop limit orders when the NBBO is deemed "wide" based on pre-established parameters. Specifically, the NBBO is considered wide if there is no NBO or if the bid/ask spread is wider than the WMP Determinant based on the NBB (Bid Price) in the table below. Inbound limit orders and triggered stop limit orders are subject to WMP if the NBBO is deemed to be wide and their price is marketable.

Orders subject to WMP will begin a drill-through process per Drill-Through Protection (above) using an initial drill-through display price as determined by WMP benchmark pricing. If a drill-through is in progress, the orders will join that process. WMP will not be initiated within 30 seconds prior to the close of the RTH or Curb trading sessions; however, any current drill-through processing will continue. Effective 08/24/26, WMP will be initiated up until the close of the RTH or Curb trading sessions and any current drill-through processing will continue.

WMP is applied to all proprietary index products.

###### WMP Benchmark Price Determinations

1. Last trade price, if more aggressive than or equal to the same-side NBBO
2. NBBO midpoint
3. Same-side NBB/NBO +/- the NBBO Adjustment Amount (NAA), as follows:
  1. Buy orders: NBB + NAA
  2. Sell orders: NBO - NAA
  3. If there is no NBO, sell orders use NBB + WMP Determinant

**Table 1. Wide Market Protection Determinants**

| NBB Price | WMP Determinant | NBBO Adjustment Amount (NAA) |
|---|---|---|
| ≤ $3.00 | ≥ $1.50 | $0.75 |
| $3.01-$5.00 | ≥ $2.00 | $1.00 |
| $5.01-$10.00 | ≥ $2.50 | $1.30 |
| $10.01-$20.00 | ≥ $4.00 | $2.00 |
| $20.01-$50.00 | ≥ $5.00 | $2.50 |
| $50.01-$100.00 | ≥ $10.00 | $4.50 |
| $100.01 - $200.00 | ≥ $23.00 | $6.00 |
| $200.01+ | ≥ $36.00 | $6.00 |

###### Subsequent Drill-through Pricing

If the market is wide and the order has been paused at the benchmark price, the order will be handled by iterative drill-through logic. The order paused at its benchmark price will be considered the initial drill-through iteration, and subsequent iterations will use existing drill-through logic. Note that drill-through amounts and timers may be modified.

Following the current drill through logic, new incoming market and limit orders will join the protected order(s) at the current drill-through price. All existing drill-through logic for handling the priority of orders in a bundle will be applied. Market-Maker quotes, Immediate or Cancel (IOC) orders, and Intermarket Sweep Orders (ISO) will bypass drill-through protection and can book or trade ahead of the drill-through bundle. If an away market or Market-Maker quote (but not an order) is displayed more aggressively than the drill-through price, the drill-through bundle will move to that price.

To mitigate risk of orders being un-executed towards the end of a trading day, WMP will be bypassed starting at a configurable amount of time prior to the close of the RTH and Curb sessions for the series. Note this timer does not apply to Global Trading Hours (GTH).

During the end of session timeframe:

1. WMP will be disabled. If no drill-through is in-progress, new non-marketable limit orders will simply book, and marketable limits and market orders will execute and be eligible to initiate drill-through after their initial execution.
2. Post-execution drill-through will continue to remain active and enabled. Any drill-through in progress will continue as normal. This includes drill-through which was previously initiated by WMP. At the end of the timer and the RTH session, any RTH-only orders will be cancelled, and any drill-through that is in progress will continue for orders eligible for the Curb session. This follows existing drill-through functionality. WMP will be reactivated at the start of the Curb session and will function the same as it does in RTH.
3. Inbound orders and newly elected stop and stop limit orders will continue to join drill-through in progress.

##### Market/Limit Order Drill-Through for Complex Orders

Default Drill-Through Protections will be applied to all complex limit and market orders that will cap the price of the order relative to the SNBBO at the time of order entry. Exchange defaults are 5% through the contra-side of the SNBBO. For orders other than SPX/SPXW, the price cap level will be no larger than $0.25 through the contra-side SNBBO. For SPX/SPXW, the price cap level will be no larger than $2.00 through the contra-side SNBBO. The price cap level will be no smaller than $0.02 through the contra-side SNBBO for all orders.

For complex orders not specifying a drill-through override with DrillThruProtection (FIX 6253), the drill-through mechanism will repeatedly post the order at a more aggressive price. If an order reaches its limit price at any time during the iterative drill-through process, the order will remain at its limit price and the drill-through protection mechanism will not continue. The preset duration is 200 ms for C1 Proprietary Index Products and 1 second for all other products on BZX, C1, C2, and EDGX. Effective 08/24/26, the preset duration will be 100 ms for all products on all Exchanges.

Sell market orders will drill through to the minimum tick for the class, where they will rest until cancelled or executed in full. Buy market orders will drill through to the maximum allowable price for the class, where they will rest until cancelled or executed in full. Market orders submitted with a TimeInForce of `IOC` will trade on arrival, capped at the first drill-through price level.

Customers can optionally set more or less restrictive Drill-Through Protections on individual orders using DrillThruProtection on the `New Order Multileg` message. Eligible complex orders may also initiate a COA throughout the iterative process.

##### Exchange Default Fat Finger Limits

Fat Finger Checks are mandatory for both Pre-Market and Regular Sessions and applied to both simple and complex orders. The following Exchange defaults are applied if not specified by the user. Fat Finger checks are not applicable for any Multi-Class Spread instruments that trade on the floor only. Fat Finger checks are applicable for Multi-Class complex instruments containing only SPX or SPXW legs as they are eligible for trading on the electronic book.

**Table 1. Pre-Open Curb/GTH Session (Eligible GTH Products, Excluding SPX)**

| Limit Price Range | Fat Finger % Default | Fat Finger Dollar-Based Limit Default |
|---|---|---|
| $0.00 - $1.99 | No Value | $1.00 |
| $2.00 - $5.00 | No Value | $1.50 |
| $5.01 - $10.00 | No Value | $2.00 |
| $10.01 - $20.00 | No Value | $3.00 |
| $20.01 - $50.00 | No Value | $4.00 |
| $50.01 - $100.00 | No Value | $6.00 |
| $100.01 & Above | 8% | Not Valid |

**Table 2. Regular Session**

| Limit Price Range | Fat Finger % Default | Fat Finger Dollar-Based Limit Default |
|---|---|---|
| $0.00 - $1.99 | No Value | $0.50 |
| $2.00 - $5.00 | No Value | $0.75 |
| $5.01 - $10.00 | No Value | $1.00 |
| $10.01 - $20.00 | No Value | $1.50 |
| $20.01 - $50.00 | No Value | $2.00 |
| $50.01 - $100.00 | No Value | $3.00 |
| $100.01 & Above | 4% | Not Valid |

SPX and SPXW are considered Exception Classes and have unique Fat Finger default values for the Pre-Open and Regular sessions.

**Table 3. Exception Class Pre-Open Curb/GTH Session (SPX)**

| Limit Price Range | Fat Finger % Default | Fat Finger Dollar-Based Limit Default |
|---|---|---|
| $0.00 - $1.99 | No Value | $15.00 |
| $2.00 - $5.00 | No Value | $15.00 |
| $5.01 - $10.00 | No Value | $15.00 |
| $10.01 - $20.00 | No Value | $15.00 |
| $20.01 - $50.00 | No Value | $20.00 |
| $50.01 - $100.00 | No Value | $20.00 |
| $100.01 & Above | No Value | $25.00 |

**Table 4. Exception Class Regular Session**

| Limit Price Range | Fat Finger % Default | Fat Finger Dollar-Based Limit Default |
|---|---|---|
| $0.00 - $1.99 | No Value | $1.00 |
| $2.00 - $5.00 | No Value | $1.50 |
| $5.01 - $10.00 | No Value | $2.00 |
| $10.01 - $20.00 | No Value | $3.00 |
| $20.01 - $50.00 | No Value | $4.00 |
| $50.01 - $100.00 | No Value | $6.00 |
| $100.01 & Above | 16% | Not Valid |

See the Cboe Titanium U.S. Equities/Options Web Portal Port Controls Specification for details on how Members can manage fat finger settings intraday.

##### Default Fat Finger Limits for Quote Updates

Quotes that cross the NBBO or displayed Cboe book will be accepted if within a configurable buffer range through the NBBO or displayed Cboe book. The buffer is set to 5% with a minimum of $0.05 and a maximum of $1.00.

##### Maximum Open Order Limits

The exchange limits the maximum number of open orders allowed on a BOE or BOE Quote port to 200,000 per port. New orders will be rejected once this limit is breached until the number of open orders drops back below 200,000. Note this limit is only for orders and does not include open quotes sent over a BOE Quote port.

#### Risk Root

The term "Risk Root" is used to describe Cboe Options Risk Management functionality that is applied at the symbol-level. The Risk Root is defined as the underlying symbol. This impacts what value must be sent in the defined RiskRoot fields when performing a mass cancel or a risk trip reset.

See the Cboe Titanium U.S. Options Risk Management Specification for more details.

#### Market Maker Trade Notifications (C1 Only)

Floor Trade Notifications (MMTNs) will be sent to Market Makers if they are identified as the contra party of a floor trade. MMTN messages will be sent over a designated FIXDrop or BOE order entry port. See Port Attributes for information on available port attributes related to MMTNs.

Market Makers that receive a Floor Trade Notification should use the `Floor Trade Confirmation` message to respond to the MMTN if they agree with the terms of the trade. Alternatively, a Market Maker can use the `Add Floor Trade` message to enter their own version of the trade.

#### Cabinet and Sub-Cabinet Orders (C1 Only)

Cabinet orders are identified via `PriceType`=0 and must have a valid `TimeInForce`=Day or GTC. Cabinet orders can support a position status of `Open`or `Close`identified via the OpenClose field. Cabinet orders will only trade with other cabinet orders on the floor and therefore require direct or default floor routing instructions as described in Floor Routing (C1 Only).

Orders in non-penny classes must have a limit price less than or equal to $0.01 and orders in penny classes must have a limit price less than $0.01. Limit prices may be up to 4 decimal places.

Orders in penny or non-penny classes priced greater than $0.01 and orders in penny classes priced equal to $0.01 will be rejected. Orders with a limit price that locks or crosses a resting non-cabinet order will be rejected.

Cabinet orders or executions will not be disseminated on OPRA but will be available on the Cboe U.S. Options Multicast TOP and PITCH feeds.

#### Auction Orders

For more information on the following Auction Only Orders, please see the Cboe Titanium U.S. Options Opening Process.

**Table 1. Auction Only Orders**

| Order Type | Order Entry Details |  |
|---|---|---|
| Market-On-Open (MOO) | `OrdType` = 1 (Market) | `TimeInForce` = 2 (At the open) |
| Limit-On-Open (LOO) | `OrdType` = 2 (Limit) `Price` = [price] | `TimeInForce` = 2 (At the open) |
| Settlement Liquidity On Open (SLOO) | `OrdType` = 2 (Limit) `Price` = [price] | `TimeInForce` = 2 (At the open) `ExecInst` = r (Settlement Liquidity) |

#### Port Types

All BOE port types may be ordered using the Logical Port Request tool on the Customer Web Portal. Port attribute changes may also be requested through this tool by submitting a Modify request for one or more existing BOE ports.

##### Unitized Ports (BZX Only)

BOE unitized ports are specific to a particular matching unit. Members connecting to unitized ports will have the most direct available route to the matching engine. See Appendix B - Architectural Diagrams.

##### Convenience Ports

BOE convenience ports support routing traffic to all units. A convenience port will in turn route traffic to the appropriate BOE unitized order handler (BZX Only) or matching unit (C1, C2, and EDGX only). Messages sent via a convenience port requires additional routing to access a unit, similar to FIX and BOEv2. See Appendix B - Architectural Diagrams for architectural diagrams of BOE unitized port deployments (BZX Only) and BOE convenience port deployments (C1, C2, and EDGX Only).

##### BOE Order Ports

Standard BOE ports support simple and complex order entry but do not support the usage of the following message types: `Quote Update`, `Quote Update (Short)`, or `Purge Orders` message. The attempted usage of any of these message types on standard BOE order ports will result in a rejection of the disallowed message.

Standard BOE ports are limited to 5,000 inbound messages per second. Only messages having symbols mapped to the matching unit will be accepted. Once the inbound limit is reached new orders are rejected, modifies are handled as cancels, and cancels are processed normally.

##### BOE Bulk Quoting Ports

BOE Bulk Quoting ports are intended for use by market makers quoting large numbers of simple options series using `Quote Update` messages and complex series using `Complex Quote Update`messages . As a result, they are unthrottled in terms of number of messages that may be accepted within any given period of time from a member. However, market makers may still experience poor performance on Bulk Quoting ports if excessive message traffic is sent.

In BZX only, Quoting ports are always unitized ports, not convenience ports.

The PreventMatch field may not be specified on the `Quote Update` or `Complex Quote Update` messages and Match Trade Prevention is only available if defaulted at the port level. For Bulk Quoting ports, only Cancel Newest, Cancel Oldest, or Cancel Both are permitted. If a Bulk Quoting port is not configured with both a default MTP Modifier and Unique ID Level, Match Trade Prevention will be disabled.

**Table 1. Bulk Quoting Port Order Acceptance Table**

| Message | Simple/Complex | Accepted over Bulk Quoting Port? | Other Conditions |
|---|---|---|---|
| `Quote Update` | Simple | Yes |  |
| `Quote Update (Short)` | Simple | Yes |  |
| `Complex Quote Update` | Complex | Yes |  |
| `Complex Quote Update (Short)` | Complex | Yes |  |
| `New Order` | Simple | Yes | Must have a TimeInForce value of Day or GTD with a same day expiration on C1, C2, and EDGX. |
| `New Order (Auction Response)` | Simple | Yes |  |
| `New Order Cross (AIM or QCC)` | Simple | No |  |
| `New Order Cross Multileg` | Simple | No |  |
| `Purge Orders` | Simple/Complex | No |  |
| `Reset Risk` | Simple/Complex | Yes |  |
| `New Complex Instrument` | Complex | Yes |  |
| `Quote Update` | Complex | No |  |
| `New Complex Order` | Complex | Yes | Must be Post Only ( `RoutingInst` = P ) and must have a TimeInForce value of Day or GTD with a same day expiration. (C1, C2, and EDGX only ) Can be Post Only ( RoutingInst = P) or Book Only ( RoutingInst = B) . (BZX only) |
| `New Complex Order (COA Response)` | Complex | Yes |  |

Bulk Quoting Port Quote/Order Behavior Matrix

The following matrix describes the liquidity removal behavior of quotes and orders sent on Bulk Quoting ports. Bulk Quoting ports are available for use by all customers but only Market Makers may use `Quote Update` or `Complex Quote Update` messages. On C1, C2, and EDGX Options, only registered Market Makers are allowed to remove liquidity using `New Order` messages. On BZX Options, all customers are allowed to remove liquidity using `New Order` and `New Complex Order` messages.

Once a quote or order is posted to the exchange book, liquidity removal against any contra capacity is always allowed in the case that a subsequent event causes the resting quote or order to be re-evaluated, such as the Opening/Re-Opening Process.

- Only Market-Makers can send `Quote Update` or `Complex Quote Update` messages, and such messages can only be sent on a Bulk Quoting Port.
- Liquidity removal using a `New Order` message on Bulk Quoting ports is restricted to appointed Market-Makers only. Removal of any resting order with a `Quote Update` by a Market-Maker when not appointed in the class will result in an `Order Reject` message with OrderRejectReason set to `A`=Market Maker must be registered to remove liquidity on quoting port.
- Liquidity removal using `Complex Quote Update` messages on Bulk Quoting ports is not allowed and will result in a QuoteResult reject of `P` = Rejected, can't post.
- `New Order` messages can be sent over FIX/BOE Ports and Bulk Quoting Ports by all capacities. However, on C1, C2, and EDGX, non-Market-Maker `New Order` messages sent over a Bulk Quoting Port must be marked Post Only and thus cannot remove liquidity. Table 2. BOE Bulk Quoting Port and FIX/BOE Order Port FAQ FAQ BOE Bulk Quoting Port FIX/BOE Order Port BZX C2 EDGX C1 BZX C2 EDGX C1 Can a Market-Maker send `New Order` messages? Yes Yes Yes Yes Yes Yes Yes Yes Can a Market-Maker send `Quote Update` messages? Yes Yes Yes Yes No No No No Can a Market-Maker send `Complex Quote Update` messages? N/A N/A N/A Yes N/A N/A N/A No Can a non-Market-Maker send `New Order` messages? Yes Yes Yes Yes Yes Yes Yes Yes Can a non-Market-Maker send `Quote Update` messages? No No No No No No No No Can a non-Market-Maker send `Complex Quote Update` messages? N/A N/A N/A No N/A N/A N/A No Can an aggressing Market-Maker remove a resting Market-Maker quote or order? Yes No No No Yes Yes Yes Yes Can an aggressing Market-Maker remove a resting non-Market-Maker order? Yes Yes Yes Yes Yes Yes Yes Yes Can an aggressing non-Market-Maker remove a resting Market-Maker quote or order? Yes No No No Yes Yes Yes Yes Can an aggressing non-Market-Maker remove a resting non-Market-Maker order? Yes No No No Yes Yes Yes Yes

Please note that under no circumstances can an order submitted with a `Complex Quote Update` message remove resting liquidity on entry to the order book.

##### BOE Purge Ports

###### BZX Purge Ports

BOE Purge Ports on BZX support the following message types: `PurgeOrdersUSOptionsV1` (sunset 03/23/26) and `PurgeOrdersUSOptionsV2` messages. Members may use this message type to request a cancellation of groups of orders, including orders across multiple FIX, BOE Order, or BOE Bulk Quoting ports associated with the same unit.

Note that since Purge Ports are also provisioned per matching unit, a purge request will be limited to the symbol range of the targeted matching unit.

###### C1, C2, and EDGX Purge Ports

BOE Purge Ports on C1, C2, and EDGX support a single message type: `PurgeOrdersUSOptionsV2` messages. Members may use this message type to request a cancellation of groups of orders, including orders across multiple FIX, BOE Order, or BOE Bulk Quoting ports.

#### Floor Routing (C1 Only)

All orders routed to the floor must include explicit routing instructions that include two features: 1) floor routing instruction indicating Direct or Default routing behavior and 2) floor destination information. Floor routing behavior is specified in FloorRoutingInst (22303). Direct routing sends the order to the indicated PAR workstation, while default routing indicates that electronic execution is preferred, but the order may be routed to the indicated PAR if it cannot be processed electronically.

Examples of conditions which cause default routing to the Floor include:

- a complex order having an AON contingency
- a complex order with multiple underlying components
- not held orders

Floor destination instructions are specified in FloorDestination (22100), indicating a PAR workstation (ex. W001) to route to on the floor (or `PARO` to route to the Floor PAR Official of the underlying symbol) if not specified on the inbound message. See Port Attributes for information on available port attributes, including Default FloorRoutingInst and Default FloorDestination.

**Table 1. Floor Routing Instructions**

| Order Tags/Port Settings | Handling of the Order |  |  |  |  |
|---|---|---|---|---|---|
| Order Floor Destination | Order FloorRoutingInst | Port Default Floor Destination | Port Default FloorRoutingInst | Orders Only Executed on Floor (i.e. complex AON) | All Other Order Types |
|  |  |  | E (default) | Reject: ineligible for electronic book | Process electronically |
|  |  |  | D | Reject: requires a floor destination | Reject: requires a floor destination |
|  |  |  | X | Reject: requires a floor destination | Reject: requires a floor destination |
|  |  | W001 | E (default) | Reject: ineligible for electronic book | Process electronically |
|  |  | W001 | D | Route to floor: W001 | Route to floor: W001 |
|  |  | W001 | X | Route to floor: W001 | Process electronically |
| W009 |  |  | E (default) | Reject: ineligible for electronic book | Process electronically |
| W009 |  | W001 | D | Route to floor: W009 | Route to floor: W009 |
| W009 |  |  | X | Route to floor: W009 | Process electronically |
| W009 | E |  |  | Reject: ineligible for electronic book | Process electronically |
| W009 | D |  |  | Route to floor: W009 | Route to floor: W009 |
| W009 | X |  |  | Route to floor: W009 | Process electronically |
|  | E |  |  | Reject: ineligible for electronic book | Process electronically |
|  | D |  |  | Reject: requires a floor destination | Reject: requires a floor destination |
|  | X |  |  | Reject: requires a floor destination | Process electronically |

E = Electronic only D = Direct X = Route to floor if unable to process electronically

##### Floor Representation Restatements (C1 Only)

Orders routed to the trading floor will be represented to the open outcry crowd before being traded in the crowd. The Cboe BOE protocol provides a mechanism for members to receive restatement of orders at the time of representation.

BOE Floor Representation Restatements are sent to connected members for each order when the floor broker reports representation of the order to the crowd. Floor Representation Restatements sent to BOE ports will also be sent to connected Order by Order Drop ports having the Floor Representation Restatements port attribute enabled.

`Order Restated` messages for floor representation will have `RestatementReason`= F (Represented on Floor). The TransactTime (60) will be the recorded time of the representation.

## Session

### Message Header Fields

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 Cboe to the Member. Messages from Member to Cboe and all session level messages must always set this value to 0.

**Table 1. Message Header Fields**

| 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 Member to Cboe, the unit must be 0. |
| Reserved | 7 | 1 | Binary | Must be zero from member. Value unspecified from Cboe. |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message. Messages from Cboe to Member 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 the following is encountered:

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

### Login, Replay, and Sequencing

Session level messages, both inbound (Member to Cboe) and outbound (Cboe to Member) are unsequenced.

Inbound (Member to Cboe) application messages are sequenced. Upon reconnection, Cboe informs the member of the last processed sequence number; the member may choose to resend any messages with sequence numbers greater than this value. A gap forward in the member’s incoming sequence number is permitted at any time and is ignored by Cboe. 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.

Many outbound (Cboe to Member) 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 member sends the last received sequence number per matching unit in a `LoginRequest` message. Cboe will then respond with any missed messages. If the sequence message gap is greater than the value supported by Cboe for a unitized port, the login will be rejected with a Login Response Status of `R` (replay too deep). The maximum value for Cboe Primary and Secondary ports is 1000 messages, while an unlimited number are permitted in DR.

The ReplayInstruction value can be used to control the replay behavior for unknown units. If the flag is set to F (Fail), Cboe will send a `Login Response` message and close the connection if the login request does not list all matching units. If the flag is set to S (Skip), Cboe will exclude messages from unspecified matching units during replay. If the flag is set to R (Replay), Cboe will send messages from unspecified units during replay (starting with sequence 1 per unspecified unit and limited to 1000 messages on a unitized port). Cboe 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. Cboe will reject all orders during replay. If the flag is set to D (Deep Replay), the login is accepted only on an inactive unitized port, to facilitate the replay of messages beyond the limit imposed on an active unitized port.

If a member has requested replay messages using a properly formatted `LoginRequest` message after a disconnect, any unacknowledged orders remaining with the member after the `Replay Complete` message is received should be assumed to be unknown to Cboe.

Unsequenced messages will not be included during replay.

A session is identified by the SessionId and SessionSubId (both supplied by Cboe).

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 member can send a `LoginRequest` message with ReplayInstruction set to S (Skip), and NumberOfUnits set to zero. Then, upon receiving a `Login Response` message from Cboe, the member can use the ClientSequence value in that message as the sequence starting point for sending future messages.

### Heartbeats

`Client Heartbeat` messages are sent from Member to Cboe, and `Server Heartbeat` messages are sent from Cboe to Member if no other data has been sent in that direction for one second. Similar to other session level messages, heartbeats from Cboe to the member do not increment the sequence number. If Cboe receives no inbound data or heartbeats for 5 seconds, a `Logout Response` message will be sent and the connection will be terminated. Members 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 member. Cboe will finish sending any queued data for that port, respond with a `Logout Response` message, and close the connection. After receipt of a `Logout Request` message, Cboe will ignore all other inbound (Member to Cboe) messages except for `Client Heartbeat` messages.

## Session Messages

**Table 1. Session Message Types**

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

### Member to Cboe

#### Login Request Message Fields

A `LoginRequest` 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 member. Cboe uses these sequence numbers to determine what outbound (Cboe to Member) traffic, if any, was missed by the member. If NumberOfUnits is 0, it is assumed the member has not received any messages (e.g., start of day).

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

If the member is sending a `LoginRequest` message to a Unit Order Port, Unit Quoting Port, or Unit Purge Port, the only UnitNumber accepted is the number of the port’s unit.

Logins to a BOEv3 convenience session have no limitation on the number of messages to replay on a login. Cboe therefore will not accept a login request on a convenience session having `ReplayInstruction`= D. Logins to a BOEv3 unitized session on the primary login port are limited to the most recent 1000 sequences on BOE3 unitized sessions. Recovery of messages beyond the limit can be accomplished using `ReplayInstruction` = D on an inactive port (normally the secondary or DR port). See Appendix C - Login Playbook for more details.

**Table 1. Login Request Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x0001 (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 Cboe |
| SessionSubId | 16 | 4 | AlphaNumeric | Session Sub Id as supplied by Cboe |
| Password | 20 | 10 | AlphaNumeric | The password associated with the SessionId and SessionSubId. |
| ReplayInstruction | 30 | 1 | Text | Controls replay behavior for unknown units. ‘D’ is exclusively supported on unitized ports that are also inactive. Must be one of: `D` = deep replay of specified unit `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 member has received messages over this port. The value must be 0 or 1 for unitized BOE ports. |
| →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. |

##### Login Request Message Example

**Table 1. Login Request Message Example**

| Field Name | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `B0 E3` | Start of message bytes |
| MessageLength | `23 00` | 35 bytes |
| MessageType | `01 00` | LoginRequest |
| 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" |
| ReplayInstruction | `46` | "F" (Fail) |
| NumberOfUnits | `01` | 1 unit |
| →UnitNumber | `02` | Unit 2 |
| →UnitSequence | `3F 15 00 00` | 5,439 |

#### Logout Request Message Fields

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

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

**Table 1. Logout Request Message Fields**

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

##### Logout Request Message Example

**Table 1. Logout Request Message Example**

| 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 Message Fields

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

**Table 1. Client Heartbeat Message Fields**

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

##### Client Heartbeat Message Example

**Table 1. Client Heartbeat Message Example**

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

### Cboe to Member

#### Login Response Message Fields

`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 Cboe to member sequence number for the specified unit. For unitized ports, only the unit of the port will populate this group (i.e., NumberOfUnits will be 1).

**Table 1. Login Response Message Fields**

| 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 `R` = Replay too Deep `S` = Invalid Session `X` = Invalid replay instruction |
| 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 (member to Cboe) message sequence number processed by Cboe 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 logins having LoginResponseStatus other than A, Q, or R, this will be 0. |
| →UnitNumber | 78 | 1 | Binary | A unit number |
| →UnitSequence | 79 | 4 | Binary | Highest available Cboe to member sequence number for the unit. |

##### Login Response Message Example

**Table 1. Login Response Message Example**

| 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 Message Fields

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

**Table 1. Replay Complete Message Fields**

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

##### Replay Complete Message Example

**Table 1. Replay Complete Message Example**

| 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 Message Fields

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

A `Logout Response` message is also sent for any ports that are connected when the Cboe Options Exchanges shut down. The shut down time for Cboe Options Exchanges is variable each day but is scheduled to occur at 17:30 ET. The message is sent without first receiving a logout request from the Member. The message contains `LogoutReason` = E (End of Day).

**Table 1. Logout Response Message Fields**

| 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 `E` = End Of Day `A` = Administrative `!` = Protocol Violation |
| LogoutReasonText | 13 | 60 | Text | Human-readable text with additional information about the reason for logout. |

##### Logout Response Message Example

**Table 1. Logout Response Message Example**

| 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 Message Fields

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

**Table 1. Server Heartbeat Message Fields**

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

##### Server Heartbeat Message Example

**Table 1. Server Heartbeat Message Example**

| 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

### Member to Cboe

Note that for sequenced messages from Member to Cboe, a sequence number of `0` will always be accepted and is treated as if it were the next expected sequence number.

#### New Order Message Fields

Submission of a new simple (single leg) order to Cboe.

##### NewOrderUSOptionsV1 Message Fields

**Table 1. NewOrderUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x07D1 (2001) |
| MatchingUnit | 6 | 1 | Binary | Zero - from member message |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary | Next sequence number (or zero) |
| ClOrdID | 12 | 20 | Text |  |
| Side | 32 | 1 | Text |  |
| OrderQty | 33 | 4 | Binary |  |
| ClearingFirm | 37 | 4 | Alpha |  |
| ClearingAccount | 41 | 4 | Text |  |
| Price | 45 | 8 | BinaryPrice |  |
| ExecInst | 53 | 1 | Text |  |
| OrdType | 54 | 1 | Text |  |
| TimeInForce | 55 | 1 | Text |  |
| MinQty | 56 | 4 | Binary |  |
| MaxFloor | 60 | 4 | Binary |  |
| Symbol | 64 | 8 | Alphanumeric |  |
| Capacity | 72 | 1 | Text |  |
| RoutingInst | 73 | 4 | Text |  |
| Account | 77 | 16 | Text |  |
| DisplayIndicator | 93 | 1 | Text |  |
| PreventMatch | 94 | 3 | Text |  |
| ExpireTime | 97 | 8 | DateTime |  |
| MaturityDate | 105 | 4 | Date |  |
| StrikePrice | 109 | 8 | BinaryPrice |  |
| PutOrCall | 117 | 1 | Text |  |
| OpenClose | 118 | 1 | Text |  |
| CMTANumber | 119 | 4 | Binary |  |
| TargetPartyID | 123 | 4 | Alpha |  |
| SessionEligibility | 127 | 1 | Text |  |
| AttributedQuote | 128 | 1 | Text |  |
| DisplayRange | 129 | 4 | Binary |  |
| StopPx | 133 | 8 | BinaryPrice |  |
| RoutStrategy | 141 | 6 | Text |  |
| RouteDeliveryMethod | 147 | 3 | Text |  |
| ExDestination | 150 | 1 | Text |  |
| AuctionID | 151 | 8 | Binary |  |
| RoutingFirmID | 159 | 4 | Alpha |  |
| CustomGroupID | 163 | 2 | Binary |  |
| ClearingOptionalData | 165 | 16 | Text |  |
| ClientIDAttr | 181 | 4 | Text |  |
| FrequentTraderID | 185 | 6 | Alphanumeric |  |
| Compression | 191 | 1 | Text |  |
| FloorDestination | 192 | 4 | Text |  |
| FloorRoutingInst | 196 | 1 | Text |  |
| OrderOrigin | 197 | 3 | Alphanumeric |  |
| OrderRouterSubsidy | 200 | 1 | Text |  |
| PriceType | 201 | 1 | Text |  |
| Held | 202 | 1 | Text |  |
| ScratchPad | 203 | 2 | Binary |  |

##### NewOrderShortUSOptionsV1 Message Fields

**Table 1. NewOrderShortUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x07D2 (2002) |
| MatchingUnit | 6 | 1 | Binary | Zero - from member message |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary | Next sequence number (or zero) |
| ClOrdID | 12 | 20 | Text |  |
| Side | 32 | 1 | Text |  |
| OrderQty | 33 | 4 | Binary |  |
| ClearingFirm | 37 | 4 | Alpha |  |
| ClearingAccount | 41 | 4 | Text |  |
| Price | 45 | 8 | BinaryPrice |  |
| ExecInst | 53 | 1 | Text |  |
| OrdType | 54 | 1 | Text |  |
| TimeInForce | 55 | 1 | Text |  |
| MinQty | 56 | 4 | Binary |  |
| MaxFloor | 60 | 4 | Binary |  |
| Symbol | 64 | 8 | Alphanumeric |  |
| Capacity | 72 | 1 | Text |  |
| RoutingInst | 73 | 4 | Text |  |
| Account | 77 | 16 | Text |  |
| DisplayIndicator | 93 | 1 | Text |  |
| PreventMatch | 94 | 3 | Text |  |
| OpenClose | 97 | 1 | Text |  |
| CMTANumber | 98 | 4 | Binary |  |
| SessionEligibility | 102 | 1 | Text |  |
| AttributedQuote | 103 | 1 | Text |  |
| RoutStrategy | 104 | 6 | Text |  |
| ExDestination | 110 | 1 | Text |  |
| AuctionID | 111 | 8 | Binary |  |
| CustomGroupID | 119 | 2 | Binary |  |
| FrequentTraderID | 121 | 6 | Alphanumeric |  |
| ScratchPad | 127 | 2 | Binary |  |

#### New Order Cross Message Fields (C1 and EDGX Only)

A `New Order Cross` message contains the details for both the agency (initiating) and contra side(s) of a cross order (such as an AIM order).`Cross Order Acknowledgment`, `Cross Order Rejected`, and `Cross Order Cancelled` messages will be used by the Exchange to respond to `New Order Cross` messages.

Required Order Attributes:

- Agency order’s Side must match the cross order’s CrossPrioritization
- Each contra-party allocation must have the opposite Side
- Each side’s cumulative AllocQty must equal the cross order’s OrderQty

The first entry in the repeating group is the agency order, followed by a maximum of 10 contra-party allocations. I.e., AllocCnt must be between 2 and 11.

##### NewOrderCrossUSOptionsV1 Message Fields

**Table 1. NewOrderCrossUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x07D3 (2003) |
| MatchingUnit | 6 | 1 | Binary | Zero - from member message |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary | Next sequence number (or zero) |
| CrossID | 12 | 20 | Text |  |
| CrossType | 32 | 1 | Text |  |
| CrossPrioritization | 33 | 1 | Text |  |
| Price | 34 | 8 | BinaryPrice |  |
| OrderQty | 42 | 4 | Binary |  |
| Symbol | 46 | 8 | Alphanumeric |  |
| MaturityDate | 54 | 4 | Date |  |
| StrikePrice | 58 | 8 | BinaryPrice |  |
| PutOrCall | 66 | 1 | Text |  |
| ExecInst | 67 | 1 | Text |  |
| AttributedQuote | 68 | 1 | Text |  |
| TargetPartyID | 69 | 4 | Alpha |  |
| PreventMatch | 73 | 3 | Text |  |
| AutoMatch | 76 | 1 | Text |  |
| AutoMatchPrice | 77 | 8 | BinaryPrice |  |
| LastPriority | 85 | 1 | Text |  |
| RoutingFirmID | 86 | 4 | Alpha |  |
| ClientIDAttr | 90 | 4 | Text |  |
| EquityTradePrice | 94 | 8 | BinaryPrice |  |
| EquityTradeSize | 102 | 4 | Binary |  |
| EquityTradeVenue | 106 | 1 | Text |  |
| EquityTransactTime | 107 | 8 | DateTime |  |
| EquityBuyClearingFirm | 115 | 4 | Alpha |  |
| EquitySellClearingFirm | 119 | 4 | Alpha |  |
| Compression | 123 | 1 | Text |  |
| OrderRouterSubsidy | 124 | 1 | Text |  |
| ScratchPad | 125 | 2 | Binary |  |
| AllocCnt | 127 | 1 | Binary |  |
| → Side | 128 | 1 | Text | (Group repeats AllocCnt times) |
| → AllocQty | 129 | 4 | Binary | (Group repeats AllocCnt times) |
| → ClOrdID | 133 | 20 | Text | (Group repeats AllocCnt times) |
| → Capacity | 153 | 1 | Text | (Group repeats AllocCnt times) |
| → OpenClose | 154 | 1 | Text | (Group repeats AllocCnt times) |
| → GiveUpFirmID | 155 | 4 | Alpha | (Group repeats AllocCnt times) |
| → Account | 159 | 16 | Text | (Group repeats AllocCnt times) |
| → CMTANumber | 175 | 4 | Binary | (Group repeats AllocCnt times) |
| → ClearingAccount | 179 | 4 | Text | (Group repeats AllocCnt times) |
| → ClearingOptionalData | 183 | 16 | Text | (Group repeats AllocCnt times) |
| → FrequentTraderID | 199 | 6 | Alphanumeric | (Group repeats AllocCnt times) |

#### New Complex Instrument Message Fields

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 `Complex Instrument Accepted` message; a `Complex Instrument Rejected` message will be sent if it is not accepted. Complex Orders are restricted to a minimum of 2 legs and a maximum of 16 legs. All legs must have the same underlying product which can be different OSI Roots (i.e., XYZ and XYZ1).

A ClearingFirm must be sent on each `New Complex Instrument` message unless a Default Executing Firm ID is set at the port-level.

##### NewComplexInstrumentUSOptionsV1 Message Fields

**Table 1. NewComplexInstrumentUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x07D5 (2005) |
| MatchingUnit | 6 | 1 | Binary | Zero - from member message |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary | Next sequence number (or zero) |
| ClOrdID | 12 | 20 | Text | ID of the creation request |
| ClearingFirm | 32 | 4 | Alpha | EFID requesting the complex instrument |
| ScratchPad | 36 | 2 | Binary |  |
| LegCnt | 38 | 1 | Binary |  |
| → Symbol | 39 | 8 | Alphanumeric | (Group repeats LegCnt times) |
| → MaturityDate | 47 | 4 | Date | (Group repeats LegCnt times) |
| → StrikePrice | 51 | 8 | BinaryPrice | (Group repeats LegCnt times) |
| → CFICode | 59 | 2 | Alphanumeric | (Group repeats LegCnt times) |
| → RatioQty | 61 | 4 | Binary | (Group repeats LegCnt times) |
| → Side | 65 | 1 | Text | (Group repeats LegCnt times) |

#### New Complex Order Message Fields

A `New Complex Order` message contains the details required to enter an order on a complex instrument created with previously entered `New Complex Instrument` message request. The message is similar to a `New Order` message with an additional repeating group of the positions for each leg. The positions must be in the order returned by the system in the `Complex Instrument Accepted` message response, not the order supplied in the `New Complex Instrument` message request. Complex orders in cross product spreads (i.e., SPX/SPXW, IWM/RUT, DIA/DJX, VIX/VXX, and MNX/NDX) where the products do not operate on the same matching unit cannot leg into the simple book.

##### NewComplexOrderUSOptionsV1 Message Fields (Sunset TBD)

**Table 1. NewComplexOrderUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x07D6 (2006) |
| MatchingUnit | 6 | 1 | Binary | Zero - from member message |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary | Next sequence number (or zero) |
| ClOrdID | 12 | 20 | Text |  |
| Side | 32 | 1 | Text |  |
| OrderQty | 33 | 4 | Binary |  |
| ClearingFirm | 37 | 4 | Alpha |  |
| ClearingAccount | 41 | 4 | Text |  |
| Price | 45 | 8 | BinaryPrice |  |
| ExecInst | 53 | 1 | Text |  |
| OrdType | 54 | 1 | Text |  |
| TimeInForce | 55 | 1 | Text |  |
| Symbol | 56 | 8 | Alphanumeric |  |
| Capacity | 64 | 1 | Text |  |
| RoutingInst | 65 | 4 | Text |  |
| Account | 69 | 16 | Text |  |
| PreventMatch | 85 | 3 | Text |  |
| ExpireTime | 88 | 8 | DateTime |  |
| CMTANumber | 96 | 4 | Binary |  |
| TargetPartyID | 100 | 4 | Alpha |  |
| AttributedQuote | 104 | 1 | Text |  |
| AuctionID | 105 | 8 | Binary |  |
| RoutingFirmID | 113 | 4 | Alpha |  |
| DrillThruProtection | 117 | 8 | BinaryPrice |  |
| UseDrillThruOverride | 125 | 1 | Text |  |
| CustomGroupID | 126 | 2 | Binary |  |
| EquityPartyId | 128 | 4 | Alpha |  |
| ClearingOptionalData | 132 | 16 | Text |  |
| ClientIDAttr | 148 | 4 | Text |  |
| FrequentTraderID | 152 | 6 | Alphanumeric |  |
| SessionEligibility | 158 | 1 | Text |  |
| MaxFloor | 159 | 4 | Binary |  |
| DisplayRange | 163 | 4 | Binary |  |
| ComboOrder | 167 | 1 | Text |  |
| Compression | 168 | 1 | Text |  |
| EquityExDestination | 169 | 1 | Text |  |
| EquityLegShortSell | 170 | 1 | Text |  |
| FloorDestination | 171 | 4 | Text |  |
| FloorRoutingInst | 175 | 1 | Text |  |
| OrderOrigin | 176 | 3 | Alphanumeric |  |
| OrderRouterSubsidy | 179 | 1 | Text |  |
| PriceType | 180 | 1 | Text |  |
| StrategyID | 181 | 1 | Text |  |
| TiedHedge | 182 | 1 | Text |  |
| Held | 183 | 1 | Text |  |
| CrossInitiator | 184 | 4 | Alpha |  |
| CrossOnBehalfofID | 188 | 4 | Alpha |  |
| ScratchPad | 192 | 2 | Binary |  |
| LegCnt | 194 | 1 | Binary | `LegCnt` = 0 (no LegPositionEffect provided) will cause all legs to have a LegPositionEffect of N (none). |
| → LegPositionEffect | 195 | 1 | Text | (Group repeats LegCnt times) |

##### NewComplexOrderUSOptionsV2 Message Fields (Effective TBD)

**Table 1. NewComplexOrderUSOptionsV2 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x07E7 (2023) |
| MatchingUnit | 6 | 1 | Binary | Zero - from member message |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary | Next sequence number (or zero) |
| ClOrdID | 12 | 20 | Text |  |
| Side | 32 | 1 | Text |  |
| OrderQty | 33 | 4 | Binary |  |
| ClearingFirm | 37 | 4 | Alpha |  |
| ClearingAccount | 41 | 4 | Text |  |
| Price | 45 | 8 | BinaryPrice |  |
| ExecInst | 53 | 1 | Text |  |
| OrdType | 54 | 1 | Text |  |
| TimeInForce | 55 | 1 | Text |  |
| Symbol | 56 | 8 | Alphanumeric |  |
| Capacity | 64 | 1 | Text |  |
| RoutingInst | 65 | 4 | Text |  |
| Account | 69 | 16 | Text |  |
| PreventMatch | 85 | 3 | Text |  |
| ExpireTime | 88 | 8 | DateTime |  |
| CMTANumber | 96 | 4 | Binary |  |
| TargetPartyID | 100 | 4 | Alpha |  |
| AttributedQuote | 104 | 1 | Text |  |
| AuctionID | 105 | 8 | Binary |  |
| RoutingFirmID | 113 | 4 | Alpha |  |
| DrillThruProtection | 117 | 8 | BinaryPrice |  |
| UseDrillThruOverride | 125 | 1 | Text |  |
| CustomGroupID | 126 | 2 | Binary |  |
| EquityPartyId | 128 | 4 | Alpha |  |
| ClearingOptionalData | 132 | 16 | Text |  |
| ClientIDAttr | 148 | 4 | Text |  |
| FrequentTraderID | 152 | 6 | Alphanumeric |  |
| SessionEligibility | 158 | 1 | Text |  |
| MaxFloor | 159 | 4 | Binary |  |
| DisplayRange | 163 | 4 | Binary |  |
| ComboOrder | 167 | 1 | Text |  |
| Compression | 168 | 1 | Text |  |
| EquityExDestination | 169 | 1 | Text |  |
| EquityLegShortSell | 170 | 1 | Text |  |
| FloorDestination | 171 | 4 | Text |  |
| FloorRoutingInst | 175 | 1 | Text |  |
| OrderOrigin | 176 | 3 | Alphanumeric |  |
| OrderRouterSubsidy | 179 | 1 | Text |  |
| PriceType | 180 | 1 | Text |  |
| StrategyID | 181 | 1 | Text |  |
| TiedHedge | 182 | 1 | Text |  |
| Held | 183 | 1 | Text |  |
| CrossInitiator | 184 | 4 | Alpha |  |
| CrossOnBehalfofID | 188 | 4 | Alpha |  |
| StopPx | 192 | 8 | BinaryPrice |  |
| StopPxType | 200 | 1 | Text |  |
| ScratchPad | 201 | 2 | Binary |  |
| LegCnt | 203 | 1 | Binary | `LegCnt` = 0 (no LegPositionEffect provided) will cause all legs to have a LegPositionEffect of N (none). |
| → LegPositionEffect | 204 | 1 | Text | (Group repeats LegCnt times) |

##### NewComplexOrderShortUSOptionsV1 Message Fields

**Table 1. NewComplexOrderShortUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x07D7 (2007) |
| MatchingUnit | 6 | 1 | Binary | Zero - from member message |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary | Next sequence number (or zero) |
| ClOrdID | 12 | 20 | Text |  |
| Side | 32 | 1 | Text |  |
| OrderQty | 33 | 4 | Binary |  |
| ClearingFirm | 37 | 4 | Alpha |  |
| ClearingAccount | 41 | 4 | Text |  |
| Price | 45 | 8 | BinaryPrice |  |
| ExecInst | 53 | 1 | Text |  |
| OrdType | 54 | 1 | Text |  |
| TimeInForce | 55 | 1 | Text |  |
| Symbol | 56 | 8 | Alphanumeric |  |
| Capacity | 64 | 1 | Text |  |
| RoutingInst | 65 | 4 | Text |  |
| Account | 69 | 16 | Text |  |
| PreventMatch | 85 | 3 | Text |  |
| CMTANumber | 88 | 4 | Binary |  |
| TargetPartyID | 92 | 4 | Alpha |  |
| AuctionID | 96 | 8 | Binary |  |
| RoutingFirmID | 104 | 4 | Alpha |  |
| CustomGroupID | 108 | 2 | Binary |  |
| EquityPartyId | 110 | 4 | Alpha |  |
| FrequentTraderID | 114 | 6 | Alphanumeric |  |
| SessionEligibility | 120 | 1 | Text |  |
| MaxFloor | 121 | 4 | Binary |  |
| FloorDestination | 125 | 4 | Text |  |
| FloorRoutingInst | 129 | 1 | Text |  |
| ScratchPad | 130 | 2 | Binary |  |
| LegCnt | 132 | 1 | Binary | `LegCnt`= 0 (no LegPositionEffect provided) will cause all legs to have a LegPositionEffect of N (none). |
| → LegPositionEffect | 133 | 1 | Text | (Group repeats LegCnt times) |

#### New Order Cross Multileg Message Fields (C1 and EDGX Only)

A `New Order Cross Multileg` message contains the details for both the agency (initiating) and contra side(s) of a multileg cross order (such as an AIM order).

`Cross Order Acknowledgment`, `Cross Order Rejected`, and `Cross Order Cancelled` message types will be used by the Exchange to respond to `New Order Cross Multileg` messages.

Required Order Attributes:

- Agency order’s Side must match the cross order’s CrossPrioritization
- Each contra-party allocation must have the opposite Side
- Each side’s cumulative AllocQty must equal the cross order’s OrderQty

The first entry in the allocation repeating group is the agency order, followed by a maximum of 10 contra-party allocations. I.e., AllocCnt must be between 2 and 11.

AllocLegCnt is the AllocCnt times the number of symbol legs. The ordering of LegPositionEffect is "allocation major, leg minor"; the legs of each allocation are described before moving on to the next allocation. The leg ordering matches the definition seen in the New Complex Instrument Accepted message (or seen in the Complex Instrument Definition PITCH message).

##### NewOrderCrossMultilegUSOptionsV1 Message Fields

**Table 1. NewOrderCrossMultilegUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x07D8 (2008) |
| MatchingUnit | 6 | 1 | Binary | Zero - from member message |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary | Next sequence number (or zero) |
| CrossID | 12 | 20 | Text |  |
| CrossType | 32 | 1 | Text |  |
| CrossPrioritization | 33 | 1 | Text |  |
| Price | 34 | 8 | BinaryPrice |  |
| OrderQty | 42 | 4 | Binary |  |
| Symbol | 46 | 8 | Alphanumeric |  |
| AttributedQuote | 54 | 1 | Text |  |
| TargetPartyID | 5 | 4 | Alpha |  |
| PreventMatch | 59 | 3 | Text |  |
| AutoMatch | 62 | 1 | Text |  |
| AutoMatchPrice | 63 | 8 | BinaryPrice |  |
| LastPriority | 71 | 1 | Text |  |
| RoutingFirmID | 72 | 4 | Alpha |  |
| ClientIDAttr | 76 | 4 | Text |  |
| EquityTradePrice | 80 | 8 | BinaryPrice |  |
| EquityTradeSize | 88 | 4 | Binary |  |
| EquityTradeVenue | 92 | 1 | Text |  |
| EquityTransactTime | 93 | 8 | DateTime |  |
| EquityBuyClearingFirm | 101 | 4 | Alpha |  |
| EquitySellClearingFirm | 105 | 4 | Alpha |  |
| DrillThruProtection | 109 | 8 | BinaryPrice |  |
| UseDrillThruOverride | 117 | 1 | Text |  |
| EquityExDestination | 118 | 1 | Text |  |
| Compression | 119 | 1 | Text |  |
| OrderRouterSubsidy | 120 | 1 | Text |  |
| CrossInitiator | 121 | 4 | Alpha |  |
| CrossOnBehalfofID | 125 | 4 | Alpha |  |
| ScratchPad | 129 | 2 | Binary |  |
| AllocCnt | 131 | 1 | Binary |  |
| AllocLegCnt | 132 | 1 | Binary |  |
| → Side | 133 | 1 | Text | (Group repeats AllocCnt times) |
| → AllocQty | 134 | 4 | Binary | (Group repeats AllocCnt times) |
| → ClOrdID | 138 | 20 | Text | (Group repeats AllocCnt times) |
| → Capacity | 158 | 1 | Text | (Group repeats AllocCnt times) |
| → GiveUpFirmID | 159 | 4 | Alpha | (Group repeats AllocCnt times) |
| → Account | 163 | 16 | Text | (Group repeats AllocCnt times) |
| → CMTANumber | 179 | 4 | Binary | (Group repeats AllocCnt times) |
| → ClearingAccount | 183 | 4 | Text | (Group repeats AllocCnt times) |
| → ClearingOptionalData | 187 | 16 | Text | (Group repeats AllocCnt times) |
| → EquityPartyId | 203 | 4 | Alpha | (Group repeats AllocCnt times) |
| → EquityLegShortSell | 207 | 1 | Text | (Group repeats AllocCnt times) |
| → FrequentTraderID | 208 | 6 | Alphanumeric | (Group repeats AllocCnt times) |
| → LegPositionEffect | 214 | 1 | Text | (Group repeats AllocLegCnt times) |

#### Cancel Order Message Fields

Request to cancel a single order.

A single order cancellation references the ClOrdID from a previous order (OrigClOrdID field). A `Cancel Order` message cannot be used to cancel a single quote: referencing a previous OrderID from a quote will be rejected.

`Cancel Order` messages for GTC and GTD orders may continue to be issued anytime after the trading session ends. All other order message types received after the market closes will be rejected. See Port Types for more details on when orders are allowed to be cancelled following the close of trading.

##### CancelOrderUSOptionsV1 Message Fields

**Table 1. CancelOrderUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x07DA (2010) |
| MatchingUnit | 6 | 1 | Binary | Zero - from member message |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary | Next sequence number (or zero) |
| OrigClOrdID | 12 | 20 | Text |  |
| ClearingFirm | 32 | 4 | Alpha |  |
| RoutingFirmID | 36 | 4 | Alpha |  |
| ScratchPad | 40 | 2 | Binary |  |

#### Mass Cancel Order Message Fields

Request a mass cancellation of a group of orders. Note that this does not apply to open orders across multiple sessions.

`Mass Cancel Order` messages for GTC and GTD orders may continue to be issued anytime after the trading session ends. All other order message types received after the market closes will be rejected. See Port Types for more details on when orders are allowed to be cancelled following the close of trading.

- If the Clearing Firm Filter is set to `F`, the ClearingFirm field must not be blank or the Cancel Order request will be rejected.
- If the Acknowledgment Style is set to `S` or `B`, or in combination with `M`, the MassCancelId must not be blank or the `Mass Cancel Order` message request will be rejected.
- If the RiskRoot field is not blank then only orders for instruments associated with the product (e.g., SPX) are cancelled.
- If Lockout Instruction is set to `L` and the ProductName field blank, a Firm-level Risk Reset is required to clear the Lockout condition. If Lockout Instruction is set to `L` and the RiskRoot field is not blank, a Product level reset is required. Effective 09/28/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.

When specifying the RiskRoot field, using the underlying symbol is strongly recommended. Mass cancellations are always performed at the risk root (underlying) level.

The system limits the rate at which identical `Mass Cancel Order` requests can be submitted to the system. Requests are restricted to 10 messages per second per port. An identical `Mass Cancel Order` 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.

##### MassCancelOrderUSOptionsV1 Message Fields

**Table 1. MassCancelOrderUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x07DF (2015) |
| MatchingUnit | 6 | 1 | Binary | Zero - from member message |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary | Next sequence number (or zero) |
| MassCancelID | 12 | 20 | Text |  |
| ClearingFirm | 32 | 4 | Alpha |  |
| RoutingFirmID | 36 | 4 | Alpha |  |
| RiskRoot | 40 | 6 | Text |  |
| MassCancelInst | 46 | 8 | Text |  |
| SendTime | 54 | 8 | DateTime |  |
| ScratchPad | 62 | 2 | Binary |  |

#### Modify Order Message Fields

Request to modify an order. Price, OrderQty, OrdType, MaxFloor (BZX, C1, and C2 only), and StopPx may be adjusted. OrdType may be adjusted from Limit to Market (market and stop/stop limit orders are not supported during GTH or Curb sessions).

- Time priority will be maintained on an order modification in the following cases:
  - A decrease in OrderQty with no other changes
  - An update to StopPx on an un-elected stop order with no other changes
  - An update to MaxFloor with no other changes
- An order modification combining two or more of the specific items above will not lose priority.
- An order modification involving one of the items above and changes to any other attribute will lose priority.
- An order modification with no change to any attribute will lose priority.

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 Member in total control of the share exposure of the order.

A `Modify Order` message should not be issued until the `Order Acknowledgment` message for the previous `New Order` or `Order Modified` message for the previous `Modify Order` message has been received. The BOE handler will reject a new `Modify Order` message if it has not been accepted or it has not seen the result of the prior modification from the Matching Engine. However, `Modify Order` message requests that merely reduce OrderQty may be overlapped if the existing ClOrdID is reused, as long as the trading identifier has not been opted-in to daily limit trading risk controls. This is the only case where reuse of the ClOrdID is allowed.

A maximum of 1,679,615 `Modify Order` message 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` message request.

| BOEv2 → BOEv3 Migration Note |
|---|
| The BOEv3 `Modify Order` message must specify all values to apply to the update. This is unlike BOEv2, wherein the absence of optional fields implied that the values would be carried forward from the version of the order being modified (blank fields in BOEv3 will have port defaults applied when available). |

##### ModifyOrderUSOptionsV1 Message Fields

**Table 1. ModifyOrderUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x07DB (2011) |
| MatchingUnit | 6 | 1 | Binary | Zero - from member message |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary | Next sequence number (or zero) |
| ClOrdID | 12 | 20 | Text |  |
| OrigClOrdID | 32 | 20 | Text |  |
| ClearingFirm | 52 | 4 | Alpha |  |
| RoutingFirmID | 56 | 4 | Alpha |  |
| OrderQty | 60 | 4 | Binary |  |
| Price | 64 | 8 | BinaryPrice |  |
| OrdType | 72 | 1 | Text |  |
| MaxFloor | 73 | 4 | Binary |  |
| StopPx | 77 | 8 | BinaryPrice |  |
| CancelOrigOnReject | 85 | 1 | Text |  |
| Reserved | 86 | 41 | Binary | Must be null-filled (0x00) |
| ScratchPad | 127 | 2 | Binary |  |

#### Quote Update Message Fields

Request to enter or update one or more quotes. `Quote Update` message requests will be forwarded in their entirety to the matching engine instance as a single message and will be applied in a single transaction. The system will only accept `Quote Update` requests entered via a BOE Bulk Quoting port that are marked with the `Capacity`= M (Market Maker). A valid registered Market-Maker account value must be provided in the ClearingAccount field or the system will respond with the `QuoteUpdateRejected` message containing `QuoteRejectReason` = C (Invalid Clearing).

All options in a single `Quote Update` message must trade under a single risk root. Requests which include options trading under multiple risk 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. To delete a quote, send an update with a zero price and/or size.

Quotes may utilize simple options only; complex options quotes may not be submitted.

By default quotes are valid for a given trading date, which may span multiple calendar dates in the event of a holiday. Quotes may be cancelled at the end of a given trading segment rather than carried forward to the next segment by updating the Multi-Segment Holiday Day Order Handling Port attribute.

Quotes may be marked post only. Quotes that cross the NBBO or displayed Cboe book will be accepted if within a configurable buffer range through the NBBO or displayed Cboe book. The buffer is set to 5% with a minimum of $0.05 and a maximum of $1.00. If a quote would be displayed at a price that locks the NBBO, it will be accepted/slid or rejected based on the PostingInstruction on the quote. Quotes can be opted out of the price-sliding functionality by specifying N or R in the PostingInstruction field on the quote message.

On BZX Options only, quote prices at non-displayable increments are permitted. Prices will be adjusted to the most aggressive non-locking price. Quotes may work (but not display) to lock an away market. Once posted, quotes act as a Display Price Sliding order. C2 and EDGX quotes act as Price Adjust orders.

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.

The PreventMatch field may not be specified on the `Quote Update` message and Match Trade Prevention is only available if defaulted at the port level. For Bulk Quoting ports, only Cancel Newest, Cancel Oldest, or Cancel Both are permitted. If a Bulk Quoting port is not configured with both a default MTP Modifier and Unique ID Level, Match Trade Prevention will be disabled.

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.

Any `Quote Update` message with a QuoteCnt larger than '1' and a PostingInstruction = `I` (Book Only, IOC) will be rejected with a `Quote Update Rejected`message having a quote reject reason code of `L` (Invalid QuoteCnt).

The `Quote Execution` message will be the only Quote related message available over ODROP and FIXDROP.

`Quote Update` message 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 will be maintained on a quote modification if there is a decrease in OrderQty with no other changes.
- A quote modification decreasing size and changes to any other attribute will lose priority.
- A quote modification with no change to any attribute will lose priority.

##### QuoteUpdateUSOptionsV1 Message Fields

**Table 1. QuoteUpdateUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x07DC (2012) |
| MatchingUnit | 6 | 1 | Binary | Zero - from member message |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary | Next sequence number (or zero) |
| QuoteUpdateID | 12 | 16 | Text |  |
| ClearingFirm | 28 | 4 | Alpha |  |
| ClearingAccount | 32 | 4 | Text |  |
| CMTANumber | 36 | 4 | Binary |  |
| Account | 40 | 16 | Text |  |
| CustomGroupID | 56 | 2 | Binary |  |
| SendTime | 58 | 8 | DateTime |  |
| PostingInstruction | 66 | 1 | Alpha |  |
| SessionEligibility | 67 | 1 | Text |  |
| SizeModifier | 68 | 1 | Text |  |
| ScratchPad | 69 | 2 | Binary |  |
| QuoteCnt | 71 | 1 | Binary |  |
| → QuoteSymbol | 72 | 6 | Alphanumeric | (Group repeats QuoteCnt times) |
| → Side | 78 | 1 | Text | (Group repeats QuoteCnt times) |
| → OpenClose | 79 | 1 | Text | (Group repeats QuoteCnt times) |
| → Price | 80 | 8 | BinaryPrice | (Group repeats QuoteCnt times) |
| → OrderQty | 88 | 4 | Binary | (Group repeats QuoteCnt times) |
| → ScratchPad | 92 | 2 | Binary | (Group repeats QuoteCnt times) |

#### Quote Update (Short) Message Fields

A shorter version of `Quote Update` messages which restricts the information which can be presented. Uses less bandwidth than the `Quote Update` message but messages presented to the Matching Engine are identical between both `Quote Update` and `Quote Update (Short)` messages. The system will only accept `Quote Update` requests entered via a BOE Bulk Quoting port that are marked with the `Capacity`= M (Market Maker).

`Quote Update (Short)` messages do not allow sending Account but a default for this field may be set at the port level. CMTANumber may never be included on a `Quote Update (Short)` message.

This message uses a smaller format Price and OrderQty on each quote update.

All other comments in Quote Update Message Fields also apply to `Quote Update (Short)` messages.

##### QuoteUpdateShortUSOptionsV1 Message Fields

**Table 1. QuoteUpdateShortUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x07DD (2013) |
| MatchingUnit | 6 | 1 | Binary | Zero - from member message |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary | Next sequence number (or zero) |
| QuoteUpdateID | 12 | 16 | Text |  |
| ClearingFirm | 28 | 4 | Alpha |  |
| ClearingAccount | 32 | 4 | Text |  |
| CustomGroupID | 36 | 2 | Binary |  |
| SendTime | 38 | 8 | DateTime |  |
| PostingInstruction | 46 | 1 | Alpha |  |
| SessionEligibility | 47 | 1 | Text |  |
| SizeModifier | 48 | 1 | Text |  |
| ScratchPad | 49 | 2 | Binary |  |
| QuoteCnt | 51 | 1 | Binary |  |
| → QuoteSymbol | 52 | 6 | Alphanumeric | (Group repeats QuoteCnt times) |
| → Side | 58 | 1 | Text | (Group repeats QuoteCnt times) |
| → OpenClose | 59 | 1 | Text | (Group repeats QuoteCnt times) |
| → Price | 60 | 4 | ShortBinaryPrice | (Group repeats QuoteCnt times) |
| → OrderQty | 64 | 2 | Binary | (Group repeats QuoteCnt times) |
| → ScratchPad | 66 | 2 | Binary | (Group repeats QuoteCnt times) |

#### Complex Quote Update Message Fields (C1 Only)

Request to enter or update one or more quotes for quotable complex options. Quotable complex instruments are defined by the exchange and are disseminated on U.S. Options Complex Multicast PITCH and U.S. Options Complex Multicast TOP data feeds as Exchange Designated `Complex Instrument Definition` messages.

`Complex Quote Update` message requests will be forwarded in their entirety to the matching engine instance as a single message and will be applied in a single transaction. The system will only accept `Complex Quote Update` message requests entered via a BOE3 Bulk Quoting port that are marked with the Capacity value of `M`= Market Maker. A valid registered Market-Maker account value must be provided in the ClearingAccount field or the system will respond with the `Quote Update Rejected` message containing the QuoteRejectReason value of `C`= InvalidClearing.

All options in a single `Complex Quote Update` message must trade under a single risk root. Requests which include options trading under multiple risk roots will be rejected in their entirety.

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

Complex quote requests are one-sided. To delete a quote, send an update with a zero size.

`Complex Quote Update` messages may be submitted for exchange designated complex options only; simple options quotes and quotes for complex options that are not exchange designated complex options may not be submitted. One or more unsupported options presented in the message repeating group will cause the `Complex Quote Update` message to be rejected in its entirety with a `Quote Update Rejected` message being returned to the user.

By default, complex quotes are valid for a given trading date, which may span multiple calendar dates in the event of a holiday. Complex quotes may be cancelled at the end of a given trading segment rather than carried forward to the next segment by updating the Multi-Segment Holiday Day Order Handling Port attribute.

Complex quotes are post-only. Individual quotes in a `Complex Quote Update` message that lock or cross the displayed Cboe complex book or SBBO will be rejected. Each individual quote that is rejected for this reason is indicated to the user with the QuoteResult value `P` = Rejected, can't post in the associated `Quote Update Acknowledgment` message.

If a complex quote modification is rejected, the resting complex 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.

The PreventMatch field may not be specified on the `Complex Quote Update` message, and Match Trade Prevention is only available if defaulted at the port level.

Executions involving complex quotes submitted using the `Complex Quote Update` message are reported to the user via the `Complex Quote Execution` message.

The `Complex Quote Execution` message will be the only complex quote related message available over ODROP and FIXDROP.

- Time priority will be maintained on a complex quote modification if there is a decrease in OrderQty with no other changes.
- A complex quote modification decreasing size and changes to any other attribute will lose priority.
- A complex quote modification with no change to any attribute will lose priority.

##### ComplexQuoteUpdateUSOptionsV1 Message Fields

**Table 1. Complex QuoteUpdateUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 2017, 0x07E1 |
| MatchingUnit | 6 | 1 | Binary | Zero (from member message) |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary |  |
| QuoteUpdateID | 12 | 16 | Text |  |
| ClearingFirm | 28 | 4 | Alpha |  |
| ClearingAccount | 32 | 4 | Text |  |
| CMTANumber | 36 | 4 | Binary |  |
| Account | 40 | 16 | Text |  |
| CustomGroupID | 56 | 2 | Binary |  |
| SendTime | 58 | 8 | DateTime |  |
| PostingInstruction | 66 | 1 | Alpha |  |
| SessionEligibility | 67 | 1 | Text |  |
| SizeModifier | 68 | 1 | Text |  |
| Scratchpad | 69 | 2 | Binary |  |
| QuoteCnt | 71 | 1 | Binary |  |
| → QuoteSymbol | 72 | 6 | Alphanumeric | (Group repeats QuoteCnt times) |
| → Side | 78 | 1 | Text | (Group repeats QuoteCnt times) |
| → OpenClose | 79 | 1 | Text | (Group repeats QuoteCnt times) |
| → Price | 80 | 8 | BinaryPrice | (Group repeats QuoteCnt times) |
| → OrderQty | 88 | 4 | Binary | (Group repeats QuoteCnt times) |
| → Scratchpad | 92 | 2 | Binary | (Group repeats QuoteCnt times) |

#### Complex Quote Update Short Message Fields (C1 Only)

A shorter version of `Complex Quote Update` messages which restricts the information which can be presented. Uses less bandwidth than the `Complex Quote Update` message but messages presented to the Matching Engine are identical between both `Complex Quote Update` and `Complex Quote Update (Short)`messages. The system will only accept `Complex Quote Update` requests entered via a BOE3 Bulk Quoting port that are marked with the Capacity =`M (Market Maker)`.

`Complex Quote Update (Short)` messages do not allow sending Account but a default for this field may be set at the port level.

CMTANumber cannot be specified by a `Complex Quote Update (Short)` message.

This message uses a smaller format Price and OrderQty on each `Complex Quote Update`.

All other comments in `Complex Quote Update` also apply to `Complex Quote Update (Short)` messages.

##### ComplexQuoteUpdateShortUSOptionsV1 Message Fields

**Table 1. ComplexQuoteUpdateShortUSOptionsV1 Message Fields**

| Field | Offset | Length | Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 2018, 0x07E2 |
| MatchingUnit | 6 | 1 | Binary | Zero (from member message) |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary |  |
| QuoteUpdateID | 12 | 16 | Text |  |
| ClearingFirm | 28 | 4 | Alpha |  |
| ClearingAccount | 32 | 4 | Text |  |
| CustomGroupID | 36 | 2 | Binary |  |
| SendTime | 38 | 8 | DateTime |  |
| PostingInstruction | 46 | 1 | Alpha |  |
| SessionEligibility | 47 | 1 | Text |  |
| SizeModifier | 48 | 1 | Text |  |
| Scratchpad | 49 | 2 | Binary |  |
| QuoteCnt | 51 | 1 | Binary |  |
| → QuoteSymbol | 52 | 6 | Alphanumeric | (Group repeats QuoteCnt times) |
| → Side | 58 | 1 | Text | (Group repeats QuoteCnt times) |
| → OpenClose | 59 | 1 | Text | (Group repeats QuoteCnt times) |
| → Price | 60 | 4 | ShortBinaryPrice | (Group repeats QuoteCnt times) |
| → OrderQty | 64 | 2 | Binary | (Group repeats QuoteCnt times) |
| → Scratchpad | 66 | 2 | Binary | (Group repeats QuoteCnt times) |

#### Purge Orders Message Fields

The `PurgeOrdersUSOptionsV2`message supported on C1, C2, and EDGX Options Exchanges.

Request to cancel a group of orders across all the firm’s sessions. This differs from a mass cancel request sent via a `Mass Cancel Order` message as the purge is applied across all of the firm’s sessions, not just the session on which the message was received.

`Purge Orders` message requires the MassCancelInst field to be populated. The ClearingFirm (EFID) is also required if a list of configured/allowed EFIDS has not been configured on the session. If a list of configured EFIDs is present, sending a blank (0x00) ClearingFirm value along with setting the first character of MassCancelInst to `A`will result in the purge applying to all configured EFIDs. In addition, a firm may choose to further filter the purge to target specific orders using either the CustomGroupID or RiskRoot fields. If both RiskRoot and a list of CustomGroupID values are specified, the `Purge Orders` message request will be rejected. The items below should also be considered.

- Users must specify the MassCancelId if the Acknowledgement Style is set to `S` or `B`.
- Users may Initiate a self-imposed, risk lockout using the MassCancelInst field.
- EFID values specified in the ClearingFirm field that are not allowed to clear for the firm will be rejected.
- On BZX , Purge messages are available only on a unitized purge port. Note that this may result in self-imposed, risk lockouts occurring on the selected units while other units are still trading.
- On C1, C2, and EDGX , CustomGroupID or EFID ( ClearingFirm ) purges with no RiskRoot may be directed to a specific matching unit using the TargetMatchingUnit field. If TargetMatchingUnit is zero or not specified, these purge types will be sent to all matching units starting with unit 1. Note that this may result in self-imposed, risk lockouts occurring on select units while other units are still trading.

When specifying the RiskRoot field, using the underlying symbol is strongly recommended. Mass cancellations are always performed at the risk root (underlying) level.

All Members that send purges must include the SendTime field. This is required to ensure that a valid cancellation send time is captured and reported to CAT.

The system limits the rate at which identical `Purge Orders` requests can be submitted to the system. Requests are restricted to 10 messages per second per port.

An identical purge 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.

##### PurgeOrdersUSOptionsV2 Message Fields

**Table 1. PurgeOrdersUSOptionsV2 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 2021, 0x07E5 |
| MatchingUnit | 6 | 1 | Binary | Zero - from member message |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary |  |
| MassCancelID | 12 | 20 | Text |  |
| ClearingFirm | 32 | 4 | Alpha |  |
| RoutingFirmID | 36 | 4 | Alpha |  |
| RiskRoot | 40 | 6 | Text |  |
| MassCancelInst | 46 | 8 | Text |  |
| SendTime | 54 | 8 | DateTime |  |
| TargetMatchingUnit | 62 | 1 | Binary |  |
| Scratchpad | 63 | 2 | Binary |  |
| CustomGroupIDCnt | 65 | 1 | Binary |  |
| → CustomGroupID | 66 | 2 | Binary | (Repeats CustomGroupIDCnt times) |

#### Reset Risk Message Fields

Reset or release Firm, Risk Root, or Custom Group ID level lockout conditions resulting from risk profile trips or self-imposed lockouts issued via `Cancel Order` or `Purge Orders` messages.

When specifying the RiskRoot field, using the underlying symbol is strongly recommended. Risk Resets are always performed at the risk root (underlying) level.

Only one unique risk reset of a given type (EFID Group, EFID, Risk Root, CustomGroupID, and TargetMatchingUnit) is allowed per 100 milliseconds per port. 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 100 milliseconds has elapsed. This restriction is designed to safeguard the trading platform from excessive risk messaging. On C1 only, if a risk limit is tripped or manually locked out at the end of the RTH session, the trip/lockout will persist into the Curb session.

Using RiskRoot and TargetMatchingUnit at the same time will result in a reject with `RiskResetResult`= M, even if TargetMatchingUnit is otherwise correct for the given RiskRoot. Either RiskRoot should be empty (NUL filled) or TargetMathchingUnit should be zero.

##### ResetRiskUSOptionsV1 Message Fields

**Table 1. ResetRiskUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x07DE (2014) |
| MatchingUnit | 6 | 1 | Binary | Zero - from member message |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary | Next sequence number (or zero) |
| RiskStatusID | 12 | 16 | Text |  |
| RiskReset | 28 | 8 | Text |  |
| ClearingFirm | 36 | 4 | Alpha | Risk will be reset for this EFID. Resets a self-imposed EFID-level lockout initiated using a mass cancel or purge request. Required on all resets. |
| RiskRoot | 40 | 6 | Text |  |
| TargetMatchingUnit | 46 | 1 | Binary |  |
| CustomGroupID | 47 | 2 | Binary |  |
| ScratchPad | 49 | 2 | Binary |  |

#### Floor Trade Confirmation Message Fields (C1 Only)

TPHs are encouraged to use `Floor Trade Confirmation` messages to respond to `Floor Trade Notification` messages if they agree with the terms of the trade. Alternatively, an `Add Floor Trade` message may be used to enter their version of the floor trade. If the floor trade notification is not known to the user (for example, if the TPH is misidentified as a contra party to a floor trade), the message can be disregarded; a response is not required.

The Exchange will respond to a `Floor Trade Confirmation` message with an`Order Execution` message or `Floor Trade Confirmation Rejected` message.

##### FloorTradeConfirmationUSOptionsV1 Message Fields

**Table 1. FloorTradeConfirmationUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Description |  |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 2020, 0x07E4 |
| MatchingUnit | 6 | 1 | Binary | Zero (from member message) |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary |  |
| ClOrdID | 12 | 20 | Text |  |
| ExecID | 32 | 8 | Binary |  |
| Symbol | 40 | 8 | Alphanumeric |  |
| PutOrCall | 48 | 1 | Text |  |
| StrikePrice | 49 | 8 | BinaryPrice |  |
| MaturityDate | 57 | 4 | Date |  |
| ReportTime | 61 | 8 | DateTime |  |
| PriceType | 69 | 1 | Text |  |
| Scratchpad | 70 | 2 | Binary |  |

#### Add Floor Trade Message Fields (C1 Only)

TPHs having in-person Market Makers on the Cboe trading floor can enter their version of a floor trade using the`Add Floor Trade` message.

This message may be used to report any floor trades but is primarily used to report floor trades between Market Makers. TPHs are encouraged to use `Floor Trade Confirmation` messages to respond to floor broker allocations (`Floor Trade Notification` messages) if they agree with the terms of the trade.

The Exchange will respond to an `Add Floor Trade` message with an `Add Floor Trade Rejected` message or an `Order acknowledgment` message followed by one or more `Order Execution` messages.

##### AddFloorTradeUSOptionsV1 Message Fields

**Table 1. AddFloorTradeUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 2019, 0x07E3 |
| MatchingUnit | 6 | 1 | Binary | Zero (from member message) |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary |  |
| ClOrdID | 12 | 20 | Text |  |
| Symbol | 32 | 8 | Alphanumeric |  |
| PutOrCall | 40 | 1 | Text |  |
| StrikePrice | 41 | 8 | BinaryPrice |  |
| MaturityDate | 49 | 4 | Date |  |
| MultilegReportingType | 53 | 1 | Text |  |
| ComboOrder | 54 | 1 | Text |  |
| Account | 55 | 16 | Text |  |
| ClearingOptionalData | 71 | 16 | Text |  |
| ClearingAccount | 87 | 4 | Text |  |
| CMTANumber | 91 | 4 | Binary |  |
| FloorTraderAcronym | 95 | 3 | Alpha |  |
| Side | 98 | 1 | Text |  |
| OrderQty | 99 | 4 | Binary |  |
| Price | 103 | 8 | BinaryPrice |  |
| ReportTime | 111 | 8 | DateTime |  |
| OpenClose | 119 | 1 | Text |  |
| FloorTradeTime | 120 | 8 | DateTime |  |
| ContraTrader | 128 | 4 | Alphanumeric |  |
| PriceType | 132 | 1 | Text |  |
| Scratchpad | 133 | 2 | Binary |  |

#### Delete Floor Trade Message Fields (C1 Only)

TPHs with in-person Market Makers on the Cboe trading floor can request the deletion of a floor trade using the `Delete Floor Trade` message type. The trade report requested for deletion will be identified by the ExecId. The TPH entering the floor trade deletion message must be on the specified side of the identified trade.

The Exchange will respond to a `Delete Floor Trade` message with a `Delete Floor Trade Rejected` message or with a `Delete Floor Trade acknowledgment` message if the floor trade report is successfully deleted.

##### DeleteFloorTradeUSOptionsV1 Message Fields

**Table 1. DeleteFloorTradeUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 2022, 0x07E6 |
| MatchingUnit | 6 | 1 | Binary | Zero (from member message) |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary |  |
| ClOrdID | 12 | 20 | Text |  |
| ExecID | 32 | 8 | Binary |  |
| Symbol | 40 | 8 | Alphanumeric |  |
| PutOrCall | 48 | 1 | Text |  |
| StrikePrice | 49 | 8 | BinaryPrice |  |
| MaturityDate | 57 | 4 | Date |  |
| Side | 61 | 1 | Text |  |
| Scratchpad | 62 | 2 | Binary |  |

### Cboe to Member

`Order Acknowledgment`, `Order Modified`, and other messages sent from Cboe to Member

#### Order Acknowledgment Message Fields

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

##### OrderAcknowledgementUSOptionsV1 Message Fields

**Table 1. OrderAcknowledgementUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09C5 (2501) |
| MatchingUnit | 6 | 1 | Binary | Unit number which accepted the order |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary |  |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| ClOrdID | 22 | 20 | Text |  |
| OrderID | 42 | 8 | Binary |  |
| Side | 50 | 1 | Text |  |
| Price | 51 | 8 | BinaryPrice |  |
| Symbol | 59 | 8 | Alphanumeric |  |
| ClearingFirm | 67 | 4 | Alpha |  |
| LeavesQty | 71 | 4 | Binary |  |
| DisplayPrice | 75 | 8 | BinaryPrice |  |
| WorkingPrice | 83 | 8 | BinaryPrice |  |
| BaseLiquidityIndicator | 91 | 1 | Text |  |
| SubLiquidityIndicator | 92 | 1 | Text |  |
| RoutingFirmID | 93 | 4 | Alpha |  |
| RequestReceivedTime | 97 | 8 | DateTime |  |

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

#### Cross Order Acknowledgment Message Fields (C1 and EDGX Only)

`Cross Order Acknowledgment` messages are sent in response to `New Order Cross` and `New Order Cross Multileg` messages. The message corresponds to a FIX Execution Report with ExecType (150) = 0 (New). In FIX, multiple execution reports could be generated from one new cross order message.

##### CrossOrderAcknowledgmentUSOptionsV1 Message Fields

**Table 1. CrossOrderAcknowledgmentUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09C6 (2502) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary |  |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| CrossID | 22 | 20 | Text |  |
| AuctionID | 42 | 8 | Binary |  |
| Price | 50 | 8 | BinaryPrice |  |
| Symbol | 58 | 8 | Alphanumeric |  |
| OrderQty | 66 | 4 | Binary |  |
| RoutingFirmID | 70 | 4 | Alpha |  |
| RequestReceivedTime | 74 | 8 | DateTime |  |
| AllocCnt | 82 | 1 | Binary |  |
| → ClOrdID | 83 | 20 | Text |  |
| → OrderID | 103 | 8 | Binary |  |
| → Side | 111 | 1 | Text |  |
| → AllocQty | 112 | 4 | Binary |  |
| → GiveUpFirmID | 116 | 4 | Alpha |  |

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

#### Quote Update Acknowledgment Message Fields

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

For quotes which may remove liquidity or which may post and cause additional Matching Engine action to be taken, such as the early termination of an in progress auction, QuoteResult values of `D` or `d` will be returned. In these cases, executions, cancellations, or modifications (as needed) will immediately follow as additional messages. PITCH messaging behavior may also change (e.g. Delete+Add rather than standard Order Modified) for these cases to ensure correct sequencing of events.

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. An order 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 sent to modify the PostingInstruction will be assigned a new OrderID if there is an existing quote in that symbol on that port and for that EFID.

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

##### QuoteUpdateAcknowledgementUSOptionsV1 Message Fields

**Table 1. QuoteUpdateAcknowledgementUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09D5 (2517) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary | Zero - unsequenced application message |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| QuoteUpdateID | 22 | 16 | Text |  |
| RequestReceivedTime | 38 | 8 | DateTime |  |
| QuoteCnt | 46 | 1 | Binary |  |
| → OrderID | 47 | 8 | Binary | (Group repeats QuoteCnt times) |
| → QuoteResult | 55 | 1 | Text | (Group repeats QuoteCnt times) |
| → SubLiquidityIndicator | 56 | 1 | Text | (Group repeats QuoteCnt times) |
| → QuoteRejectSubReason | 57 | 1 | Text | (Group repeats QuoteCnt times) |

#### Order Rejected Message Fields

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

##### OrderRejectedUSOptionsV1 Message Fields

**Table 1. OrderRejectedUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09C7 (2503) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary | Zero - unsequenced application message |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| ClOrdID | 22 | 20 | Text |  |
| ClearingFirm | 42 | 4 | Alpha |  |
| RoutingFirmID | 46 | 4 | Alpha |  |
| OrderRejectReason | 50 | 1 | Text |  |
| Text | 51 | 60 | Text |  |

#### Cross Order Rejected Message Fields (C1 and EDGX Only)

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

##### CrossOrderRejectedUSOptionsV1 Message Fields

**Table 1. CrossOrderRejectedUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09C8 (2504) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary | Zero - unsequenced application message |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| CrossID | 22 | 20 | Text |  |
| RoutingFirmID | 42 | 4 | Alpha |  |
| OrderRejectReason | 46 | 1 | Text |  |
| Text | 47 | 60 | Text |  |

#### Quote Update Rejected Message Fields

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

##### QuoteUpdateRejectedUSOptionsV1 Message Fields

**Table 1. QuoteUpdateRejectedUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09D6 (2518) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary | Zero - unsequenced application message |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| QuoteUpdateID | 22 | 16 | Text |  |
| QuoteRejectReason | 38 | 1 | Text |  |

#### Order Modified Message Fields

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

In some cases, the last message to be received on an order's lifecycle 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.

##### OrderModifiedUSOptionsV1 Message Fields

**Table 1. OrderModifiedUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09CB (2507) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary |  |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| ClOrdID | 22 | 20 | Text |  |
| OrigClOrdID | 42 | 20 | Text |  |
| OrderID | 62 | 8 | Binary |  |
| ClearingFirm | 70 | 4 | Alpha |  |
| RoutingFirmID | 74 | 4 | Alpha |  |
| Symbol | 78 | 8 | Alphanumeric |  |
| OrderQty | 86 | 4 | Binary |  |
| Price | 90 | 8 | BinaryPrice |  |
| OrdType | 98 | 1 | Text |  |
| MaxFloor | 99 | 4 | Binary |  |
| StopPx | 103 | 8 | BinaryPrice |  |
| LeavesQty | 111 | 4 | Binary |  |
| DisplayPrice | 115 | 8 | BinaryPrice |  |
| WorkingPrice | 123 | 8 | BinaryPrice |  |
| BaseLiquidityIndicator | 131 | 1 | Text |  |
| SecondaryOrderID | 132 | 8 | Binary |  |
| RequestReceivedTime | 140 | 8 | DateTime |  |

#### Order Restated Message Fields

`Order Restated` messages are sent to inform the Member that an order has been asynchronously modified for some reason without an explicit `Modify Order` message request having been sent. Some example (non-exhaustive) reasons for `Order Restated` messages being sent:

- A reserve (iceberg) order has been reloaded (BZX , C1, and C2 Only).
- An order's remaining quantity was decremented because of a prevented wash trade.
- An order is represented on the Cboe Options Trading Floor (C1 Only).
- A routed order has returned to rest on the book after matching liquidity on another market.

Members should be prepared to accept and apply `Order Restated` messages for any reason.

In some cases, the last message to be received on an order's lifecycle will be an `Order Restated` message. The way to know the order is no longer live is to inspect LeavesQty. An example of this would be restatement of an order in some cases due to PreventMatch being set to d.

##### OrderRestatedUSOptionsV1 Message Fields

**Table 1. OrderRestatedUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09CD (2509) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary |  |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| ClOrdID | 22 | 20 | Text |  |
| OrderID | 42 | 8 | Binary |  |
| ClearingFirm | 50 | 4 | Alpha |  |
| RoutingFirmID | 54 | 4 | Alpha |  |
| Symbol | 58 | 8 | Alphanumeric |  |
| OrderRestatementReason | 66 | 1 | Text |  |
| OrderQty | 67 | 4 | Binary |  |
| Price | 71 | 8 | BinaryPrice |  |
| LeavesQty | 79 | 4 | Binary |  |
| DisplayPrice | 83 | 8 | BinaryPrice |  |
| WorkingPrice | 91 | 8 | BinaryPrice |  |
| BaseLiquidityIndicator | 99 | 1 | Text |  |
| SecondaryOrderID | 100 | 8 | Binary |  |
| LastShares | 108 | 4 | Binary |  |
| LastPx | 112 | 8 | BinaryPrice |  |

#### Quote Restated Message Fields

`Quote Restated` messages are sent to inform the Member that an order has been asynchronously modified for some reason by the Exchange. For quotes, this could happen if the MTP decrement method has been used by an inbound order against a resting quote. On BZX Options, if a hidden working price is covered by an inbound post only order or quote, a restatement will also occur. Additional reasons may be added in the future.

##### QuoteRestatedUSOptionsV1 Message Fields

**Table 1. QuoteRestatedUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09D9 (2521) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary |  |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| QuoteUpdateID | 22 | 16 | Text |  |
| OrderID | 38 | 8 | Binary |  |
| LeavesQty | 46 | 4 | Binary |  |
| WorkingPrice | 50 | 8 | BinaryPrice |  |
| QuoteSymbol | 58 | 6 | Alphanumeric |  |
| Side | 64 | 1 | Text |  |
| RestatementReason | 65 | 1 | Text |  |

#### Modify Rejected Message Fields

`User Modify Rejected` messages are sent in response to a `Modify Order` message for an order which cannot be modified. `User 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).

##### ModifyRejectedUSOptionsV1 Message Fields

**Table 1. ModifyRejectedUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09CC (2508) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary | Zero - unsequenced application message |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| ClOrdID | 22 | 20 | Text |  |
| ClearingFirm | 42 | 4 | Alpha |  |
| RoutingFirmID | 46 | 4 | Alpha |  |
| OrigClOrdID | 50 | 20 | Text |  |
| ModifyRejectReason | 70 | 1 | Text |  |
| Text | 71 | 60 | Text |  |

#### Order Cancelled Message Fields

This message indicates an order has been cancelled. The cancellation may be solicited or unsolicited. A solicited cancellation is in response to a `Cancel Order`, `Mass Cancel Orders`, or a `Purge Orders` message.

##### OrderCancelledUSOptionsV1 Message Fields

**Table 1. OrderCancelledUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09D0 (2512) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary |  |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| ClOrdID | 22 | 20 | Text |  |
| CancelReason | 42 | 1 | Text |  |
| CancelSubReason | 43 | 1 | Text |  |
| ClearingFirm | 44 | 4 | Alpha |  |
| RoutingFirmID | 48 | 4 | Alpha |  |
| Symbol | 52 | 8 | Alphanumeric |  |
| RequestReceivedTime | 60 | 8 | DateTime |  |

#### Quote Cancelled Message Fields

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.

##### QuoteCancelledUSOptionsV1 Message Fields

**Table 1. QuoteCancelledUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09D7 (2519) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary | Zero - unsequenced application message |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| QuoteUpdateID | 22 | 16 | Text |  |
| OrderID | 38 | 8 | Binary |  |
| QuoteSymbol | 46 | 6 | Alphanumeric |  |
| Side | 52 | 1 | Text |  |
| CancelReason | 53 | 1 | Text |  |
| CancelSubReason | 54 | 1 | Text |  |

#### Cross Order Cancelled Message Fields (C1 and EDGX Only)

Sent when a `New Order Cross` message has been cancelled. Individual order allocations from the original `New Order Cross` and `New Order Cross Multileg` message will be echoed back in the repeating groups.

##### CrossOrderCancelledUSOptionsV1 Message Fields

**Table 1. CrossOrderCancelledUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09D1 (2513) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary |  |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| CrossID | 22 | 20 | Text |  |
| RoutingFirmID | 42 | 4 | Alpha |  |
| CancelReason | 46 | 1 | Text |  |
| AllocCnt | 47 | 1 | Binary |  |
| → ClOrdID | 48 | 20 | Text | (Group repeats AllocCnt times) |
| → GiveUpFirmID | 68 | 4 | Alpha | (Group repeats AllocCnt times) |

#### Cancel Rejected Message Fields

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.

##### CancelRejectedUSOptionsV1 Message Fields

**Table 1. CancelRejectedUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09D2 (2514) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary | Zero - unsequenced application message |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| ClOrdID | 22 | 20 | Text |  |
| ClearingFirm | 42 | 4 | Alpha |  |
| RoutingFirmID | 46 | 4 | Alpha |  |
| CancelRejectReason | 50 | 1 | Text |  |
| Text | 51 | 60 | Text |  |

#### Order Execution Message Fields

An `Order Execution` message 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 complex orders, an `Order Execution` message will be generated for the complex order, with `MultilegReportingType`= 3, followed by `Order Execution` messages for each leg, with `MultilegReportingType`= 2. 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.

The symbology used on executions for complex orders, including the legs, will always be Cboe symbology.

##### OrderExecutionUSOptionsV1 Message Fields

**Table 1. OrderExecutionUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09D3 (2515) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary |  |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| ClOrdID | 22 | 20 | Text |  |
| ExecID | 42 | 8 | Binary |  |
| LastShares | 50 | 4 | Binary |  |
| LastPx | 54 | 8 | BinaryPrice |  |
| LeavesQty | 62 | 4 | Binary |  |
| BaseLiquidityIndicator | 66 | 1 | Text |  |
| SubLiquidityIndicator | 67 | 1 | Text |  |
| ContraBroker | 68 | 4 | Alphanumeric |  |
| Side | 72 | 1 | Text |  |
| Symbol | 73 | 8 | Alphanumeric |  |
| ContraTrader | 81 | 4 | Alphanumeric |  |
| ClearingFirm | 85 | 4 | Alpha |  |
| ContraCapacity | 89 | 1 | Text |  |
| FeeCode | 90 | 2 | Alphanumeric |  |
| MarketingFeeCode | 92 | 2 | Alphanumeric |  |
| RoutingFirmID | 94 | 4 | Alpha |  |
| CrossExclusionIndicator | 98 | 1 | Text |  |
| TradeDate | 99 | 4 | Date |  |
| MultilegReportingType | 103 | 1 | Text |  |
| SecondaryExecID | 104 | 8 | Binary |  |
| PriceType | 112 | 1 | Text |  |
| TradeThroughAlertType | 113 | 1 | Text |  |
| SenderLocationID | 114 | 1 | Text |  |
| FloorTraderAcronym | 115 | 3 | Alpha |  |
| FloorTradeTime | 118 | 8 | DateTime |  |
| ExDestination | 126 | 1 | Alphanumeric |  |
| EquityExDestination | 127 | 1 | Alphanumeric |  |

#### Quote Execution Message Fields

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

##### QuoteExecutionUSOptionsV1 Message Fields

**Table 1. QuoteExecutionUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09D8 (2520) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary |  |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| QuoteUpdateID | 22 | 16 | Text |  |
| OrderID | 38 | 8 | Binary |  |
| ExecID | 46 | 8 | Binary |  |
| QuoteSymbol | 54 | 6 | Alphanumeric |  |
| ClearingFirm | 60 | 4 | Alpha |  |
| LastShares | 64 | 4 | Binary |  |
| LastPx | 68 | 8 | BinaryPrice |  |
| LeavesQty | 76 | 4 | Binary |  |
| ContraTrader | 80 | 4 | Alphanumeric |  |
| ContraCapacity | 84 | 1 | Text |  |
| Side | 85 | 1 | Text |  |
| BaseLiquidityIndicator | 86 | 1 | Text |  |
| SubLiquidityIndicator | 87 | 1 | Text |  |
| FeeCode | 88 | 2 | Alphanumeric |  |
| MarketingFeeCode | 90 | 2 | Alphanumeric |  |
| TradeDate | 92 | 4 | Date |  |

#### Complex Quote Execution Message Fields (C1 Only)

A `Complex Quote Execution` message is used to indicate an execution has occurred on a resting complex quote (i.e., quote introduced to the exchange using the `Complex Quote Update` message).

The execution of a complex quote will produce multiple `Complex Quote Execution` messages. The first will be the package-level fill having MultilegReportingType = 3 (entire multi-leg instrument package) and the complex symbol in the Symbol field. This will be followed by the leg execution messages having the leg symbol in the Symbol field and MultiLegReportingType = 2 (individual leg of mutil-leg instrument) or (for the last fill of the execution) MultiLegReportingType = 4 (last individual leg of a multi-leg instrument).

#### ComplexQuoteExecutionUSOptionsV1

**Table 1. ComplexQuoteExecutionUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Description |  |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 2529, 0x09E1 |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary |  |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| QuoteUpdateID | 22 | 16 | Text |  |
| OrderID | 38 | 8 | Binary |  |
| ExecID | 46 | 8 | Binary |  |
| QuoteSymbol | 54 | 6 | Alphanumeric |  |
| ClearingFirm | 60 | 4 | Alpha |  |
| LastShares | 64 | 4 | Binary |  |
| LastPx | 68 | 8 | BinaryPrice |  |
| LeavesQty | 76 | 4 | Binary |  |
| ContraTrader | 80 | 4 | Alphanumeric |  |
| ContraCapacity | 84 | 1 | Text |  |
| Side | 85 | 1 | Text |  |
| BaseLiquidityIndicator | 86 | 1 | Text |  |
| SubLiquidityIndicator | 87 | 1 | Text |  |
| FeeCode | 88 | 2 | Alphanumeric |  |
| MarketingFeeCode | 90 | 2 | Alphanumeric |  |
| TradeDate | 92 | 4 | Date |  |
| MultilegReportingType | 96 | 1 | Text |  |
| SecondaryExecID | 97 | 8 | Binary |  |

#### Trade Cancel or Correct Message Fields

Used to relay a trade which has been cancelled (busted) or corrected (price or size change only). The CorrectedPrice and CorrectedSize fields will be set to 0 for cancelled trades and to the new trade price and/or size for corrected trades. `Trade Cancel or Correct` messages can be sent for same day as well as previous day trades.

Trade cancels or corrections to complex instruments will result in individual `Trade Cancel or Correct` messages being sent for each leg. No cancels or corrections will be sent for complex instruments.

##### TradeCancelCorrectUSOptionsV1Block Message Fields

**Table 1. TradeCancelCorrectUSOptionsV1Block Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09D4 (2516) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary |  |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| ClOrdID | 22 | 20 | Text |  |
| OrderID | 42 | 8 | Binary |  |
| ExecRefID | 50 | 8 | Binary |  |
| Side | 58 | 1 | Text |  |
| BaseLiquidityIndicator | 59 | 1 | Text |  |
| SubLiquidityIndicator | 60 | 1 | Text |  |
| ClearingFirm | 61 | 4 | Alpha |  |
| ClearingAccount | 65 | 4 | Text |  |
| LastShares | 69 | 4 | Binary |  |
| LastPx | 73 | 8 | BinaryPrice |  |
| CorrectedPrice | 81 | 8 | BinaryPrice |  |
| CorrectedSize | 89 | 4 | Binary |  |
| OrigTime | 93 | 8 | DateTime |  |
| Symbol | 101 | 8 | Alphanumeric |  |
| MaturityDate | 109 | 4 | Date |  |
| StrikePrice | 113 | 8 | BinaryPrice |  |
| PutOrCall | 121 | 1 | Text |  |
| Capacity | 122 | 1 | Text |  |
| OpenClose | 123 | 1 | Text |  |
| MarketingFeeCode | 124 | 2 | Alphanumeric |  |
| TargetPartyID | 126 | 4 | Alpha |  |
| CMTANumber | 130 | 4 | Binary |  |

#### Purge Rejected Message Fields

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.

##### PurgeRejectedUSOptionsV1 Message Fields

**Table 1. PurgeRejectedUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09DE (2526) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary | Zero - unsequenced application message |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| MassCancelID | 22 | 20 | Text |  |
| PurgeRejectReason | 42 | 1 | Text |  |
| Text | 43 | 60 | Text |  |

#### Reset Risk Acknowledgment Message Fields

Response to a `Reset Risk` message request.

##### ResetRiskAcknowledgementUSOptionsV1 Message Fields

**Table 1. ResetRiskAcknowledgementUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09DA (2522) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary | Zero - unsequenced application message |
| InFlight | 12 | 2 | Binary |  |
| RiskStatusID | 14 | 16 | Text |  |
| RiskResetResult | 30 | 1 | Text |  |
| RequestReceivedTime | 31 | 8 | DateTime |  |

#### Mass Cancel Acknowledgment Message Fields

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

##### MassCancelAcknowledgementUSOptionsV1 Message Fields

**Table 1. MassCancelAcknowledgementUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09DB (2523) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary | Zero - unsequenced application message |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime | The time the event occurred in the Cboe Matching Engine (not the time the message was sent). |
| MassCancelID | 22 | 20 | Text |  |
| CancelledOrderCount | 42 | 4 | Binary |  |
| RequestReceivedTime | 46 | 8 | DateTime |  |

#### Mass Cancel Rejected Message Fields

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

##### MassCancelRejectedUSOptionsV1 Message Fields

**Table 1. MassCancelRejectedUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09DC (2524) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary | Zero - unsequenced application message |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| MassCancelID | 22 | 20 | Text |  |
| MassCancelRejectReason | 42 | 1 | Text |  |
| Text | 43 | 60 | Text |  |

#### Purge Acknowledgement Message Fields

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

Multiple `Purge Acknowledgment` messages will be sent in response to `Purge Order` message requests for multi-unit orders (MassCancelInst, 2nd character = `I`). An acknowledgement message will be sent for each matching unit followed by a final acknowledgement containing the total number of orders cancelled due to the purge request across all matching units. This final acknowledgment will have a SourceMatchingUnit value of `0`.

##### PurgeAcknowledgementUSOptionsV1 Message Fields

**Table 1. PurgeAcknowledgementUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09DD (2525) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary | Zero - unsequenced application message |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| MassCancelID | 22 | 20 | Text |  |
| CancelledOrderCount | 42 | 4 | Binary |  |
| SourceMatchingUnit | 46 | 1 | Binary |  |
| RequestReceivedTime | 47 | 8 | DateTime |  |

#### Purge Notification Message Fields

A `Purge Notification` message is an unsequenced message sent when the Acknowledgement Style of a Purge Request is `A`. One `Purge Notification` message is sent for each matching unit that cancelled orders for that order entry port.

##### PurgeNotificationUSOptionsV1 Message Fields

**Table 1. PurgeNotificationUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09DF (2527) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary | Zero - unsequenced application message |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| MassCancelID | 22 | 20 | Text |  |
| CancelledOrderCount | 42 | 4 | Binary |  |
| SourceMatchingUnit | 46 | 1 | Binary |  |
| ClearingFirm | 47 | 4 | Alpha |  |
| RiskRoot | 51 | 6 | Text |  |
| MassCancelLockout | 57 | 1 | Text |  |

#### New Complex Instrument Accepted Message Fields

The `New Complex Instrument Accepted` message is used to indicate acceptance of a complex strategy. The leg order sent back may differ from the originating request.

##### NewComplexInstrumentAcceptedUSOptionsV1 Message Fields

**Table 1. NewComplexInstrumentAcceptedUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09C9 (2505) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary |  |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| ClOrdID | 22 | 20 | Text |  |
| Symbol | 42 | 8 | Alphanumeric |  |
| NoOfSecurities | 50 | 4 | Binary |  |
| LegCnt | 54 | 1 | Binary |  |
| → Symbol | 55 | 8 | Alphanumeric | (Group repeated LegCnt times) |
| → MaturityDate | 63 | 4 | Date |  |
| → StrikePrice | 67 | 8 | BinaryPrice |  |
| → CFICode | 75 | 2 | Alphanumeric |  |
| → RatioQty | 77 | 4 | Binary | (Group repeated LegCnt times) |
| → Side | 81 | 1 | Text | (Group repeated LegCnt times) |

#### New Complex Instrument Rejected Message Fields

The `New Complex Instrument Rejected` message is used to indicate that a requested complex strategy has been rejected. `Complex Instrument Rejected` messages are unsequenced.

##### NewComplexInstrumentRejectedUSOptionsV1 Message Fields

**Table 1. NewComplexInstrumentRejectedUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09CA (2506) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary | Zero - unsequenced application message |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| ClOrdID | 22 | 20 | Text |  |
| NoOfSecurities | 42 | 4 | Binary |  |
| OrderRejectReason | 46 | 1 | Text |  |
| Text | 47 | 60 | Text |  |

#### Carried Restatement Message Fields

The `Carried Restatement` message is used to indicate the restoration of a multi-day GTC or GTD order at the start of a new business day.

##### CarriedRestatementUSOptionsV1 Message Fields

**Table 1. CarriedRestatementUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09CE (2510) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary |  |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| ClOrdID | 22 | 20 | Text |  |
| OrderID | 42 | 8 | Binary |  |
| Side | 50 | 1 | Text |  |
| Price | 51 | 8 | BinaryPrice |  |
| ExecInst | 59 | 1 | Text |  |
| OrdType | 60 | 1 | Text |  |
| TimeInForce | 61 | 1 | Text |  |
| MinQty | 62 | 4 | Binary |  |
| Symbol | 66 | 8 | Alphanumeric |  |
| Capacity | 74 | 1 | Text |  |
| Account | 75 | 16 | Text |  |
| ClearingFirm | 91 | 4 | Alpha |  |
| ClearingAccount | 95 | 4 | Text |  |
| DisplayIndicator | 99 | 1 | Text |  |
| MaxFloor | 100 | 4 | Binary |  |
| OrderQty | 104 | 4 | Binary |  |
| PreventMatch | 108 | 3 | Text |  |
| MaturityDate | 111 | 4 | Date |  |
| StrikePrice | 115 | 8 | Binary Price |  |
| PutOrCall | 123 | 1 | Alphanumeric |  |
| OpenClose | 124 | 1 | Text |  |
| LeavesQty | 125 | 4 | Binary |  |
| DisplayPrice | 129 | 8 | BinaryPrice |  |
| WorkingPrice | 137 | 8 | BinaryPrice |  |
| ExpireTime | 145 | 8 | DateTime |  |
| AttributedQuote | 153 | 1 | Text |  |
| StopPx | 154 | 8 | BinaryPrice |  |
| RoutingInst | 162 | 4 | Text |  |
| RoutStrategy | 166 | 6 | Text |  |
| RouteDeliveryMethod | 172 | 3 | Text |  |
| ExDestination | 175 | 1 | Text |  |
| TargetPartyID | 176 | 4 | Alpha |  |
| AuctionID | 180 | 8 | Binary |  |
| CMTANumber | 188 | 4 | Binary |  |
| RoutingFirmID | 192 | 4 | Alpha |  |
| ClearingOptionalData | 196 | 16 | Text |  |
| CumQty | 212 | 4 | Binary |  |
| DrillThruProtection | 216 | 8 | BinaryPrice |  |
| EquityPartyId | 224 | 4 | Alpha |  |
| ClientIDAttr | 228 | 4 | Text |  |
| FrequentTraderID | 232 | 6 | Alphanumeric |  |
| SessionEligibility | 238 | 1 | Text |  |
| ComboOrder | 239 | 1 | Text |  |
| Compression | 240 | 1 | Text |  |
| FloorDestination | 241 | 4 | Text |  |
| FloorRoutingInst | 245 | 1 | Text |  |
| OrderOrigin | 246 | 3 | Alphanumeric |  |
| PriceType | 249 | 1 | Text |  |
| StrategyID | 250 | 1 | Text |  |
| Held | 251 | 1 | Text |  |

#### Done For Day Message Fields

The `Done For Day` messages represent orders persisted during the current day session to carry over to the next session. `Done For Day` messages will be sent after the end of trading for the associated product and before system recycle.

##### DoneForDayUSOptionsV1 Message Fields

**Table 1. DoneForDayUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x09CF (2511) |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary |  |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| ClOrdID | 22 | 20 | Text |  |
| ClearingFirm | 42 | 4 | Alpha |  |
| RoutingFirmID | 46 | 4 | Alpha |  |
| Symbol | 50 | 8 | Alphanumeric |  |

#### Floor Trade Notification Message Fields (C1 Only)

TPHs with Market Makers on the Cboe trading floor may optionally receive `Floor Trade Notification` messages. TPHs must request the Enable Floor Trade Notifications port attribute be enabled for one or more floor acronyms in order to receive these messages.

TPHs are encouraged to use `Floor Trade Confirmation` messages to respond to `Floor Trade Notification` messages if they agree with the terms of the trade. Alternatively, an `Add Floor Trade` message may be used to enter their version of the floor trade. If the floor trade notification is not known to the Market Maker (for example, if the TPH is misidentified as a contra party to the floor trade), the message can be disregarded; a response is not required.

TPHs configured to be automatically endorsed to floor trades will not receive a `Floor Trade Notification` message; only an `Order Execution` message.

##### FloorTradeNotificationUSOptionsV1

**Table 1. FloorTradeNotificationUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 2530, 0x09E2 |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary | Zero (unsequenced application message) |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| ExecID | 22 | 8 | Binary |  |
| Symbol | 30 | 8 | Alphanumeric |  |
| PutOrCall | 38 | 1 | Text |  |
| StrikePrice | 39 | 8 | BinaryPrice |  |
| MaturityDate | 47 | 4 | Date |  |
| OrderQty | 51 | 4 | Binary |  |
| Price | 55 | 8 | BinaryPrice |  |
| Side | 63 | 1 | Text |  |
| ContraTrader | 64 | 4 | Alphanumeric |  |
| FloorTraderAcronym | 68 | 3 | Alpha |  |
| FloorTradeTime | 71 | 8 | DateTime |  |
| TradethroughAlertType | 79 | 1 | Text |  |
| PriceType | 80 | 1 | Text |  |

#### Floor Trade Confirmation Rejected Message Fields (C1 Only)

The `Add Floor Trade Rejected`message is used to indicate that a requested `Add Floor Trade` message has been rejected. Add `Floor Trade Rejected` messages are unsequenced.

##### FloorTradeConfirmationRejectedUSOptionsV1

**Table 1. FloorTradeConfirmationRejectedUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Description |  |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 2532, 0x09E4 |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary | Zero (unsequenced application message) |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| ClOrdID | 22 | 20 | Text |  |
| ExecID | 42 | 8 | Binary |  |
| OrderRejectReason | 50 | 1 | Text |  |
| Text | 51 | 60 | Text |  |

#### Add Floor Trade Rejected Message Fields (C1 Only)

The `Add Floor Trade Rejected` message is used to indicate that a requested `Add Floor Trade` message has been rejected. `Add Floor Trade Rejected` messages are unsequenced.

##### AddFloorTradeRejectedUSOptionsV1

| Field Name | Offset | Length | Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 2531, 0x09E3 |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary | Zero (unsequenced application message) |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| ClOrdID | 22 | 20 | Text |  |
| OrderRejectReason | 42 | 1 | Text |  |
| Text | 43 | 60 | Text |  |

#### Delete Floor Trade Rejected Message Fields (C1 Only)

The `Delete Floor Trade Rejected` message is used to indicate that a requested `Delete Floor Trade` message has been rejected. `Delete Floor Trade Rejected` messages are unsequenced.

##### DeleteFloorTradeRejectedUSOptionsV1

**Table 1. Delete FloorTradeRejectedUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 2533, 0x09E5 |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary | Zero (unsequenced application message) |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| ClOrdID | 22 | 20 | Text |  |
| ExecId | 42 | 8 | Binary |  |
| OrderRejectReason | 50 | 1 | Text |  |
| Text | 51 | 60 | Text |  |

#### Floor Order Represented Message Fields (C1 Only)

Orders routed to the trading floor will be represented before being traded in open outcry. The Cboe BOEv3 protocol provides a mechanism for clients to request restatement of orders at the time of representation; Floor Representation Restatements are sent to connected clients for each order when the floor broker reports representation of the order to the crowd.

Floor Representation Restatements sent to order ports will also be sent to connected Order by Order Drop clients having the Floor Representation Restatements port attribute enabled. These messages will have ExecTransType (20) = 3 (Status), ExecType (150) = `D (Restated)`, and ExecRestatementReason (378) = 7 (Represented in Crowd). The TransactTime (60) will be the recorded time of the representation.

##### FloorOrderRepresentedUSOptionsV1

**Table 1. Floor OrderRepresentedUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 2535, 0x09E7 |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary |  |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| ClOrdID | 22 | 20 | Text |  |
| OrderID | 42 | 8 | Binary |  |
| ClearingFirm | 50 | 4 | Alpha |  |
| RoutingFirmID | 54 | 4 | Alpha |  |
| FloorTraderAcronym | 58 | 3 | Alpha |  |
| OrderRestatementReason | 61 | 1 | Text |  |

#### Delete Floor Trade Acknowledgement Message Fields (C1 Only)

A `Delete Floor Trade Acknowledgment` message is an unsequenced message sent when a `Delete Floor Trade` message has been accepted.

##### DeleteFloorTradeAcknowledgementUSOptionsV1

**Table 1. DeleteFloorTradeAcknowledgementUSOptionsV1 Message Fields**

| Field Name | Offset | Length | Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 2534, 0x09E6 |
| MatchingUnit | 6 | 1 | Binary |  |
| Reserved | 7 | 1 | Binary | Value sent to member not specified |
| SequenceNumber | 8 | 4 | Binary | Zero (unsequenced application message) |
| InFlight | 12 | 2 | Binary |  |
| TransactionTime | 14 | 8 | DateTime |  |
| ClOrdID | 22 | 20 | Text |  |
| ExecID | 42 | 8 | Binary |  |

## List of Message Fields

The following are descriptions of fields which may be sent or received.

**Table 1. List of Message Fields**

| Field | Length | Data Type | Description |  |  |  |  |  |  |  |  |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Account | 16 | Text | Corresponds to Account (1) in Cboe FIX. Characters in ASCII range 33-126 are allowed. When clearing OCC, the value is passed to clearing in the Clearing Member Optional Data field (16 characters) and the Customer ID field (max 10 characters). The value may be made available in the Member's clearing file. When clearing Cboe Clear U.S., the value is passed to clearing in the Customer Account Number field. |  |  |  |  |  |  |  |  |
| AllocCnt | 1 | Binary | Number of allocation party repeating groups in the message. |  |  |  |  |  |  |  |  |
| AllocQty (C1 and EDGX only) | 4 | Binary | Corresponds to AllocQty (80) in Cboe FIX. Number of contracts for this party. |  |  |  |  |  |  |  |  |
| AllocLegCnt | 1 | Binary | Total number of leg details in the message: AllocCnt * #legs, or 0. All leg data for the first allocation should preceed all leg data for the second allocation, etc. |  |  |  |  |  |  |  |  |
| AttributedQuote | 1 | Alphanumeric | Optional. Allows for an order to be attributed to a firm's Executing Broker ID in Cboe market data feeds. The order may also be included with attributed summary information displays related to quote/trade information on the Cboe website. Must opt-in to support through the Cboe Trade Desk. On a `New Order Cross` and `New Order Cross Multileg` message, this field is only applicable to the Agency order. `N` = Do not attribute firm Executing Broker ID to this order (Default) `Y` = Attribute firm Executing Broker ID to this order `C` = Attribute ClientID only `Z` = Attribute both ClearingFirm (EFID) and ClientID |  |  |  |  |  |  |  |  |
| AuctionID | 8 | Binary | Corresponds to AuctionID (9370) in Cboe FIX. Auction order identifier supplied by Cboe. This identifier corresponds to the identifiers used in Cboe market data products. |  |  |  |  |  |  |  |  |
| AutoMatch (C1 and EDGX only) | 1 | Alphanumeric | Corresponds to AutoMatch (9040) in Cboe FIX. Better-priced responses will be matched by the Contra side. Indicates the type of Auto Match the Contra Order will use. Mutually exclusive with LastPriority . Limit type Auto Match orders require AutoMatchPrice to be supplied. `0` = Disabled (Default) `1` = Market `2` = Limit `3` = Market. No starting price adjustments. `4` = Limit. No starting price adjustments. |  |  |  |  |  |  |  |  |
| AutoMatchPrice (C1 and EDGX only) | 8 | Binary Price | Corresponds to AutoMatchPrice (9044) in Cboe FIX. Sets the limit price at which the Contra Order will Auto Match. Required if AutoMatch = `2 (Limit)` or `4 (Limit. No starting price adjustments)` , ignored otherwise. Format is the same as Price . AutoMatchPrice is from the perspective of the Contra Side. Net Auction Price of the Strategy. Buy Orders: Positive Value, Debit Negative Value, Credit Even Order - 0 (Zero) Sell Orders: Positive Value, Credit Negative Value, Debit Even Order - 0 (Zero) |  |  |  |  |  |  |  |  |
| BaseLiquidityIndicator | 1 | Alphanumeric | Indicates whether the trade added or removed liquidity. `A` = Added Liquidity `R` = Removed Liquidity `X` = Routed to Another Market `C` = Auction/Uncrossing |  |  |  |  |  |  |  |  |
| CancelledOrderCount | 4 | Binary | Number of orders cancelled by the mass cancel or purge operation. |  |  |  |  |  |  |  |  |
| CancelOrigOnReject | 1 | Alpha | Corresponds to CancelOrigOnReject (9619) in Cboe FIX. Indicates handling of original order on failure to modify. `N` = Leave original order alone `Y` = Cancel original order if modification fails |  |  |  |  |  |  |  |  |
| CancelReason | 1 | Text | Single character code for the cancellation reason. (See Reason Codes ) |  |  |  |  |  |  |  |  |
| CancelRejectReason | 1 | Text | Single character code for the cancel rejection reason. (See Reason Codes ) |  |  |  |  |  |  |  |  |
| CancelSubReason | 1 | Text | Single character code for the cancellation sub-reason. (See Order and Quote Subreason Codes ) |  |  |  |  |  |  |  |  |
| Capacity | 1 | Alpha | Corresponds to OrderCapacity (47) in Cboe FIX. The capacity of the order. `C` = Customer `M` = Market Maker (this must be used for all Quote Update messages) `F` = Firm `U` = Professional Customer `N` = Away Market Maker `B` = Broker-Dealer `J` = Joint Back Office `L` = Non-Trading Permit Holder Affiliate (C1 and C2 only) |  |  |  |  |  |  |  |  |
| CFICode | 2 | Alphanumeric | CFI Code for leg. `O` = Options `E` = Equity (C1 and EDGX only) |  |  |  |  |  |  |  |  |
| ClearingAccount | 4 | Text | Corresponds to ClearingAccount (440) in Cboe FIX. This field is returned in Execution Reports including FIX Drop. When Capacity is set to a value of M or N for Market Maker, this field should be filled with the desired market maker ID. When using CMTA, this value is the Market Maker ID for the CMTA member instead of the Cboe member executing the trade. This value is passed through to clearing. If OrderCapacity (47) is not set to 'M' or 'N' and ClearingAccount is populated, the order will be rejected by default on C1 and C2 and will be accepted by default for EDGX Only. |  |  |  |  |  |  |  |  |
| ClearingFirm | 4 | Alpha | Corresponds to OnBehalfOfCompID (115) Cboe FIX. EFID that will clear the trade. Port attribute value of Default EFID is used if not provided. |  |  |  |  |  |  |  |  |
| ClearingOptionalData | 16 | Text | Corresponds to ClearingOptionalData (9324) in Cboe FIX. This field is passed through to clearing and is included in Execution Reports on FIX Drop feeds. |  |  |  |  |  |  |  |  |
| ClOrdID | 20 | Text | Corresponds to ClOrdID (11) in Cboe FIX. ID chosen by the client. Characters in the ASCII range 33-126 are allowed, except for comma , , semicolon ; , pipe \| , at @ , and double quotes " . Additionally, the ClOrdID cannot begin with a tilde ~ since this is reserved for Cboe-generated ClOrdID values. If the ClOrdID matches a live order, the order will be rejected as duplicate. Note: Cboe only enforces uniqueness of ClOrdID values among currently live orders, which includes long-lived, persisting GTC/GTD orders . However, we strongly recommend that you keep your ClOrdID values unique. |  |  |  |  |  |  |  |  |
| ClientIDAttr | 4 | Text | Corresponds to ClientID (109) Cboe FIX. User defined identifier for quote attribution. |  |  |  |  |  |  |  |  |
| CMTANumber | 4 | Binary | Corresponds to ClearingFirm (439) in Cboe FIX. CMTA Number of the firm that will clear the trade. Must be specified for CMTA orders and left unspecified for non-CMTA orders. |  |  |  |  |  |  |  |  |
| ComboOrder (C1 only) | 1 | Alpha | Corresponds to ComboOrder (22005) in Cboe FIX. Declare the order as a Combo (for regulatory relief if trading SPX on the floor). `N` = No (Default) `Y` = Yes |  |  |  |  |  |  |  |  |
| Compression (C1 only) | 1 | Alpha | Corresponds to Compression (22006) in Cboe FIX. Order is a compression trade. `N` = No (Default) `Y` = Yes When `CrossType (549)` = 4 this field should not be specified. |  |  |  |  |  |  |  |  |
| ContraBroker | 4 | Alphanumeric | Corresponds to ContraBroker (375) in Cboe FIX. Simple Instrument Fills Internally matched simple executions will identify the clearing number of the contra on the execution. This includes leg fill reports ( MultilegReportingType = `2` ) that are sent as a result of a complex trade. Executions matched on the C1 trading floor will contain a value of `FBKR` for ContraBroker for the first reporter of a Broker to Broker floor trade otherwise, this will identify the clearing number of the contra (C1 only) . Complex Package Fills ContraBroker will be sent and populated on electronic, complex package fills ( MultilegReportingType = `3` ) when the contra side is also a complex order. When legging in to the simple books ContraBroker will be blank. ContraBroker will be blank on complex package fills ( MultilegReportingType = `3` ) executed on the Cboe Options trading floor (C1 only) . Routed Fills All externally matched (routed, BaseLiquidityIndicator = `X` ) executions will identify the away exchange with the following possible values. `AMEX` = Routed to NYSE American `ARCA` = Routed to NYSE Arca `BATS` = Routed to Cboe BZX Options `BOX` = Routed to BOX `CBOE` = Routed to Cboe Options `CTWO` = Routed to C2 Options `EDGX` = Routed to Cboe EDGX Options `EMLD` = Routed to MIAX Emerald `GMNI` = Routed to Nasdaq GEMX `IEX` = Routed to IEX Options `ISE` = Routed to Nasdaq ISE `MEMX` = Routed to MEMX `MERC` = Routed to Nasdaq MRX `MIAX` = Routed to MIAX Options Exchange `MXTO` = Routed to MX2 Options `NOMX` = Routed to Nasdaq `NOBX` = Routed to Nasdaq Texas `PERL` = Routed to MIAX PEARL `PHLX` = Routed to Nasdaq PHLX `SPHR` = Routed to MIAX Sapphire |  |  |  |  |  |  |  |  |
| ContraCapacity | 1 | Alphanumeric | Capacity of the contra for this execution. See Capacity for allowed values. |  |  |  |  |  |  |  |  |
| ContraTrader | 4 | Alphanumeric | Corresponds to ContraTrader (337) in Cboe FIX. Only present on local book trades, not present on routed trades. Simple Instrument Fills Displays the EFID (Contra ClearingFirm ) of the contra side firm. This includes leg fill reports ( MultilegReportingType = `2` ) that are sent as a result of a complex trade. For Cboe Options floor trades, displays the Contra Floor Acronym (C1 only) . Complex Package Fills ContraTrader will be sent and populated on electronic, complex package fills ( MultilegReportingType = `3` ) when the contra side is also a complex order. When legging in to the simple books ContraTrader will be blank. ContraTrader will also be blank on complex package fills executed on the Cboe Options trading floor (C1 only) . |  |  |  |  |  |  |  |  |
| CorrectedPrice | 8 | BinaryPrice | Corresponds to CorrectedPrice (9620) in Cboe FIX. Price of the trade after adjustment. |  |  |  |  |  |  |  |  |
| CorrectedSize | 4 | Binary | Corresponds to CorrectedSize (6655) in Cboe FIX. Number of shares after trade adjustment. |  |  |  |  |  |  |  |  |
| CrossExclusion Indicator (C1 and EDGX only) | 1 | Alpha | Corresponds to CrossExclusionIndicator (6438) in Cboe FIX. `N` = Contracts were executed in auction against Contra party or against a resting order when auction was initiated `Y` = Contracts were executed in auction against another party. |  |  |  |  |  |  |  |  |
| CrossID (C1 and EDGX only) | 20 | Text | Corresponds to CrossID (548) in Cboe FIX. Day-unique identifier for the cross order chosen by the member. Characters in the ASCII range 33-126 are allowed, except for comma , , semicolon ; , pipe \| , at @ , and double quotes " . Additionally, the ClOrdID cannot begin with a tilde ~ since this is reserved for Cboe-generated ClOrdID values. |  |  |  |  |  |  |  |  |
| CrossInitiator (C1 and EDGX only) | 4 | Alpha | Corresponds to CrossInitiator (22026) in Cboe FIX. MPID field required on cross orders routed to destinations via NYSE Chicago using EquityExDestination (22016). Should be populated with the originator or routing broker MPID. May or may not be the same as the agency/contra MPID. Note that Broker Choice will be allowed on any stock/option order including FLEX or Non-FLEX orders of any ratio. |  |  |  |  |  |  |  |  |
| CrossOnBehalfOfID (C1 and EDGX only) | 4 | Alpha | Corresponds to CrossOnBehalfOfID (22028) in Cboe FIX. Optional identifier of the initiating customer on orders routed to destinations via NYSE Chicago using EquityExDestination (22016) Populate with the order initiator's MPID or any other identifier of choice. Should be populated if not the same broker specified in CrossInitiator (22026). Note that Broker Choice is allowed on any stock/option order including FLEX or Non-Flex orders of any ratio. |  |  |  |  |  |  |  |  |
| CrossPrioritization (C1 and EDGX only) | 1 | Alphanumeric | Corresponds to CrossPrioritization (550) in Cboe FIX. Indicates which side of the cross order will be prioritized for execution. This identifies the Agency side. `1` = Buy `2` = Sell |  |  |  |  |  |  |  |  |
| CrossType | 1 | Alphanumeric | Corresponds to CrossType (549) in Cboe FIX. Type of auction order being submitted. This indicates the type of auction that will be initiated upon order entry. `1` = Automated Improvement Mechamism (AIM) `2` = Qualified Contingent Cross (QCC) `3` = Solicitation Cross (SAM) (C1 and EDGX only) `4` = Position Compression Cross (PCC) (C1 Only) |  |  |  |  |  |  |  |  |
| CumQty | 4 | Binary | The total quantity traded by the order. |  |  |  |  |  |  |  |  |
| CustomGroupID | 2 | Binary | Corresponds to CustomGroupID (7699) in Cboe FIX for `New Order` and `Purge Orders` messages. Used to group orders for use in `Purge Orders` messages where multiple orders can be cancelled by specifying a list of CustomGroupIDs . |  |  |  |  |  |  |  |  |
| CustomGroupIDCnt | 1 | Binary | Number of CustomGroupID fields in the message. Integer 0-10. |  |  |  |  |  |  |  |  |
| DisplayIndicator | 1 | Alphanumeric | Corresponds to DisplayIndicator (9479) in Cboe FIX. `V` = Default . As determined by port level setting (default to S) `S` = Display Price Sliding (this is to override a opt-out of Display Price Sliding at the port level (BZX only) . `L` = Display Price Sliding, but reject if order crosses NBBO on entry (BZX only) `M` = Multiple Display Price Sliding (BZX only) `P` = Price Adjust `m` = Multiple Price Adjust `R` = Reject the order if it cannot be booked and displayed without adjustment. `N` = NoRescrapeAtLimit (BZX only) See Port Types for more details on sliding options. |  |  |  |  |  |  |  |  |
| DisplayPrice | 8 | Binary Price | Only present when order is fully or partially booked. If the order has to be displayed at a less aggressive price for some reason, then that price will be reported here, otherwise equals Price. |  |  |  |  |  |  |  |  |
| DisplayRange | 4 | Binary | Corresponds to DisplayRange (8020) in Cboe FIX. Used for random replenishment of reserve orders. Random replenishment establishes a range of possible values for the order quantity that is to be displayed. For example, if MaxFloor = `2,000` , and DisplayRange = `200` , the displayed quantity will be selected from one of the following values: 1,800, 1,900, 2,000, 2,100, or 2,200. Must be specified in round lots. |  |  |  |  |  |  |  |  |
| DrillThruProtection | 8 | Binary Price | Corresponds to DrillThruProtection (6253) in Cboe FIX. Amount sender is willing to trade through the SNBBO. A zero price provides full SNBBO protection. The price should be entered as a non-negative value. Exchange default values are 5% of the opposite of the SNBBO, with a minimum value of $0.02, a maximum value of $2.00 for SPX/SPXW, and a maximum value of $0.25 for non-SPX/SPXW. Values provided on a `New Complex Order` message do not have a minimum or maximum. |  |  |  |  |  |  |  |  |
| EquityBuyClearingFirm (C1 and EDGX only) | 4 | Text | Corresponds to EquityBuyClearingFirm (22014) in Cboe FIX. Clearing firm on buy side of the equity trade associated with a QCC trade. Valid when CrossType = `2` . |  |  |  |  |  |  |  |  |
| EquityExDestination (C1 and EDGX only) | 1 | Alphanumeric | Corresponds to EquityExDestination (22016) in Cboe FIX. Valid when an equity symbol is present in the complex instrument. Exchange venue to which equity leg matching will be submitted. Supported values are: `C` = TD Securities (USA) LLC (default) `P` = Penserra via NYSE Chicago `F` = FOG Equities via NYSE Chicago `L` = Libucki & Co. via NYSE Chicago `S` = SRT Securities via NYSE Chicago If buyer and seller do not provide matching venues, then the equity match will be reported to TD Securities (USA) LLC (C). |  |  |  |  |  |  |  |  |
| EquityLegShortSell (C1 and EDGX only) | 1 | Alphanumeric | Corresponds to EquityLegShortSell (22624) in Cboe FIX. `5` = Sell Short (for stock leg) `6` = Sell Short Exempt (for stock leg) |  |  |  |  |  |  |  |  |
| EquityPartyId (C1 and EDGX only) | 4 | Alpha | Corresponds to EquityPartyId (22008) in Cboe FIX. MPID used to clear the equity leg being cleared via the Exchange. |  |  |  |  |  |  |  |  |
| EquitySellClearingFirm (C1 and EDGX only) | 4 | Text | Corresponds to EquitySellClearingFirm (22015) in Cboe FIX. Clearing firm on sell side of the equity trade associated with a QCC trade. Valid when CrossType = `2` . |  |  |  |  |  |  |  |  |
| EquityTradePrice (C1 and EDGX only) | 8 | Binary Price | Corresponds to EquityTradePrice (22011) in Cboe FIX. Price at which the equity associated with a QCC trade. Valid when CrossType = `2` . |  |  |  |  |  |  |  |  |
| EquityTradeSize (C1 and EDGX only) | 4 | Binary | Corresponds to EquityTradeSize (22012) in Cboe FIX. Number of shares executed in the equity associated with a QCC trade. Valid when CrossType = `2` . |  |  |  |  |  |  |  |  |
| EquityTradeVenue (C1 and EDGX only) | 1 | Text | Corresponds to EquityTradeVenue (22013) in Cboe FIX. Exchange venue where equity associated with a QCC traded. Valid when CrossType (549) = `2` . `A` = NYSE American `B` = Nasdaq Texas `C` = NYSE National `I` = Investors Exchange `J` = Cboe EDGA Exchange `K` = Cboe EDGX Exchange `M` = CHX `N` = NYSE `P` = NYSE Arca `Q` = Nasdaq `X` = Nasdaq PSX `Y` = Cboe BYX Exchange `Z` = Cboe BZX Exchange |  |  |  |  |  |  |  |  |
| EquityTransactTime (C1 and EDGX only) | 8 | DateTime | Corresponds to EquityTransactTime (22060) in Cboe FIX. Time of equity trade associated with a QCC trade. Valid when CrossType = `2` . |  |  |  |  |  |  |  |  |
| ExDestination | 1 | Text | Corresponds to ExDestination (100) in Cboe FIX. Used to specify the designated away venue for RoutStrategy = `DIRC` . `A` = NYSE ARCA `E` = Nasdaq ISE `F` = MIAX `P` = MIAX PEARL `D` = MIAX Emerald `G` = EDGX Options `H` = C2 `I` = IEX Options `J` = MX2 Options `K` = BOX `M` = MEMX `N` = Nasdaq `S` = Nasdaq Texas `U` = NYSE AMERICAN `W` = Cboe Options (C1) `X` = Nasdaq PHLX `Z` = BZX Options `g` = Nasdaq GEMX `m` = Nasdaq MRX `w` = MIAX Sapphire |  |  |  |  |  |  |  |  |
| ExecID | 8 | Binary | Corresponds to ExecID (17) in Cboe FIX. Execution ID. Unique across all matching units on a given day. Note: ExecIDs will be represented on FIXDROP ports as nine character, base 36 ASCII. Leading zeros should be added if the converted base 36 value is shorter than nine characters. Table 2. Example Conversion Decimal Base 36 28294005440239 A1234B567 76335905726621 R248BC23H 728557228187 09AP05V2Z | Decimal | Base 36 | 28294005440239 | A1234B567 | 76335905726621 | R248BC23H | 728557228187 | 09AP05V2Z |
| Decimal | Base 36 |  |  |  |  |  |  |  |  |  |  |
| 28294005440239 | A1234B567 |  |  |  |  |  |  |  |  |  |  |
| 76335905726621 | R248BC23H |  |  |  |  |  |  |  |  |  |  |
| 728557228187 | 09AP05V2Z |  |  |  |  |  |  |  |  |  |  |
| ExecRefID | 8 | Binary | Corresponds to ExecRefID (19) in Cboe FIX. Refers to the ExecID of the fill being cancelled or corrected. |  |  |  |  |  |  |  |  |
| ExecInst | 1 | Text | Corresponds to ExecInst (18) in Cboe FIX. `1` = Not held. Must be routed to the floor. (C1 only) `f` = Intermarket Sweep (Directed or Cboe) `r` = Settlement Liquidity 1 (C1 only) `G` = All or None (AON) (C1 and EDGX only) `s` = Sweep 2 (C1 and EDGX only) `ASCII NULL (0x00)` = no special handling 1 Requires TimeInForce = `2` and Price . 2 Used for `New Order Cross` `New Order Cross Multileg` messages only. Requires CrossType = `1` (AIM) . |  |  |  |  |  |  |  |  |
| ExpireTime | 8 | DateTime | Corresponds to ExpireTime (126) in Cboe FIX. Required for TimeInForce = `6` orders, specifies the date-time (in UTC) that the order expires. |  |  |  |  |  |  |  |  |
| FeeCode | 2 | Alphanumeric | Corresponds to FeeCode (9882) in Cboe FIX. 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. Members are encouraged to code their systems to accept unknown fee codes. |  |  |  |  |  |  |  |  |
| FloorDestination (C1 only) | 4 | Text | Corresponds to FloorDestination (22100) in Cboe FIX. Specifies a default PAR workstation (ex. W001) to route to on the floor (or ‘PARO’ to route to the Floor PAR Official of the underlying symbol) if not specified on inbound messages. |  |  |  |  |  |  |  |  |
| FloorRoutingInst (C1 only) | 1 | Alphanumeric | Corresponds to FloorRoutingInst (22303) in Cboe FIX. `D` = Direct (do not attempt to process electronically) 1 `E` = Electronic only `X` = Route to floor if unable to process electronically 1 `<blank>` = Port level default The default value for any given port can be changed by requesting an update to the Default FloorRoutingInst port attribute. 1 When FloorRoutingInst is `D` or `X` , RoutingInst must be set to `B` or `R` for simple orders; or `B` for complex instruments. |  |  |  |  |  |  |  |  |
| FloorTraderAcronym (C1 only) | 3 | Alpha | Floor Acronym of member submitting trade. |  |  |  |  |  |  |  |  |
| FloorTradeTime (C1 only) | 8 | DateTime | Trade time reported by the trading floor. |  |  |  |  |  |  |  |  |
| FrequentTraderID (C1 only) | 6 | Text | Corresponds to FrequentTraderId (21097) in Cboe FIX. Identifies the frequent trader program in which the order is participating. |  |  |  |  |  |  |  |  |
| GiveUpFirmID (C1 and EDGX only) | 4 | Alpha | Corresponds to GiveupFirmID (9946) in Cboe FIX. For the Agency Side, this field must equal the value of ClearingFirm (EFID). Each Contra allocation will use this field instead of ClearingFirm for clearing information. |  |  |  |  |  |  |  |  |
| Held (C1 only) | 1 | Alpha | Corresponds to Held (20012) in Cboe FIX. Indicates if order should be designated as Held upon order entry. `N` = Mark order as Not Held `Y` = Mark order as Held Default value is `N` if the order is direct routed to a Non-PAR Official on the floor. |  |  |  |  |  |  |  |  |
| InFlight | 2 | Binary | Total number of messages "in-flight" from the port (total number of messages sent/queued to matching engine which have not yet been acknowledged by the matching engine). See Architecture and Message in Flight Settings . |  |  |  |  |  |  |  |  |
| LastPriority (C1 and EDGX only) | 1 | Alphanumeric | Corresponds to LastPriority (9849) in Cboe FIX. When enabled, allocation will go to other members’ responses before requiring the Contra Order to satisfy remaining contracts of the Agency Order. Mutually exclusive with AutoMatch . `0` = Disabled (Default) `1` = Enabled |  |  |  |  |  |  |  |  |
| LastPx | 8 | Binary Price | Corresponds to LastPx (31) in Cboe FIX. Price of this fill. |  |  |  |  |  |  |  |  |
| LastShares | 4 | Binary | Corresponds to LastShares (32) in Cboe FIX. Executed share quantity. |  |  |  |  |  |  |  |  |
| LeavesQty | 4 | Binary | Corresponds to LeavesQty (151) in Cboe FIX. Quantity still open for further execution. If zero, the order is complete. |  |  |  |  |  |  |  |  |
| LegCnt | 1 | Binary | Number of leg repeating groups in the message. |  |  |  |  |  |  |  |  |
| LegPositionEffect | 1 | Text | Corresponds to OpenClose (77) in Cboe FIX, as applied to the leg of a complex order. Indicates status of member position in the option leg of a complex order. `O` = Open `C` = Close `N` = None Equity legs must use `N` . (See OpenClose field for detail regarding limitations of the use of values `O` , `C` , `N` .) |  |  |  |  |  |  |  |  |
| MarketingFeeCode (C1 and EDGX only) | 2 | Alphanumeric | Corresponds to MarketingFeeCode (5937) in Cboe FIX. `P` = Penny Pilot `N` = Non-Penny Pilot `X` = Not Eligible for Marketing Fees |  |  |  |  |  |  |  |  |
| MassCancelID | 20 | Text | Corresponds to MassCancelID (7695) in Cboe FIX. If the populated value ends in a space the message will be rejected. Mass cancel requests containing a currently outstanding MassCancelID will be rejected. This field will be echoed back in the resulting response message when the single acknoweldgement style is selected. |  |  |  |  |  |  |  |  |
| MassCancelInst | 8 | Text | Corresponds to MassCancelInst (7700) in Cboe FIX. Used for specification of `Purge Orders` message functionality and optionally used for specification of Mass Cancel functionality associated with the `Mass 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. EFID values specified in OnBehalfOfCompId that are not allowed to clear for the firm will be rejected. 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 field. If `F` is 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 and the MassCancelID field is not blank (NULL), then the `Mass Cancel` message will be rejected. For a `Purge Orders` message `M` will be accepted with a non-blank MassCancelID value. `S` = A single `Mass Cancel Acknowledgement` or `Purge Acknowledgement` message is sent once all cancels have been processed. The MassCancelID field must be non-blank or the `Mass Cancel` or `Purge Orders` message will be rejected. `B` = Both individual `Order Cancelled` and `Mass Cancel Acknowledgement` (or `Purge Acknowledgement` message) messages will be sent. Also requires MassCancelID field to be non-blank or the `Mass Cancel` or `Purge Orders` message will be rejected. `A` = A single `Purge Acknowledgement` message is sent to the purge port and one `Purge Notification` message for each matching unit with cancelled orders is sent to the order entry ports that originated those orders. The message type must be `Purge Orders` ; `Mass Cancel` messages specifying this style will be rejected. The CancelledOrderCount field of the purge port message will contain a count of all cancelled orders. The same field of the order entry port messages will contain a count of all cancelled orders from the specified matching unit that originate from the port. The MassCancelID field must be specified or the `Purge Orders` will be rejected. `I` = A single `Purge Acknowledgement` message is sent for each matching unit impacted in a multi-unit cancel. The message type must be `Purge Orders` ; `Mass Cancel` messages specifying this style will be rejected. A final acknowledgement is sent when the last matching unit has completed all requested cancellations. MassCancelId (7695) must be non-blank, or the `Purge Orders` will be rejected . 3rd Character: Lockout Instruction `N` = (D) No lockout `(Effective 09/28/26, this instruction will be required for all Mass Cancel messages)` `L` = Lockout until corresponding a risk reset is received. Lockout can be used only with `Clearing Firm Filter` set to `F` , otherwise the `Mass Cancel` or `Purge Orders` message will be rejected. Lockout will apply to all new orders for the ClearingFirm (and ProductName or CustomGroupIDs , if specified), regardless of other filtering in the `Mass Cancel` or `Purge Orders` message. Effective 09/28/26, Mass Cancel messages with Lockout Instruction = L will be rejected. 4th Character: Instrument Type Filter (C1, C2, and EDGX Only) Value will be ignored on BZX Options. `B` = (D) Cancel both single leg and complex orders `S` = Cancel single leg orders only `C` = Cancel complex orders only 5th Character: GTC Order Filter `C` = (D) Cancel GTC and GTD orders `P` = Don’t cancel (preserve) GTC and GTD orders If the RiskRoot optional field is specified, it must contain a valid symbol (e.g., ‘MSFT’), in which case only orders associated with the specified RiskRoot will be cancelled. A self-imposed lockout can be released by sending a `Reset Risk` message. If RiskRoot field is specified, a symbol level reset is required, otherwise a EFID level reset is required to release a lockout. For more information, see the Cboe Titanium U.S. Options Risk Management Specification . If a risk limit is tripped or manually locked out at the end of the RTH session, the trip/lockout will persist into the Curb session (C1 only) . |  |  |  |  |  |  |  |  |
| MassCancelLockout | 1 | Text | Corresponds to Lockout (7697) in Cboe FIX. Reports the status of the mass cancel lockout `Y` = Lockout `N` = No Lockout |  |  |  |  |  |  |  |  |
| MassCancelRejectReason | 1 | Text | Single character code for the rejection of a purge request. (See Order Reason Codes ) |  |  |  |  |  |  |  |  |
| MaturityDate | 4 | Date | Corresponds to MaturityMonth (200) and MaturityDay (205) in Cboe FIX. When sending Cboe native symbology, set MaturityDate to zero. |  |  |  |  |  |  |  |  |
| MaxFloor | 4 | Binary | Corresponds to MaxFloor (111) in Cboe FIX. Portion of OrderQty to display. The balance is reserve. Zero displays the entire quantity. The displayed quantity of each order at a price level is decremented first. When displayed quantity is fully decremented, it is reloaded up to MaxFloor from reserve. Default = `0` An order with a MaxFloor greater than 0 will be rejected for Cboe proprietary classes (such as DJX, RUT, SPX, XSP, and VIX). |  |  |  |  |  |  |  |  |
| MinQty | 4 | Binary | Corresponds to MinQty (110) in Cboe FIX. Minimum fill quantity for IOC orders which only interact with liquidity on the target book. Ignored for other orders. |  |  |  |  |  |  |  |  |
| ModifyRejectReason | 1 | Text | Single character code for the rejection of a modify. (See Order Reason Codes ) |  |  |  |  |  |  |  |  |
| MultilegReportingType | 1 | Alphanumeric | Corresponds to MultilegReportingType (442) in Cboe FIX Indicates the type of `Order Execution` message. `1` = Single-leg instrument `2` = Individual leg of multi-leg instrument `3` = Entire multi-leg instrument package `4` = Last individual leg of multi-leg instrument |  |  |  |  |  |  |  |  |
| NoOfSecurities | 4 | Binary | Corresponds to NoOfSecurities (8641) in Cboe FIX. Indicates the number of securities created by the member in this trading session. |  |  |  |  |  |  |  |  |
| OpenClose | 1 | Alphanumeric | Corresponds to OpenClose (77) in Cboe FIX. Indicates status of member position in the option. `O` = Open `C` = Close `N` = None 1 1 Orders with Capacity = `M` or `N` will not be required to specify OpenClose on their orders. A value of `N` may optionally be specified unless the series is limited to closing only. If the series is limited to closing only transactions, only Capacity = `M` will be permitted to submit OpenClose = `O` if the order has TimeInForce = `3` (IOC) and RoutingInst = `B` , or the order has a RoutingInst = `P` . An Open position cannot trade with an Open position for series limited to Closing Only transactions, even if the inbound IOC from the aggressing market maker is sent with that combination of tags. |  |  |  |  |  |  |  |  |
| OrderID | 8 | Binary | Corresponds to OrderID (37) in Cboe FIX. Order identifier supplied by Cboe. This identifier corresponds to the identifiers used in Cboe market data products. |  |  |  |  |  |  |  |  |
| OrderOrigin (C1 only) | 3 | Alphanumeric | Corresponds to OrderOrigin (9465) in Cboe FIX. Floor acronym of Market Maker on whose behalf this order is being entered by a floor broker. |  |  |  |  |  |  |  |  |
| OrderQty | 2\|4 | Binary | Corresponds to OrderQty (38) in Cboe FIX. Order quantity. System limit is 999,999 contracts. |  |  |  |  |  |  |  |  |
| OrderRejectReason | 1 | Text | Single character code for the rejection of an order. (See Order Reason Codes ) |  |  |  |  |  |  |  |  |
| OrderRestatementReason | 1 | Text | The reason for this Order Restated message. `E` = Reduction of OrdQty due to Equity Leg Reject (C1 only) `F` = Represented on Floor (C1 only) `L` = Reload `P` = Price Sliding Reprice `Q` = Liquidity Updated `R` = Reroute `S` = Ship and Post (SWP) `W` = Wash `f` = Unsolicited Floor Action (C1 only) Cboe reserves the right to add new values as necessary without prior notice. |  |  |  |  |  |  |  |  |
| OrderRouterSubsidy (C1 only) | 1 | Alpha | Corresponds to ORS (22003) in Cboe FIX. Order router subsidy eligibility (used for billing purposes). `N` = No (Default) `Y` = Yes |  |  |  |  |  |  |  |  |
| OrdType | 1 | Alphanumeric | Corresponds to OrdType (40) in Cboe FIX. `1` = Market `2` = Limit (default) `3` = Stop `4` = Stop Limit Stop/Stop Limit orders must be set to TimeInForce = `0` (DAY), `1` (GTC), or `6` (GTD) . Note market and stop/stop limit orders are not supported during GTH or Curb sessions. |  |  |  |  |  |  |  |  |
| OrigClOrdID | 20 | Text | Corresponds to OrigClOrdID (41) in Cboe FIX. On a `CancelOrder` message the OrigClOrdId 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. |  |  |  |  |  |  |  |  |
| OrigTime | 8 | DateTime | Time of the original transaction. |  |  |  |  |  |  |  |  |
| PostingInstruction | 1 | Alpha | `P` = Post Only (do not remove liquidity) `B` = Book Only (allow removal of liquidity, available for Market Makers only) `N` = Book Only, No Slide `R` = Post Only, No Slide (do not remove liquidity) `I` = Book Only IOC |  |  |  |  |  |  |  |  |
| PreventMatch | 3 | Alpha | Corresponds to PreventMatch (7928) in Cboe FIX. Three characters: 1st character - MTP Modifier: `N` = Cancel Newest `O` = Cancel Oldest `B` = Cancel Both `S` = Cancel Smallest `D` = Decrement larger / Cancel Smaller `d` = Same as D above, but only decrement LeavesQty. Do not restate OrderQty. 2nd character - Unique ID Level: `F` = Prevent Match at Firm(Member) Level `M` = Prevent Match at EFID Level 3rd character - Trading Group ID (optional): Member 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. The MTP Modifier (character 1) of the inbound order will be honored, except that if the inbound order specifies Decrement and the resting order does not, and the resting order is larger, then both orders will be cancelled. This exception is to protect the order entry software for the resting order from receiving an unexpected restatement message. If order entry software is prepared to handle unexpected restatement messages, this exception may be overridden at the port level by requesting Allow MTP Decrement Override functionality. Uses of MTP Modifier `D` or `d` and users of "Allow MTP Decrement Override" functionality must be prepared to receive an `Order Restated` message that decrements LeavesQty (and, for method `D` , OrdQty as well). On a `New Order Cross` message, only `N` and `O` are supported for the MTP modifier. MTP instructions on AIM orders will be used to prevent executions against AIM responses only; they will permit executions against resting or unrelated orders. Responses may only employ `N` (Cancel Newest) in which case the response will be cancelled and the auction order will continue. On a `New Order Cross` message, this field is only applicable to the Agency order. |  |  |  |  |  |  |  |  |
| Price | 4\|8 | Short Binary Price \| Binary Price | Corresponds to Price (44) in Cboe FIX. Limit price. Required for limit orders ( OrdType = `2` ). If specified on market orders ( OrdType = `1` ), the order will be rejected. Price may be of type Binary Price (8 bytes) or Short Binary Price (4 bytes), as specified in the message definitions. For complex orders, net pricing of the strategy. Four implied decimal places. (BZX, EDGX, and C2 only) Buy orders: Positive value, Debit Negative value, Credit Even order, 0 (Zero) Sell orders: Positive value, Credit Negative value, Debit Even order, 0 (Zero) |  |  |  |  |  |  |  |  |
| PriceType (C1 only) | 1 | Alphanumeric | Corresponds to PriceType (423) in Cboe FIX. `0` = Fixed cabinet trade price `2` = Price per unit (contract) (Default) `3` = Fixed amount (cash spread pricing) - only for complex orders routed to the floor |  |  |  |  |  |  |  |  |
| PurgeRejectReason | 1 | Text | Single character code for the rejection of a purge request. (See Order Reason Codes ) |  |  |  |  |  |  |  |  |
| PutOrCall | 1 | Alphanumeric | Corresponds to PutOrCall (201) in Cboe FIX. When sending Cboe native symbology, set PutOrCall to ASCII NUL (0x00). `0` = Put `1` = Call |  |  |  |  |  |  |  |  |
| QuoteCnt | 1 | Binary | Number of quotes in the message. Maximum is 20. |  |  |  |  |  |  |  |  |
| QuoteRejectReason | 1 | Text | Single character code for the rejection of an order. (See Quote Reason Codes ) |  |  |  |  |  |  |  |  |
| QuoteRejectSubReason | 1 | Text | Single character sub-reason code for the rejection of a quote. (See Order and Quote Subreason Codes ) |  |  |  |  |  |  |  |  |
| QuoteResult | 1 | Text | Result of the quote request. Acceptance: `A` = New Quote `I` = IOC Quote Accepted `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 `V` = No change, existing constituent series quote modify attempt after cutoff time (C1 only) 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 firm or Custom Group ID level `S` = Rejected, symbol not found `p` = Rejected, invalid price `r` = Invalid Remove `s` = Risk management risk root level `u` = Rejected, other reason `+` = Risk management EFID Group level `c` = Rejected, closing only series `v` = Rejected, attempt to add constituent series quote after cutoff time (C1 only) Additional reasons indicating a reject may be added in the future with no notice. |  |  |  |  |  |  |  |  |
| QuoteSymbol | 6 | Alphanumeric | Corresponds to Symbol (55) in Cboe FIX. Entire Cboe format symbol for a quote update. |  |  |  |  |  |  |  |  |
| QuoteUpdateID | 16 | Text | ID chosen by the member. Characters in the ASCII range 33-126 are allowed, except for comma , , semicolon ; , pipe \| , at @ , and double quotes " . Responses, both to the `Quote Update` and any `Quote Executions` , `Quote Cancellations` , and `Quote Modification` messages will include this identifier. Note: Cboe strongly recommends that QuoteUpdateID be kept unique for a trading day, and CAT reporting requirements mandate that QuoteUpdateID is unique for each Quote Update message sent to the Exchange. |  |  |  |  |  |  |  |  |
| RatioQty | 4 | Binary | Integer ratio of a complex leg with respect to the other legs of a complex instrument. |  |  |  |  |  |  |  |  |
| ReportTime | 8 | DateTime | Corresponds to TransactTime (60) in Cboe FIX. The time a Floor Trade is reported. Not to be confused with FloorTradeTime. |  |  |  |  |  |  |  |  |
| RequestReceivedTime | 8 | DateTime | A hardware timestamp, populated with nanosecond precision, that represents when the unitized order handler server NIC observed the inbound message (BZX Only). Reserved field on C1, C2, and EDGX and will be null-filled (0x00). A hardware timestamp, populated with nanosecond precision, that represents when the order handler server NIC observed the inbound message. |  |  |  |  |  |  |  |  |
| Reserved | * | Reserved | Reserved field. Must be null-filled (0x00) when sent by clients to Cboe. Any value may be present when sent by Cboe. Length is defined on a per-instance basis. |  |  |  |  |  |  |  |  |
| RestatementReason | 1 | Text | The reason for this Quote Restated message. `K` = Price sliding reprice (BZX only) `Q` = Liquidity `W` = Wash |  |  |  |  |  |  |  |  |
| RevisedLegs | 1 | Alphanumeric | Indicates if the legs on the created complex strategy have been reordered from the original request. If the legs were reordered, the order of the OpenClose fields on a `New Complex Order` message must be the order returned by the exchange, not the order from the original request. `1` = Legs were not reordered `2` = Legs were reordered |  |  |  |  |  |  |  |  |
| RiskResetResult | 1 | Text | `<space>` = Ignored; exceeds 1 reset per 100 milliseconds `C` = Rejected; exceeds Risk Group ID limit `D` = Rejected; automatic risk resets are disabled `E` = Rejected; empty ResetRisk field `F` = Rejected; exceeds firm reset limit `I` = Rejected; incorrect data center `M` = Rejected; invalid matching unit `S` = Rejected; exceeds symbol reset limit `U` = Rejected; invalid Symbol `Y` = Success `c` = Rejected; invalid ClearingFirm `y` = Rejected; in replay Additional reject values may be added in the future with no notice. |  |  |  |  |  |  |  |  |
| RiskRoot | 6 | Text | Corresponds to Symbol (55) in Cboe FIX. The underlying symbol. |  |  |  |  |  |  |  |  |
| RiskReset | 8 | Text | Corresponds to RiskReset (7692) in Cboe FIX. For use by customers using Cboe's Risk Management tools to reset or release EFID Group, EFID, Risk Root, or Custom Group ID level lockout conditions resulting from risk profile trips or self-imposed lockouts issued via `Cancel Order` or `Purge Orders` messages. Single Character Values - with counter reset: `S` = Risk Root level risk/lockout reset `F` = EFID level risk/lockout reset `C` = CustomGroupID lockout reset `G` = EFID Group level risk/lockout reset Single Character Values - without counter reset: `T` = Risk Root-level self-imposed lockout reset `E` = EFID self-imposed lockout reset Values may be combined together to allow for resets of multiple risk trips or self-imposed lockouts in a single message. For example, `GS` , `SC` , `FC` , and `SFC` are all acceptable values. The single character values with no counter reset will release a self-imposed lockout condition only without resetting any counters related to active risk rules. This may be useful for time based risk rules where the lockout may be released without resetting any risk values being tracked back to zero. If a conflicting value is provided the lockout release with counter reset will take precedence. For example, `ST` will release any lockout and reset any applicable root-level rule counters to zero. When a resting or inbound order is executed and a Risk Root level risk profile limit is reached, resting orders on the associated Risk Root will be cancelled and inbound orders on the Risk Root will be rejected until this field is filled with the value `S` on a subsequent `New Order` or `New Complex Order` message corresponding to a symbol on the same Risk Root. All active Risk Root level rules in the risk profile are reset at this time. Individual rules cannot be reset on their own. If an EFID-level rule is tripped, this tag can be filled with the value `F` to reset all EFID-level rules. While this will reset EFID-level rules, it is possible that both EFID and Risk Root level rules are currently tripped. Setting this field to `F` ’ will not clear Risk Root-level rules and the order may still be rejected. To clear both Risk Root and EFID-level rules, set this field to `SF` to reset all associated Risk Root and EFID-level lockouts. If orders have been locked out at the CustomGroupID level, inbound orders for the locked CustomGroupID will be rejected until this field is filled with a `C` value on a `New Order` or `New Complex` message order that uses the locked CustomGroupID . EFID and EFID Group resets are not allowed by default . Customers should contact the Cboe Trade Desk to reset these limits or request a change to the EFID Risk Reset port setting using the Logical Port Request form. If a risk limit is tripped or manually locked out at the end of the RTH session, the trip/lockout will persist into the Curb session (C1 only) . For more information, see the Cboe Titanium U.S. Options Risk Management Specification . |  |  |  |  |  |  |  |  |
| RiskStatusID | 16 | Text | User defined identifier of a Reset Risk message. |  |  |  |  |  |  |  |  |
| RouteDeliveryMethod | 3 | Text | Corresponds to RouteDeliveryMethod (9350) in Cboe FIX. `RTI` = Route to improve (default if not specified). Ability to receive price improvement will take priority over speed of execution. `RTF` = Route to Fill. Speed of execution will take priority over potential price improvement. Only applicable to RoutStrategy = `ROUT` |  |  |  |  |  |  |  |  |
| RoutingFirmID | 4 | Alpha | Corresponds to RoutingFirmID (7933) in Cboe FIX. Used to optionally convey the routing firm of the order. If supplied, value must be a valid member EFID. May be combined with MassCancelInst with Firm Filter set to `F` in a mass cancel request. |  |  |  |  |  |  |  |  |
| RoutingInst | 4 | Text | Corresponds to RoutingInst (9303) in Cboe FIX. Simple Instruments 1st character: `B` = Book Only (not routable, will remove from local book) `P` = Post Only (not routable) 1 `R` = Routable `S` = Super Aggressive - Cross or Lock (order will be removed from the book and routed to any quote that is locking or crossing the order) `X` = Aggressive - Cross Only (order will be removed from the book and routed to any quote that is crossing the order ) 2nd character: (C1, EDGX and effective 09/04/26 C2 only) `L` = Do Not Expose order via Step-Up Mechanism (SUM) `S` = Expose order via Step Up Mechanism (SUM) 2 Complex Instruments 1st character: `B` = Book Only (will remove from local book), allowed to interact with both single-leg and other complex orders. `D` = Complex Book Only, allowed to interact with other complex orders only. 3 `P` = Post Only (adds liquidity only) 2nd character: `L` = Do Not Expose order via Complex Options Auction (COA) `S` = Expose order via Complex Options Auction (COA) 4 1 Post Only orders with DisplayIndicator (9479) = `R` will be cancelled back even if they would be immediately executable with price improvement (C1, C2, and EDGX only) . 2 Routable Orders identified with RoutingInst = `R` , `RS` , `S` , `SS` , `X` , or `XS` , RoutStrategy = `ROUT` , and AuctionId not supplied, or Non-Routable Orders identified with RoutingInst = `BS` , ExecInst != `f` , TimeInForce != `4` , and MinQty not supplied will participate in the Step-Up Mechanism (SUM) before routing, booking, or cancelling back. 3 Only valid with TimeInForce = `Day` or `IOC` , otherwise rejected. 4 All non-IOC complex orders will be eligible for COA unless otherwise specified. |  |  |  |  |  |  |  |  |
| RoutStrategy | 6 | Text | Corresponds to RoutStrategy (9400) in Cboe FIX. All exchanges: `ROUT` = Book + Street `DIRC` 5 = Book + Directed IOC or Directed ISO if ExecInst = `f` `SWPA` = Book + Sweep Street (default) 5 ExDestination must be populated with RoutStrategy = `DIRC` . Must be specified when sending non-book only ISO, otherwise the order will be rejected. |  |  |  |  |  |  |  |  |
| ScratchPad | 2 | Binary | Field ignored by Cboe (any value is accepted). |  |  |  |  |  |  |  |  |
| SecondaryExecID | 8 | Binary | Indicates whether a fill or partial fill is a complex instrument fill or a single leg fill that comprises a complex execution. If SecondaryExecID (527) is not present, the fill is a single leg fill only. If SecondaryExecID is present and is the same as the ExecID (17), the fill represents a complex execution for which associated single leg fills will follow. Single leg fills associated with a complex execution will contain a SecondaryExecID of the associated complex execution. |  |  |  |  |  |  |  |  |
| SecondaryOrderID | 8 | Binary | Corresponds to SecondaryOrderID (198) in Cboe FIX. Denotes an alternative OrderID which is present on Cboe market data feeds (for example, to hide that a reserve (iceberg) order has reloaded). Or, OrderID of the contra side of a prevented match. |  |  |  |  |  |  |  |  |
| SendTime | 8 | DateTime | UTC timestamp when the mass cancel or purge was sent by the Market Maker to the Exchange. This timestamp is required to be at least in millisecond granularity but the CAT NMS Plan requires Industry Members to report the SendTime with the finest increment supported by the Industry Member. This is required to be populated whenever a mass cancel or purge message is expected to cancel one or more Market Maker ( capacity = `M` ) quotes that were submitted using the `Quote Update` message so that the appropriate timestamp can be captured and sent to the CAT. This field must be populated on all `Cancel Order` and `Purge Order` messages. |  |  |  |  |  |  |  |  |
| SenderLocationID (C1 only) | 1 | Alphanumeric | Corresponds to SenderLocationID (142) in Cboe FIX. `F` = Floor <blank> = (or not present) for electronic execution. |  |  |  |  |  |  |  |  |
| SessionEligibility (C1 only) | 1 | Alpha | Corresponds to SessionEligibility (22017) in Cboe FIX. `R` = Order participates in Regular Trading Hours (default) `A` = Order participates in both Global and Regular Trading Hours. Also allows for participation in Curb Trading Session. `B` = Order participates in both RTH and Curb Session. |  |  |  |  |  |  |  |  |
| Side | 1 | Alphanumeric | Corresponds to Side (54) in Cboe FIX. `1` = Buy `2` = Sell `5` = Sell Short (stock leg only) (C1 and EDGX only) `6` = Sell Short Exempt (stock leg only) (C1 and EDGX only) |  |  |  |  |  |  |  |  |
| SizeModifier | 1 | Text | Controls the behavior of the quote OrderQty field. Using `R` ensures 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. Members are expected to track the remaining quantity of each quote as resulting size is not included on the `Quote Update Acknowledgement` message. |  |  |  |  |  |  |  |  |
| SourceMatchingUnit | 1 | Binary | Matching unit originating the message |  |  |  |  |  |  |  |  |
| StopPx | 8 | Binary Price | Corresponds to StopPx (99) in Cboe FIX. For simple orders: Stop price. Required if OrdType = `3` (Stop) or `4` (Stop Limit) . Stop and Stop Limit orders will only be triggered off Last Sale Eligible trades. Stop/Stop Limit orders will only elect based off of RTH quotes and trades. For complex orders (effective TBD) : The trigger price for stop-limit complex orders. Required if OrdType (40) = 4. Only one trigger condition can be designated per order. The stop limit trigger conditions are as follows: Net price of the complex strategy: an order will trigger when either the same side Market-Maker SBBO equals or betters the designated threshold price, or a trade in the same complex instrument occurs via COB, COA, AIM, SAM, or PAR at or better than the designated threshold price. Underlying price : an order will trigger when a designated threshold price of the underlying security is either (i) at or above the underlying price or index level or (ii) at or below the underlying price or index level. For (i) the underlying price designated must be higher, and for (ii) the underlying price designated must be lower, than the current value of the equity same side NBBO or index level. If not, the order will be rejected. Equity: triggers when the underlying security bid (ask) is equal to or higher (lower) than the designated stop price, or a trade occurs at a price equal to or higher (lower) than the stop price. Index: triggers when the underlying index level is equal to or higher (lower) than the designated threshold price. This trigger does not include any bid/ask component. |  |  |  |  |  |  |  |  |
| StopPxType (Effective TBD) | 1 | Text | Indicates what kind of stop price is being sent. `L` = Fixed limit price `B` = Fixed underlying bid price or index level (complex orders only) `A` = Fixed underlying ask price or index level (complex orders only) |  |  |  |  |  |  |  |  |
| StrategyID (C1 only) | 1 | Alphanumeric | Corresponds to StrategyID (22002) in Cboe FIX. Used to declare when a strategy is used. `C` = Conversion `R` = Reversal `M` = Merger `S` = Short stock interest `J` = Jelly roll `F` = CompressionForum `B` = BoxSpread `A` = BoxSwap |  |  |  |  |  |  |  |  |
| StrikePrice | 8 | Binary Price | Corresponds to StrikePrice (202) in Cboe FIX. Strike Price for option, 0 - 999,999.99. When sending Cboe native symbology, set StrikePrice to zero. |  |  |  |  |  |  |  |  |
| SubLiquidityIndicator | 1 | Alphanumeric | Additional information about an execution. Cboe may add additional values without notice. Members must gracefully ignore unknown values. `ASCII NUL (0x00)` = No Additional Information `S` = Execution from order that set the NBBO `J` = NBBO Joiner `B` = Step Up Mechanism (C1 and EDGX Only) `U` = Market Turner (C1 Only) `b` = AIM (C1 and EDGX Only) `C` = Carried `D` = Done For Day `Q` = QCC (C1 and EDGX Only) `s` = SAM (C1 and EDGX Only) `P` = PCC (C1 Only) `F` = RFC (C1 Only) |  |  |  |  |  |  |  |  |
| Symbol | 8 | Alphanumeric | Corresponds to Symbol (55) in Cboe FIX. Entire Cboe format symbol |  |  |  |  |  |  |  |  |
| TargetMatchingUnit | 1 | Binary | Matching unit to which the message is to be directed. In BZX Only, the field should be set to null (0x00) since all purge messages are handled by unitized BOE3 sessions. |  |  |  |  |  |  |  |  |
| TargetPartyID (C1 and EDGX only) | 4 | Alpha | Corresponds to TargetPartyID (1462) in Cboe FIX. A valid Parent ID of the Directed Market Maker (EDGX only) or Preferred Market Maker (C1 only) . Required for directed orders. On `New Order Cross` messages, this field is only applicable to the Agency order. |  |  |  |  |  |  |  |  |
| Text | 60 | Text | Printable ASCII text, null (0x00) terminated. See Reason Codes for details. |  |  |  |  |  |  |  |  |
| TiedHedge (C1 only) | 1 | Alpha | Corresponds to TiedHedge (22018) in Cboe FIX. Order is a tied hedge. `N` = No (Default) `Y` = Yes |  |  |  |  |  |  |  |  |
| TimeInForce | 1 | Alphanumeric | Corresponds to TimeInForce (59) in Cboe FIX. `0` = Day - Expires at end of market day. (Default) `1` = GTC - Remains in system until executed, cancelled or option expires. 1 `2` = At the Open - Will remain queued and only interact in the Cboe Opening Process (BZX, C2, and EDGX only) or the Cboe Opening Auction (C1 only). `3` = IOC - Portion not filled immediately is cancelled. Market orders are implicitly IOC for non-complex orders. `4` = FOK - An IOC where the entire size must be filled, else the order will be cancelled back. Not compatible with Step-Up Mechanism (SUM). `6` = GTD - Expires at specified ExpireTime for a specified day. 1 `7` = At the Close - Orders held for execution until 180 seconds before series is scheduled to close. 1 Bulk Quoting Ports will only support TimeInForce values of Day or GTD with a same day expiration on C1, C2, and EDGX. |  |  |  |  |  |  |  |  |
| TradeDate | 4 | Date | Corresponds to TradeDate (75) in Cboe FIX. |  |  |  |  |  |  |  |  |
| TradeThroughAlertType (C1 only) | 1 | Alphanumeric | Corresponds to TradeThroughAlertType (21098) in Cboe FIX. Indication of a type of trade through. `0` = No trade through `1` = NBBO `2` = BBO (local best bid or offer) `3` = SBBO (market quote of complex derived by legs) `4` = Book trade through (trade through customer size) `5` = Due Dilligence trade through |  |  |  |  |  |  |  |  |
| TransactionTime | 8 | DateTime | The exchange timestamp of the transaction. Reject messages will have a TransactionTime of the order gateway. |  |  |  |  |  |  |  |  |
| UseDrillThruOverride | 1 | Text | Specifies whether to apply the value in DrillThruProtection . Default is `N` if not set. `N` = No. (Do not use the value present in DrillThruProtection ) `Y` = Yes. (Use the value present in DrillThruProtection ) |  |  |  |  |  |  |  |  |
| WorkingPrice | 8 | Binary Price | Corresponds to WorkingPrice (9690) in Cboe FIX. Only present if an order is fully or partially booked. If price had to be adjusted to a less aggressive value for some reason, the adjusted price will be reported here, otherwise equals price. |  |  |  |  |  |  |  |  |

## Reason Codes

### Order Reason Codes

The following is a list of all order related reason codes used by Cboe. 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. Cboe may add additional reason codes without notice. Members must gracefully ignore unknown values.

**Table 1. Order Reason Codes**

| Code | Description |
|---|---|
| A | Admin |
| D | Duplicate identifier (e.g., ClOrdID) |
| F | Could not reflect to consolidated quote (OPRA) |
| H | Halted |
| I | Incorrect data center |
| J | Too late to cancel |
| K | Order rate threshold exceeded |
| L | Order would lock or Cross NBBO |
| M | Order size exceeded |
| 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 fill |
| Q | Waiting for first trade |
| R | Routing Unavailable |
| T | Fill would trade through the NBBO |
| U | User requested |
| V | Would wash |
| W | Add liquidity only order would remove |
| X | Order expired |
| Y | Symbol not supported |
| Z | Unforeseen reason |
| c | Only Close transactions accepted |
| f | Risk management EFID or Custom Group ID level |
| m | Market access risk limit exceeded |
| o | Max open orders count exceeded |
| r | Reserve reload |
| s | Risk management risk root level |
| w | Would remove on unslide |
| x | Crossed market |
| y | Order received by Cboe during replay |
| z | Session End |
| + | Risk management EFID Group level |
| 4 | After volatility cutoff |

### Quote Reason Codes

The following is a list of all quote reason codes used by Cboe. 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. Cboe may add additional reason codes without notice. Members must gracefully ignore unknown values.

**Table 1. Quote Reason Codes**

| Code | Description |
|---|---|
| C | Invalid EFID (ClearingFirm) |
| D | Invalid WashId |
| E | Invalid SessionEligibility |
| F | Not enabled for quotes |
| I | Incorrect data center |
| L | Invalid QuoteCnt |
| M | Symbols not on same matching engine |
| P | Invalid PostingInstruction |
| Q | Invalid QuoteUpdateID |
| R | Risk root does not match across quotes |
| S | Symbol not found |
| U | Message unable to be sent to Matching Engine |
| W | Invalid WashPreventType |
| a | Admin |
| c | Invalid Capacity |
| d | Close only |
| f | Risk management EFID or Custom Group ID level |
| m | Invalid WashMethod |
| n | Exceedes max notional value per order |
| o | Invalid Open/Close |
| p | Risk management risk root level |
| r | Invalid Remove |
| s | Invalid Side |
| t | Invalid SendTime |
| u | Symbol range unreachable |
| x | Exceeds max size per order |
| y | Quote received by Cboe during replay |
| z | Invalid reduce size restriction |

### Order and Quote Subreason Codes

The following is a list of subreason codes used to indicate additional detail for order rejections or cancellations. The 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 or cancel reason. Cboe may add additional values without notice. Users must gracefully ignore unknown values.

**Table 1. Order and Quote Subreason Codes**

| Code | Description |
|---|---|
| A | Purge/mass cancel EFID level by user |
| B | Purge/mass cancel Symbol level by user |
| C | Purge/mass cancel Custom Group ID level by user |
| E | EFID level lockout by Cboe Trade Desk admin |
| J | Firm disconnect |
| K | ME disconnect |
| L | Unregistered MM Account |
| S | Minimum size requirement not met |
| T | Cboe Trade Desk admin |
| f | Risk management EFID level by rule |
| s | Risk management Symbol level by rule |
| + | Risk management EFID Group level by rule |

## List of Message Types

**Table 1. Member to Cboe**

| Message Name | Level | Type | Sequenced* |
|---|---|---|---|
| ClientHeartbeat | Session | 0x0003 | No |
| LoginRequest | Session | 0x0001 | No |
| LogoutRequest | Session | 0x0002 | No |
| AddFloorTradeUSOptionsV1 | Application | 0x07E3 | Yes |
| CancelOrderUSOptionsV1 | Application | 0x07DA | Yes |
| ComplexQuoteUpdateShortUSOptionsV1 | Application | 0x07E2 | Yes |
| ComplexQuoteUpdateUSOptionsV1 | Application | 0x07E1 | Yes |
| DeleteFloorTradeUSOptionsV1 | Application | 0x07E6 | Yes |
| FloorTradeConfirmationUSOptionsV1 | Application | 0x07E4 | Yes |
| MassCancelOrderUSOptionsV1 | Application | 0x07DF | Yes |
| ModifyOrderUSOptionsV1 | Application | 0x07DB | Yes |
| NewComplexInstrumentUSOptionsV1 | Application | 0x07D5 | Yes |
| NewComplexOrderShortUSOptionsV1 | Application | 0x07D7 | Yes |
| NewComplexOrderUSOptionsV1 (Sunset TBD) | Application | 0x07D6 | Yes |
| NewComplexOrderUSOptionsV2 (Effective TBD) | Application | 0x07E7 | Yes |
| NewOrderCrossMultilegUSOptionsV1 | Application | 0x07D8 | Yes |
| NewOrderCrossUSOptionsV1 | Application | 0x07D3 | Yes |
| NewOrderUSOptionsV1 | Application | 0x07D1 | Yes |
| NewOrderShortUSOptionsV1 | Application | 0x07D2 | Yes |
| PurgeOrdersUSOptionsV1 | Application | 0x07E0 | Yes |
| PurgeOrdersUSOptionsV2 | Application | 0x07E5 | Yes |
| QuoteUpdateShortUSOptionsV1 | Application | 0x07DD | Yes |
| QuoteUpdateUSOptionsV1 | Application | 0x07DC | Yes |
| ResetRiskUSOptionsV1 | Application | 0x07DE | Yes |

*For sequenced messages from Member to Cboe, a sequence number of `0` will always be accepted and is treated as if it were the next expected sequence number.

**Table 2. Cboe to Member**

| Message Name | Level | Type | Sequenced |
|---|---|---|---|
| LoginResponse | Session | 0x01F5 | No |
| LogoutResponse | Session | 0x01F7 | No |
| ReplayComplete | Session | 0x01F6 | No |
| ServerHeartbeat | Session | 0x01F8 | No |
| AddFloorTradeRejectedUSOptionsV1 | Application | 0x09E3 | No |
| CancelRejectedUSOptionsV1 | Application | 0x09D2 | No |
| CarriedRestatementUSOptionsV1 | Application | 0x09CE | Yes |
| ComplexQuoteExecutionUSOptionsV1 | Application | 0x09E1 | Yes |
| CrossOrderAcknowledgementUSOptionsV1 | Application | 0x09C6 | Yes |
| CrossOrderCancelledUSOptionsV1 | Application | 0x09D1 | Yes |
| CrossOrderRejectedUSOptionsV1 | Application | 0x09C8 | No |
| DeleteFloorTradeAcknowledgementUSOptionsV1 | Application | 0x09E6 | No |
| DeleteFloorTradeRejectedUSOptionsV1 | Application | 0x09E5 | No |
| DoneForDayUSOptionsV1 | Application | 0x09CF | Yes |
| FloorOrderRepresentedUSOptionsV1 | Application | 0x09E7 | Yes |
| FloorTradeConfirmationRejectedUSOptionsV1 | Application | 0x09E4 | No |
| FloorTradeNotificationUSOptionsV1 | Application | 0x09E2 | No |
| MassCancelAcknowledgementUSOptionsV1 | Application | 0x09DB | No |
| MassCancelRejectedUSOptionsV1 | Application | 0x09DC | No |
| ModifyRejectedUSOptionsV1 | Application | 0x09CC | No |
| NewComplexInstrumentAcceptedUSOptionsV1 | Application | 0x09C9 | Yes |
| NewComplexInstrumentRejectedUSOptionsV1 | Application | 0x09CA | No |
| OrderAcknowledgementUSOptionsV1 | Application | 0x09C5 | Yes |
| OrderCancelledUSOptionsV1 | Application | 0x09D0 | Yes |
| OrderExecutionUSOptionsV1 | Application | 0x09D3 | Yes |
| OrderModifiedUSOptionsV1 | Application | 0x09CB | Yes |
| OrderRejectedUSOptionsV1 | Application | 0x09C7 | No |
| OrderRestatedUSOptionsV1 | Application | 0x09CD | Yes |
| PurgeAcknowledgementUSOptionsV1 | Application | 0x09DD | No |
| PurgeNotificationUSOptionsV1 | Application | 0x09DF | No |
| PurgeRejectedUSOptionsV1 | Application | 0x09DE | No |
| QuoteCancelledUSOptionsV1 | Application | 0x09D7 | No |
| QuoteExecutionUSOptionsV1 | Application | 0x09D8 | Yes |
| QuoteRestatedUSOptionsV1 | Application | 0x09D9 | Yes |
| QuoteUpdateAcknowledgementUSOptionsV1 | Application | 0x09D5 | No |
| QuoteUpdateRejectedUSOptionsV1 | Application | 0x09D6 | No |
| ResetRiskAcknowledgementUSOptionsV1 | Application | 0x09DA | No |
| TradeCancelCorrectUSOptionsV1 | Application | 0x09D4 | Yes |

## Port Attributes

The table below lists the port attributes that are configurable on the port or firm level. Changes to these attributes can be made by contacting the Cboe Trade Desk. Port Attribute changes made intra-day by the Cboe Trade Desk will not affect existing quotes or orders. In order for the desired intra-day port attribute to be applied to existing quotes or orders, you must first cancel or send a quote with zero price and size and then re-enter the order or quote.

**Table 1. BOEv3 Port Attributes**

| Attribute | Default | Description |
|---|---|---|
| Allow Directed ISO* | Yes | Allow or disallow ISO orders directed to other market centers. |
| Allow ISO* | Yes | Allow or disallow ISO orders. |
| Allow MTP Decrement Override* ^ | No | Overrides the exception that requires both the resting and inbound order to be marked as "Decrement". |
| Allow Sponsored Member MTP Control*^ | No | Allow Sponsored Member to override port default for match trade prevention by using PreventMatch on the order level. |
| Allow Test Symbols Only | Disabled | Allow or disallow orders in non-test symbols. |
| Allowed Clearing Executing Firm ID(s)* | All EFIDS | Executing Firm ID(s) allowed for trading on the port. |
| Cancel on Disconnect | All | Cancels open orders upon order handler session disconnect; both graceful and ungraceful. If Cancel On Disconnect is set, open orders in Symbols not in Closed state at the time of the disconnect are cancelled. `All` = Cancel Day and GTC/GTD orders `Day` = Cancel only Day orders `None` = Disabled BOE Quoting ports require Cancel on Disconnect set to All or Day. Default will be used if not specified. |
| 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/GTD orders. For BZX, C2, and EDGX , in any event, if a failover takes longer than 5 minutes, all orders are cancelled (including GTC/GTD Orders). For C1 if a failover takes longer than 15 minutes, all orders are cancelled (including GTC/GTD Orders). `All` = Cancel Day and GTC/GTD orders `Day` = Cancel only Day orders `None` = Disabled BOE Bulk Quoting ports require Cancel on ME Disconnect set to All or Day. Default will be used if not specified. |
| Cancel on Regulatory Halt | All (BZX and EDGX Only) None (C1 and C2 Only) | Cancels open orders upon receipt of a Regulatory Halt. `All` = Cancel Day and GTC/GTD orders `Day` = Cancel only Day orders `None` = Disabled |
| Cancel on Reject+ | No | Cancels an order upon a modify reject. |
| Cancel Open Orders on DROP Port Disconnect* | None | 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 and GTC/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). |
| Crossed Market Cancel / Reject$ | No | Reject new orders when the NBBO in the security is crossed. Routable orders will have any remaining quantity cancelled back when the order returns to the book. Order modifications causing a loss in priority will result in a cancel of the original order if the NBBO is crossed upon receipt of the modify request. Quotes are always accepted, even in a crossed market. |
| Default Account | None | Default Account to be used if none is sent on inbound messages. Allows 16 characters or less (ASCII 33-126) but a max of 10 characters will be passed through to clearing. |
| Default Attributed Quote*+ | X | Default value for AttributedQuote . May override at order level. `C†` = Attribute ClientIDAttr only (C1 only) `N` = Don’t Attribute (may override at order level) `Y` = Attribute EFID only `Z` = Attribute EFID and ClientIDAttr `X*` = (Default) Never Attribute (may not efinitionden at order level) * On EDGX and BZX , this setting may only be changed after executing Attribution Addendum to Exchange User Agreement. |
| Default ClearingOptionalData | None | Default ClearingOptionalData to be used if none is sent on inbound messages. Allows 16 characters or less (ASCII 33-126). |
| Default ClientIDAttr | None | Default ClientIDAttr to be used if none is specified on inbound messages. |
| Default EquityExDestination | None | Default EquityExDestination to be used if it is blank on inbound messages. |
| Default EquityPartyID (C1 and EDGX only) | None | Default EquityPartyID to be used if none is specified on inbound messages. |
| Default ExecutingFirmID | None | Default Executing Firm ID to use if none is sent on a `New Order` or `New Complex Order` message. |
| Default FloorDestination (C1 only) | None | Specifies a default PAR workstation (ex. W001) to route to on the floor (or ‘PARO’ to route to the Floor PAR Official of the underlying symbol) if not specified on inbound messages. 4 characters or less (ASCII 33-126). |
| Default FloorRoutingInst* (C1 only) | E | `D` = Direct. Do not attempt to process electronically `E` = Electronic only `X` = Route to floor if unable to process electronically. *When FloorRoutingInst = D or X, RoutingInst (9303) must be set to B or R for simple orders; or B for complex instruments. |
| Default MTP Value*^+ | None | Specifies default value for PreventMatch. |
| Default Price Sliding | `BZX` = S EDGX/ `C2` = P | Default price sliding behavior. See DisplayIndicator for details. |
| Default Routing Instruction+ | 9303=RS 9350=RTI 9400=SWPA | Specifies a default value for routing. Fields can be overridden at the order level. The defaults are RoutingInst = RS, RouteDeliveryMethod = RTI, and RoutStrategy = SWPA. |
| Duplicative Order Protection Action$ | 1 | Action taken when Duplicative Order Protection criteria is met: 1 = Not enabled. 2 = Reject any offending orders. 3 = Disable port for ClearingFirm . Must call Cboe Trade Desk to reenable. |
| Duplicative Order Protection Order Count Threshold$ | None | Number of consecutive orders with the same ClearingFirm, Price, OrdQty, and Symbol that must be seen to initiate Duplicative Order Protection Action. |
| EFID Filter for Purge Ports | None | Specify up to 10 EFIDs per purge port for which purges will be permitted. If a purge request (with first character of MassCancelInst =`F`) specifies an EFID not included in the list of configured EFIDs, the purge request will be rejected. If a purge port is configured with multiple EFIDs and a purge request is sent (with first character of MassCancelInst = `A`) without any EFIDs specified, the purge will be applied only to the list of configured EFIDs. |
| EFID Risk Reset | Disabled | Configures how risk may be reset after a risk trip. `Disabled` = (Default). Will require manually resetting all EFID Group and EFID-Level Risk trips by contacting the Trade Desk. Enabled = Will allow EFID Group and EFID-level Risk resets using RiskReset of ‘F’ or ‘G’. |
| Enable Market Maker Floor Trade Notifications (C1 only) | No | Enables Market Maker Floor Trade Notifications for specific Market Maker acronyms on a port. |
| Fat Finger Protection*$ | BZX/ EDGX= None C2= See specification for defaults | Orders entered through the NBBO by a specified percentage or dollar based limit price tolerance will be rejected. Limits may be different for different price ranges and price ranges may vary across markets. Please see the Cboe Titanium U.S. Equities/Options Web Portal Port Controls Specification for complete details. |
| Forced Open Cancel Instruction | DoNotCancel | Specifies order handling during a forced opening. `DoNotCancel` = Preserve Orders (Default) `CancelMarket` = Cancel Open Market Orders Only (preserve Limit Orders) `CancelAll` = Cancel All Open Orders |
| Market Maker Floor Trade Notification Symbology (C1 only) | Cboe | Specifies the symbology used on Market Maker Floor Trade Notifications. `Cboe` = Six character Cboe Symbol ID `OSI` = OSI Symbology ( PutOrCall , StrikePrice , and MaturityDate will be returned) |
| Market Maker Reject if Cancel on Disconnect disabled | No | Rejection of Market Maker or Away-Market Maker orders if Cancel on Disconnect is not enabled. Non-Market Maker capacity order swill be unaffected with this configuration. |
| Maximum Order Dollar Value* | Unlimited | Maximum dollar value per order. |
| Maximum Order Size* | 25,000 99,000 (C1) | Maximum order quantity. |
| Multi-Segment Holiday Day Order Handling (C1 only) | None | Controls whether Day ( TimeInForce (59) = 0) orders are cancelled or preserved across holiday trading segments comprising a single business date. `None` = All Day orders on the book are carried between trading segments `Cancel` = All Day orders on the book at the conclusion of the current trading segment are cancelled back. |
| Port Order Rate Threshold | 5,000 msgs/s 1 msg/sec for test products. | The maximum allowed message rate on the session. When the first non-session level message is received, a one second window begins, during which no more than 4,999 additional non-session level messages are allowed. If the rate is exceeded, all new orders in the time window are rejected, modifies are treated as cancels, and cancels are processed. Maximum value is 5,000 msgs/sec. For Bulk Quoting ports, the default threshold is unlimited. Note: Order handler burst rates towards each matching unit may be limited as described in Architecture and Message in Flight Settings . |
| Reject Orders on DROP Port Disconnect* | No | If all Standard FIX DROP ports associated with an order entry session experience disconnection, new orders will be rejected until at least one Standard FIX DROP port session is reestablished. Note this parameter does not apply to Order-By-Order drop ports (ODROP). |
| Reject Orders on DROP Port Timeout (seconds)* | 30 seconds | Only applicable if Reject Orders on DROP Port Disconnect is enabled. When the last Standard FIX DROP port associated with an order entry session has disconnected, begin rejecting orders on the order entry session if a Standard FIX DROP session has not been reestablished within this timeout. Minimum value allowed is 0 seconds. |

*Sponsored Members require written approval from Sponsors to update these settings on ports associated with a Sponsor’s MPID.

+Port attribute can be overridden on an order-by-order basis.

^Requires certification.

$Not supported for quotes.

## Support

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

## Appendix A: Example Application Messages

### Member to Cboe

#### NewOrderUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `cb 00` | 203 |
| MessageType | `d1 07` | `NewOrderUSOptionsV1` (2001, 0x07d1) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `b0 01 00 00` | 432 |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| Side | `32` | Sell (50, 0x32, '2') |
| OrderQty | `dc 05 00 00` | 1500 |
| ClearingFirm | `00 00 00 00` |  |
| ClearingAccount | `00 00 00 00` |  |
| Price | `58 86 03 00 00 00 00 00` | 23.10 |
| ExecInst | `00` | NotSet (0, 0x00) |
| OrdType | `32` | Limit (50, 0x32, '2') |
| TimeInForce | `36` | GTD (54, 0x36, '6') |
| MinQty | `00 00 00 00` | 0 |
| MaxFloor | `00 00 00 00` | 0 |
| Symbol | `34 33 32 31 00 00 00 00` | 4321 |
| Capacity | `41` | Agency (65, 0x41, 'A') |
| RoutingInst | `00 00 00 00` |  |
| Account | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| DisplayIndicator | `00` | NotSet (0, 0x00) |
| PreventMatch | `00 00 00` |  |
| ExpireTime | `28 18 14 cf 13 84 32 17` | 2022-12-20 13:40:32.321321 |
| MaturityDate | `00 00 00 00` | 0000-00-00 |
| StrikePrice | `00 00 00 00 00 00 00 00` | 0.00 |
| PutOrCall | `00` | NotSet (0, 0x00) |
| OpenClose | `00` | NotSet (0, 0x00) |
| CMTANumber | `00 00 00 00` | 0 |
| TargetPartyID | `00 00 00 00` |  |
| SessionEligibility | `00` | NotSet (0, 0x00) |
| AttributedQuote | `00` | NotSet (0, 0x00) |
| DisplayRange | `00 00 00 00` | 0 |
| StopPx | `00 00 00 00 00 00 00 00` | 0.00 |
| RoutStrategy | `00 00 00 00 00 00` |  |
| RouteDeliveryMethod | `00 00 00` |  |
| ExDestination | `00` |  |
| AuctionID | `00 00 00 00 00 00 00 00` | 000000000000 |
| RoutingFirmID | `00 00 00 00` |  |
| CustomGroupID | `12 00` | 18 |
| ClearingOptionalData | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| ClientIDAttr | `00 00 00 00` |  |
| FrequentTraderID | `00 00 00 00 00 00` |  |
| Compression | `00` | NotSet (0, 0x00) |
| FloorDestination | `00 00 00 00` |  |
| FloorRoutingInst | `00` | NotSet (0, 0x00) |
| OrderOrigin | `00 00 00` |  |
| OrderRouterSubsidy | `00` | NotSet (0, 0x00) |
| PriceType | `00` | NotSet (0, 0x00) |
| Held | `00` | NotSet (0, 0x00) |
| Scratchpad | `00 00` | 0 |

#### NewOrderShortUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `7f 00` | 127 |
| MessageType | `d2 07` | `NewOrderShortUSOptionsV1` (2002, 0x07d2) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `b1 01 00 00` | 433 |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| Side | `32` | Sell (50, 0x32, '2') |
| OrderQty | `dc 05 00 00` | 1500 |
| ClearingFirm | `00 00 00 00` |  |
| ClearingAccount | `00 00 00 00` |  |
| Price | `58 86 03 00 00 00 00 00` | 23.10 |
| ExecInst | `00` | NotSet (0, 0x00) |
| OrdType | `32` | Limit (50, 0x32, '2') |
| TimeInForce | `36` | GTD (54, 0x36, '6') |
| MinQty | `00 00 00 00` | 0 |
| MaxFloor | `00 00 00 00` | 0 |
| Symbol | `34 33 32 31 00 00 00 00` | 4321 |
| Capacity | `41` | Agency (65, 0x41, 'A') |
| RoutingInst | `00 00 00 00` |  |
| Account | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| DisplayIndicator | `00` | NotSet (0, 0x00) |
| PreventMatch | `00 00 00` |  |
| OpenClose | `00` | NotSet (0, 0x00) |
| CMTANumber | `00 00 00 00` | 0 |
| SessionEligibility | `00` | NotSet (0, 0x00) |
| AttributedQuote | `00` | NotSet (0, 0x00) |
| RoutStrategy | `00 00 00 00 00 00` |  |
| ExDestination | `00` |  |
| AuctionID | `00 00 00 00 00 00 00 00` | 000000000000 |
| CustomGroupID | `12 00` | 18 |
| FrequentTraderID | `00 00 00 00 00 00` |  |
| Scratchpad | `00 00` | 0 |

#### NewOrderCrossUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `18 01` | 280 |
| MessageType | `d3 07` | `NewOrderCrossUSOptionsV1` (2003, 0x07d3) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `b2 01 00 00` | 434 |
| CrossID | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| CrossType | `00` | NotSet (0, 0x00) |
| CrossPrioritization | `00` | NotSet (0, 0x00) |
| Price | `58 86 03 00 00 00 00 00` | 23.10 |
| OrderQty | `dc 05 00 00` | 1500 |
| Symbol | `34 33 32 31 00 00 00 00` | 4321 |
| MaturityDate | `00 00 00 00` | 0000-00-00 |
| StrikePrice | `00 00 00 00 00 00 00 00` | 0.00 |
| PutOrCall | `00` | NotSet (0, 0x00) |
| ExecInst | `00` | NotSet (0, 0x00) |
| AttributedQuote | `00` | NotSet (0, 0x00) |
| TargetPartyID | `00 00 00 00` |  |
| PreventMatch | `00 00 00` |  |
| AutoMatch | `00` | NotSet (0, 0x00) |
| AutoMatchPrice | `00 00 00 00 00 00 00 00` | 0.00 |
| LastPriority | `00` | NotSet (0, 0x00) |
| RoutingFirmID | `00 00 00 00` |  |
| ClientIDAttr | `00 00 00 00` |  |
| EquityTradePrice | `00 00 00 00 00 00 00 00` | 0.00 |
| EquityTradeSize | `00 00 00 00` | 0 |
| EquityTradeVenue | `00` | NotSet (0, 0x00) |
| EquityTransactTime | `00 00 00 00 00 00 00 00` | 1970-01-01 00:00:00.000000 |
| EquityBuyClearingFirm | `00 00 00 00` |  |
| EquitySellClearingFirm | `00 00 00 00` |  |
| Compression | `00` | NotSet (0, 0x00) |
| OrderRouterSubsidy | `00` | NotSet (0, 0x00) |
| Scratchpad | `00 00` | 0 |
| AllocCnt | `02` | 2 |
| allocs.Side[1/2] | `32` | Sell (50, 0x32, '2') |
| allocs.AllocQty[1/2] | `00 00 00 00` | 0 |
| allocs.ClOrdID[1/2] | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| allocs.Capacity[1/2] | `41` | Agency (65, 0x41, 'A') |
| allocs.OpenClose[1/2] | `00` | NotSet (0, 0x00) |
| allocs.GiveUpFirmID[1/2] | `00 00 00 00` |  |
| allocs.Account[1/2] | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| allocs.CMTANumber[1/2] | `00 00 00 00` | 0 |
| allocs.ClearingAccount[1/2] | `00 00 00 00` |  |
| allocs.ClearingOptionalData[1/2] | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| allocs.FrequentTraderID[1/2] | `00 00 00 00 00 00` |  |
| allocs.Side[2/2] | `32` | Sell (50, 0x32, '2') |
| allocs.AllocQty[2/2] | `00 00 00 00` | 0 |
| allocs.ClOrdID[2/2] | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| allocs.Capacity[2/2] | `41` | Agency (65, 0x41, 'A') |
| allocs.OpenClose[2/2] | `00` | NotSet (0, 0x00) |
| allocs.GiveUpFirmID[2/2] | `00 00 00 00` |  |
| allocs.Account[2/2] | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| allocs.CMTANumber[2/2] | `00 00 00 00` | 0 |
| allocs.ClearingAccount[2/2] | `00 00 00 00` |  |
| allocs.ClearingOptionalData[2/2] | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| allocs.FrequentTraderID[2/2] | `00 00 00 00 00 00` |  |

#### NewComplexInstrumentUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `5b 00` | 91 |
| MessageType | `d5 07` | NewComplexInstrumentUSOptionsV1 (2005, 0x07d5) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `b3 01 00 00` | 435 |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| ClearingFirm | `00 00 00 00` |  |
| Scratchpad | `00 00` | 0 |
| LegCnt | `02` | 2 |
| legs.Symbol[1/2] | `34 33 32 31 00 00 00 00` | 4321 |
| legs.MaturityDate[1/2] | `00 00 00 00` | 0000-00-00 |
| legs.StrikePrice[1/2] | `00 00 00 00 00 00 00 00` | 0.00 |
| legs.CFICode[1/2] | `00 00` |  |
| legs.RatioQty[1/2] | `00 00 00 00` | 0 |
| legs.Side[1/2] | `32` | Sell (50, 0x32, '2') |
| legs.Symbol[2/2] | `34 33 32 31 00 00 00 00` | 4321 |
| legs.MaturityDate[2/2] | `00 00 00 00` | 0000-00-00 |
| legs.StrikePrice[2/2] | `00 00 00 00 00 00 00 00` | 0.00 |
| legs.CFICode[2/2] | `00 00` |  |
| legs.RatioQty[2/2] | `00 00 00 00` | 0 |
| legs.Side[2/2] | `32` | Sell (50, 0x32, '2') |

#### NewComplexOrderUSOptionsV1 (Sunset TBD)

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `c1 00` | 193 |
| MessageType | `d6 07` | NewComplexOrderUSOptionsV1 (2006, 0x07d6) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `b4 01 00 00` | 436 |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| Side | `32` | Sell (50, 0x32, '2') |
| OrderQty | `dc 05 00 00` | 1500 |
| ClearingFirm | `00 00 00 00` |  |
| ClearingAccount | `00 00 00 00` |  |
| Price | `38 FF FF FF FF FF FF FF` | -0.02 |
| ExecInst | `00` | NotSet (0, 0x00) |
| OrdType | `32` | Limit (50, 0x32, '2') |
| TimeInForce | `36` | GTD (54, 0x36, '6') |
| Symbol | `34 33 32 31 00 00 00 00` | 4321 |
| Capacity | `41` | Agency (65, 0x41, 'A') |
| RoutingInst | `00 00 00 00` |  |
| Account | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| PreventMatch | `00 00 00` |  |
| ExpireTime | `28 18 14 cf 13 84 32 17` | 2022-12-20 13:40:32.321321 |
| CMTANumber | `00 00 00 00` | 0 |
| TargetPartyID | `00 00 00 00` |  |
| AttributedQuote | `00` | NotSet (0, 0x00) |
| AuctionID | `00 00 00 00 00 00 00 00` | 000000000000 |
| RoutingFirmID | `00 00 00 00` |  |
| DrillThruProtection | `00 00 00 00 00 00 00 00` | 0.00 |
| UseDrillThruOverride | `00` | NotSet (0, 0x00) |
| CustomGroupID | `12 00` | 18 |
| EquityPartyId | `00 00 00 00` |  |
| ClearingOptionalData | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| ClientIDAttr | `00 00 00 00` |  |
| FrequentTraderID | `00 00 00 00 00 00` |  |
| SessionEligibility | `00` | NotSet (0, 0x00) |
| MaxFloor | `00 00 00 00` | 0 |
| DisplayRange | `00 00 00 00` | 0 |
| ComboOrder | `00` | NotSet (0, 0x00) |
| Compression | `00` | NotSet (0, 0x00) |
| EquityExDestination | `00` | NotSet (0, 0x00) |
| EquityLegShortSell | `00` | NotSet (0, 0x00) |
| FloorDestination | `00 00 00 00` |  |
| FloorRoutingInst | `00` | NotSet (0, 0x00) |
| OrderOrigin | `00 00 00` |  |
| OrderRouterSubsidy | `00` | NotSet (0, 0x00) |
| PriceType | `00` | NotSet (0, 0x00) |
| StrategyID | `00` | NotSet (0, 0x00) |
| TiedHedge | `00` | NotSet (0, 0x00) |
| Held | `00` | NotSet (0, 0x00) |
| CrossInitiator | `00 00 00 00` |  |
| CrossOnBehalfofID | `00 00 00 00` |  |
| Scratchpad | `00 00` | 0 |
| LegCnt | `02` | 2 |
| legs.LegPositionEffect[1/2] | `00` | NotSet (0, 0x00) |
| legs.LegPositionEffect[2/2] | `00` | NotSet (0, 0x00) |

#### NewComplexOrderUSOptionsV2 (Effective TBD)

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `c1 00` | 202 |
| MessageType | `d6 07` | NewComplexOrderUSOptionsV2 (2023, 0x07E7) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `b4 01 00 00` | 436 |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| Side | `32` | Sell (50, 0x32, '2') |
| OrderQty | `dc 05 00 00` | 1500 |
| ClearingFirm | `00 00 00 00` |  |
| ClearingAccount | `00 00 00 00` |  |
| Price | `38 FF FF FF FF FF FF FF` | -0.02 |
| ExecInst | `00` | NotSet (0, 0x00) |
| OrdType | `32` | Limit (50, 0x32, '2') |
| TimeInForce | `36` | GTD (54, 0x36, '6') |
| Symbol | `34 33 32 31 00 00 00 00` | 4321 |
| Capacity | `41` | Agency (65, 0x41, 'A') |
| RoutingInst | `00 00 00 00` |  |
| Account | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| PreventMatch | `00 00 00` |  |
| ExpireTime | `28 18 14 cf 13 84 32 17` | 2022-12-20 13:40:32.321321 |
| CMTANumber | `00 00 00 00` | 0 |
| TargetPartyID | `00 00 00 00` |  |
| AttributedQuote | `00` | NotSet (0, 0x00) |
| AuctionID | `00 00 00 00 00 00 00 00` | 000000000000 |
| RoutingFirmID | `00 00 00 00` |  |
| DrillThruProtection | `00 00 00 00 00 00 00 00` | 0.00 |
| UseDrillThruOverride | `00` | NotSet (0, 0x00) |
| CustomGroupID | `12 00` | 18 |
| EquityPartyId | `00 00 00 00` |  |
| ClearingOptionalData | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| ClientIDAttr | `00 00 00 00` |  |
| FrequentTraderID | `00 00 00 00 00 00` |  |
| SessionEligibility | `00` | NotSet (0, 0x00) |
| MaxFloor | `00 00 00 00` | 0 |
| DisplayRange | `00 00 00 00` | 0 |
| ComboOrder | `00` | NotSet (0, 0x00) |
| Compression | `00` | NotSet (0, 0x00) |
| EquityExDestination | `00` | NotSet (0, 0x00) |
| EquityLegShortSell | `00` | NotSet (0, 0x00) |
| FloorDestination | `00 00 00 00` |  |
| FloorRoutingInst | `00` | NotSet (0, 0x00) |
| OrderOrigin | `00 00 00` |  |
| OrderRouterSubsidy | `00` | NotSet (0, 0x00) |
| PriceType | `00` | NotSet (0, 0x00) |
| StrategyID | `00` | NotSet (0, 0x00) |
| TiedHedge | `00` | NotSet (0, 0x00) |
| Held | `00` | NotSet (0, 0x00) |
| CrossInitiator | `00 00 00 00` |  |
| CrossOnBehalfofID | `00 00 00 00` |  |
| StopPx | `00 00 00 00 00 00 00 00` | 0.00 |
| StopPxType | `00` | NotSet (0, 0x00) |
| Scratchpad | `00 00` | 0 |
| LegCnt | `02` | 2 |
| legs.LegPositionEffect[1/2] | `00` | NotSet (0, 0x00) |
| legs.LegPositionEffect[2/2] | `00` | NotSet (0, 0x00) |

#### NewComplexOrderShortUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `85 00` | 133 |
| MessageType | `d7 07` | `NewComplexOrderShortUSOptionsV1` (2007, 0x07d7) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `b5 01 00 00` | 437 |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| Side | `32` | Sell (50, 0x32, '2') |
| OrderQty | `dc 05 00 00` | 1500 |
| ClearingFirm | `00 00 00 00` |  |
| ClearingAccount | `00 00 00 00` |  |
| Price | `58 86 03 00 00 00 00 00` | 23.10 |
| ExecInst | `00` | NotSet (0, 0x00) |
| OrdType | `32` | Limit (50, 0x32, '2') |
| TimeInForce | `36` | GTD (54, 0x36, '6') |
| Symbol | `34 33 32 31 00 00 00 00` | 4321 |
| Capacity | `41` | Agency (65, 0x41, 'A') |
| RoutingInst | `00 00 00 00` |  |
| Account | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| PreventMatch | `00 00 00` |  |
| CMTANumber | `00 00 00 00` | 0 |
| TargetPartyID | `00 00 00 00` |  |
| AuctionID | `00 00 00 00 00 00 00 00` | 000000000000 |
| RoutingFirmID | `00 00 00 00` |  |
| CustomGroupID | `12 00` | 18 |
| EquityPartyId | `00 00 00 00` |  |
| FrequentTraderID | `00 00 00 00 00 00` |  |
| SessionEligibility | `00` | NotSet (0, 0x00) |
| MaxFloor | `00 00 00 00` | 0 |
| FloorDestination | `00 00 00 00` |  |
| FloorRoutingInst | `00` | NotSet (0, 0x00) |
| Scratchpad | `00 00` | 0 |
| LegCnt | `02` | 2 |
| legs.LegPositionEffect[1/2] | `00` | NotSet (0, 0x00) |
| legs.LegPositionEffect[2/2] | `00` | NotSet (0, 0x00) |

#### NewOrderCrossMultilegUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `25 01` | 293 |
| MessageType | `d8 07` | NewOrderCrossMultilegUSOptionsV1 (2008, 0x07d8) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `b6 01 00 00` | 438 |
| CrossID | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| CrossType | `00` | NotSet (0, 0x00) |
| CrossPrioritization | `00` | NotSet (0, 0x00) |
| Price | `58 86 03 00 00 00 00 00` | 23.10 |
| OrderQty | `dc 05 00 00` | 1500 |
| Symbol | `34 33 32 31 00 00 00 00` | 4321 |
| AttributedQuote | `00` | NotSet (0, 0x00) |
| TargetPartyID | `00 00 00 00` |  |
| PreventMatch | `00 00 00` |  |
| AutoMatch | `00` | NotSet (0, 0x00) |
| AutoMatchPrice | `00 00 00 00 00 00 00 00` | 0.00 |
| LastPriority | `00` | NotSet (0, 0x00) |
| RoutingFirmID | `00 00 00 00` |  |
| ClientIDAttr | `00 00 00 00` |  |
| EquityTradePrice | `00 00 00 00 00 00 00 00` | 0.00 |
| EquityTradeSize | `00 00 00 00` | 0 |
| EquityTradeVenue | `00` | NotSet (0, 0x00) |
| EquityTransactTime | `00 00 00 00 00 00 00 00` | 1970-01-01 00:00:00.000000 |
| EquityBuyClearingFirm | `00 00 00 00` |  |
| EquitySellClearingFirm | `00 00 00 00` |  |
| DrillThruProtection | `00 00 00 00 00 00 00 00` | 0.00 |
| UseDrillThruOverride | `4e` | No (78, 0x4e, 'N') |
| EquityExDestination | `00` | NotSet (0, 0x00) |
| Compression | `00` | NotSet (0, 0x00) |
| OrderRouterSubsidy | `00` | NotSet (0, 0x00) |
| CrossInitiator | `00 00 00 00` |  |
| Scratchpad | `00 00` | 0 |
| AllocCnt | `02` | 2 |
| AllocLegCnt | `04` | 4 (2 legs * 2 allocs) |
| alloc.Side[1/2] | `32` | Sell (50, 0x32, '2') |
| alloc.AllocQty[1/2] | `00 00 00 00` | 0 |
| alloc.ClOrdID[1/2] | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| alloc.Capacity[1/2] | `41` | Agency (65, 0x41, 'A') |
| alloc.GiveUpFirmID[1/2] | `00 00 00 00` |  |
| alloc.Account[1/2] | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| alloc.CMTANumber[1/2] | `00 00 00 00` | 0 |
| alloc.ClearingAccount[1/2] | `00 00 00 00` |  |
| alloc.ClearingOptionalData[1/2] | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| alloc.EquityPartyId[1/2] | `00 00 00 00` |  |
| alloc.EquityLegShortSell[1/2] | `00` | NotSet (0, 0x00) |
| alloc.FrequentTraderID[1/2] | `00 00 00 00 00 00` |  |
| alloc.Side[2/2] | `32` | Sell (50, 0x32, '2') |
| alloc.AllocQty[2/2] | `00 00 00 00` | 0 |
| alloc.ClOrdID[2/2] | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| alloc.Capacity[2/2] | `41` | Agency (65, 0x41, 'A') |
| alloc.GiveUpFirmID[2/2] | `00 00 00 00` |  |
| alloc.Account[2/2] | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| alloc.CMTANumber[2/2] | `00 00 00 00` | 0 |
| alloc.ClearingAccount[2/2] | `00 00 00 00` |  |
| alloc.ClearingOptionalData[2/2] | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| alloc.EquityPartyId[2/2] | `00 00 00 00` |  |
| alloc.EquityLegShortSell[2/2] | `00` | NotSet (0, 0x00) |
| alloc.FrequentTraderID[2/2] | `00 00 00 00 00 00` |  |
| allocLegs.LegPositionEffect[1/4] | `00` | NotSet (0, 0x00) (alloc 1, leg 1) |
| allocLegs.LegPositionEffect[2/4] | `00` | NotSet (0, 0x00) (alloc 1, leg 2) |
| allocLegs.LegPositionEffect[3/4] | 00 | NotSet (0, 0x00) (alloc 2, leg 1) |
| allocLegs.LegPositionEffect[4/4] | 00 | NotSet (0, 0x00) (alloc 2, leg 2) |

#### CancelOrderUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `28 00` | 40 |
| MessageType | `da 07` | CancelOrderUSOptionsV1 (2010, 0x07da) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `b7 01 00 00` | 439 |
| OrigClOrdID | `5a 5a 2d 34 33 32 32 20 61 61 61 61 00 00 00 00 00 00 00 00` | ZZ-4322 aaaa |
| ClearingFirm | `00 00 00 00` |  |
| RoutingFirmID | `00 00 00 00` |  |
| Scratchpad | `00 00` | 0 |

#### ModifyOrderUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `7f 00` | 127 |
| MessageType | `db 07` | `ModifyOrderUSOptionsV1` (2011, 0x07db) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `b8 01 00 00` | 440 |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| OrigClOrdID | `5a 5a 2d 34 33 32 32 20 61 61 61 61 00 00 00 00 00 00 00 00` | ZZ-4322 aaaa |
| ClearingFirm | `00 00 00 00` |  |
| RoutingFirmID | `00 00 00 00` |  |
| OrderQty | `dc 05 00 00` | 1500 |
| Price | `58 86 03 00 00 00 00 00` | 23.10 |
| OrdType | `32` | Limit (50, 0x32, '2') |
| MaxFloor | `00 00 00 00` | 0 |
| StopPx | `00 00 00 00 00 00 00 00` | 0.00 |
| CancelOrigOnReject | `59` | Yes (89, 0x59, 'Y') |
| Reserved | `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` |  |
| Scratchpad | `00 00` | 0 |

#### QuoteUpdateUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `72 00` | 114 |
| MessageType | `dc 07` | QuoteUpdateUSOptionsV1 (2012, 0x07dc) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `b9 01 00 00` | 441 |
| QuoteUpdateID | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| ClearingFirm | `00 00 00 00` |  |
| ClearingAccount | `00 00 00 00` |  |
| CMTANumber | `00 00 00 00` | 0 |
| Account | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| CustomGroupID | `12 00` | 18 |
| SendTime | `00 00 00 00 00 00 00 00` | 1970-01-01 00:00:00.000000 |
| PostingInstruction | `50` | P |
| SessionEligibility | `00` | NotSet (0, 0x00) |
| SizeModifier | `00` | NotSet (0, 0x00) |
| Scratchpad | `00 00` | 0 |
| QuoteCnt | `02` | 2 |
| quotes.QuoteSymbol[1/2] | `00 00 00 00 00 00` |  |
| quotes.Side[1/2] | `32` | Sell (50, 0x32, '2') |
| quotes.OpenClose[1/2] | `00` | NotSet (0, 0x00) |
| quotes.Price[1/2] | `58 86 03 00 00 00 00 00` | 23.10 |
| quotes.OrderQty[1/2] | `dc 05 00 00` | 1500 |
| quotes.Scratchpad[1/2] | `00 00` | 0 |
| quotes.QuoteSymbol[2/2] | `00 00 00 00 00 00` |  |
| quotes.Side[2/2] | `32` | Sell (50, 0x32, '2') |
| quotes.OpenClose[2/2] | `00` | NotSet (0, 0x00) |
| quotes.Price[2/2] | `58 86 03 00 00 00 00 00` | 23.10 |
| quotes.OrderQty[2/2] | `dc 05 00 00` | 1500 |
| quotes.Scratchpad[2/2] | `00 00` | 0 |

#### QuoteUpdateShortUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `52 00` | 82 |
| MessageType | `dd 07` | QuoteUpdateShortUSOptionsV1 (2013, 0x07dd) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `ba 01 00 00` | 442 |
| QuoteUpdateID | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| ClearingFirm | `00 00 00 00` |  |
| ClearingAccount | `00 00 00 00` |  |
| CustomGroupID | `12 00` | 18 |
| SendTime | `00 00 00 00 00 00 00 00` | 1970-01-01 00:00:00.000000 |
| PostingInstruction | `50` | P |
| SessionEligibility | `00` | NotSet (0, 0x00) |
| SizeModifier | `00` | NotSet (0, 0x00) |
| Scratchpad | `00 00` | 0 |
| QuoteCnt | `02` | 2 |
| quotes.QuoteSymbol[1/2] | `00 00 00 00 00 00` |  |
| quotes.Side[1/2] | `32` | Sell (50, 0x32, '2') |
| quotes.OpenClose[1/2] | `00` | NotSet (0, 0x00) |
| quotes.Price[1/2] | `00 00 00 00` | 0.00 |
| quotes.OrderQty[1/2] | `00 00` | 0 |
| quotes.Scratchpad[1/2] | `00 00` | 0 |
| quotes.QuoteSymbol[2/2] | `00 00 00 00 00 00` |  |
| quotes.Side[2/2] | `32` | Sell (50, 0x32, '2') |
| quotes.OpenClose[2/2] | `00` | NotSet (0, 0x00) |
| quotes.Price[2/2] | `00 00 00 00` | 0.00 |
| quotes.OrderQty[2/2] | `00 00` | 0 |
| quotes.Scratchpad[2/2] | `00 00` | 0 |

#### ComplexQuoteUpdateUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `72 00` | 114 |
| MessageType | `e1 07` | `ComplexQuoteUpdateUSOptionsV1` (2017, 0x07e1) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `bf 01 00 00` | 447 |
| QuoteUpdateID | `51 55 49 44 30 31 32 33 00 00 00 00 00 00 00 00` | QUID0123 |
| ClearingFirm | `43 46 52 4d` | CFRM |
| ClearingAccount | `43 41 43 54` | CACT |
| CMTANumber | `22 00 00 00` | 34 |
| Account | `41 43 43 54 00 00 00 00 00 00 00 00 00 00 00 00` | ACCT |
| CustomGroupID | `12 00` | 18 |
| SendTime | `28 2e 86 bd 89 83 32 17` | 2022-12-20 13:30:39.321321000 |
| PostingInstruction | `50` | P |
| SessionEligibility | `41` | All (65, 0x41, 'A') |
| SizeModifier | `52` | Reduce (82, 0x52, 'R') |
| Scratchpad | `d2 04` | 1234 |
| QuoteCnt | `02` | 2 |
| quotes.QuoteSymbol[1/2] | `30 41 42 43 44 45` | 0ABCDE |
| quotes.Side[1/2] | `32` | Sell (50, 0x32, '2') |
| quotes.OpenClose[1/2] | `43` | Close (67, 0x43, 'C') |
| quotes.Price[1/2] | `38 38 03 00 00 00 00 00` | 21.10 |
| quotes.OrderQty[1/2] | `dc 05 00 00` | 1500 |
| quotes.Scratchpad[1/2] | `d2 04` | 1234 |
| quotes.QuoteSymbol[2/2] | `30 41 42 43 44 45` | 0ABCDE |
| quotes.Side[2/2] | `32` | Sell (50, 0x32, '2') |
| quotes.OpenClose[2/2] | `43` | Close (67, 0x43, 'C') |
| quotes.Price[2/2] | `38 38 03 00 00 00 00 00` | 21.10 |
| quotes.OrderQty[2/2] | `dc 05 00 00` | 1500 |
| quotes.Scratchpad[2/2] | `d2 04` | 1234 |

#### ComplexQuoteUpdateShortUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `52 00` | 82 |
| MessageType | `e2 07` | `ComplexQuoteUpdateShortUSOptionsV1` (2018, 0x07e2) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `c0 01 00 00` | 448 |
| QuoteUpdateID | `51 55 49 44 30 31 32 33 00 00 00 00 00 00 00 00` | QUID0123 |
| ClearingFirm | `43 46 52 4d` | CFRM |
| ClearingAccount | `43 41 43 54` | CACT |
| CustomGroupID | `12 00` | 18 |
| SendTime | `28 f8 20 f9 89 83 32 17` | 2022-12-20 13:30:40.321321000 |
| PostingInstruction | `50` | P |
| SessionEligibility | `41` | All (65, 0x41, 'A') |
| SizeModifier | `52` | Reduce (82, 0x52, 'R') |
| Scratchpad | `d2 04` | 1234 |
| QuoteCnt | `02` | 2 |
| quotes.QuoteSymbol[1/2] | `30 41 42 43 44 45` | 0ABCDE |
| quotes.Side[1/2] | `32` | Sell (50, 0x32, '2') |
| quotes.OpenClose[1/2] | `43` | Close (67, 0x43, 'C') |
| quotes.Price[1/2] | `0c 30 00 00` | 1.23 |
| quotes.OrderQty[1/2] | `02 00` | 2 |
| quotes.Scratchpad[1/2] | `d2 04` | 1234 |
| quotes.QuoteSymbol[2/2] | `30 41 42 43 44 45` | 0ABCDE |
| quotes.Side[2/2] | `32` | Sell (50, 0x32, '2') |
| quotes.OpenClose[2/2] | `43` | Close (67, 0x43, 'C') |
| quotes.Price[2/2] | `0c 30 00 00` | 1.23 |
| quotes.OrderQty[2/2] | `02 00` | 2 |
| quotes.Scratchpad[2/2] | `d2 04` | 1234 |

#### ResetRiskUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `31 00` | 49 |
| MessageType | `de 07` | `ResetRiskUSOptionsV1` (2014, 0x07de) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `bb 01 00 00` | 443 |
| RiskStatusID | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| RiskReset | `00 00 00 00 00 00 00 00` |  |
| ClearingFirm | `00 00 00 00` |  |
| RiskRoot | `00 00 00 00 00 00` |  |
| TargetMatchingUnit | `00` | 0 |
| CustomGroupID | `12 00` | 18 |
| Scratchpad | `00 00` | 0 |

#### MassCancelOrderUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `3e 00` | 62 |
| MessageType | `df 07` | `MassCancelOrderUSOptionsV1` (2015, 0x07df) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `bc 01 00 00` | 444 |
| MassCancelID | `6d 61 73 73 63 78 6c 2d 35 35 34 34 00 00 00 00 00 00 00 00` | masscxl-5544 |
| ClearingFirm | `00 00 00 00` |  |
| RoutingFirmID | `00 00 00 00` |  |
| RiskRoot | `00 00 00 00 00 00` |  |
| MassCancelInst | `00 00 00 00 00 00 00 00` |  |
| SendTime | `00 00 00 00 00 00 00 00` | 1970-01-01 00:00:00.000000 |
| Scratchpad | `00 00` | 0 |

#### PurgeOrdersUSOptionsV1 (BZX Only) (Sunset 03/23/26)

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `43 00` | 67 |
| MessageType | `e0 07` | PurgeOrdersUSOptionsV1 (2016, 0x07e0) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `bd 01 00 00` | 445 |
| MassCancelID | `6d 61 73 73 63 78 6c 2d 35 35 34 34 00 00 00 00 00 00 00 00` | masscxl-5544 |
| ClearingFirm | `00 00 00 00` |  |
| RoutingFirmID | `00 00 00 00` |  |
| RiskRoot | `00 00 00 00 00 00` |  |
| MassCancelInst | `00 00 00 00 00 00 00 00` |  |
| SendTime | `00 00 00 00 00 00 00 00` | 1970-01-01 00:00:00.000000 |
| Scratchpad | `00 00` | 0 |
| CustomGroupIDCnt | `02` | 2 |
| customGroups.CustomGroupID[1/2] | `12 00` | 18 |
| customGroups.CustomGroupID[2/2] | `1e 01` | 286 |

#### PurgeOrdersUSOptionsV2

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `44 00` | 68 |
| MessageType | `e5 07` | `PurgeOrdersUSOptionsV2` (2021, 0x07e5) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `bd 01 00 00` | 445 |
| MassCancelID | `6d 61 73 73 63 78 6c 2d 35 35 34 34 00 00 00 00 00 00 00 00` | masscxl-5544 |
| ClearingFirm | `00 00 00 00` |  |
| RoutingFirmID | `00 00 00 00` |  |
| RiskRoot | `00 00 00 00 00 00` |  |
| MassCancelInst | `00 00 00 00 00 00 00 00` |  |
| SendTime | `00 00 00 00 00 00 00 00` | 1970-01-01 00:00:00.000000 |
| TargetMatchingUnit | `00` | 0 |
| Scratchpad | `00 00` | 0 |
| CustomGroupIDCnt | `02` | 2 |
| customGroups.CustomGroupID[1/2] | `12 00` | 18 |
| customGroups.CustomGroupID[2/2] | `1e 01` | 286 |

#### FloorTradeConfirmationUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `46 00` | 70 |
| MessageType | `e4 07` | `FloorTradeConfirmationUSOptionsV1` (2020, 0x07e4) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `c2 01 00 00` | 450 |
| ClOrdID | `5a 5a 2d 34 33 32 31 61 62 63 64 00 00 00 00 00 00 00 00 00` | ZZ-4321abcd |
| ExecID | `79 57 de 3e 12 00 00 00` | 0100004MX |
| Symbol | `53 59 4d 42 4f 4c 00 00` | SYMBOL |
| PutOrCall | `30` | Put (48, 0x30, '0') |
| StrikePrice | `08 e2 01 00 00 00 00 00` | 12.34 |
| MaturityDate | `24 8d 34 01` | 2022-12-20 |
| ReportTime | `28 56 f1 ab 8a 83 32 17` | 2022-12-20 13:30:43.321321000 |
| PriceType | `00` | NotSet (0, 0x00) |
| Scratchpad | `d2 04` | 1234 |

#### AddFloorTradeUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `85 00` | 133 |
| MessageType | `e3 07` | `AddFloorTradeUSOptionsV1`(2019, 0x07e3) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `c1 01 00 00` | 449 |
| ClOrdID | `5a 5a 2d 34 33 32 31 61 62 63 64 00 00 00 00 00 00 00 00 00` | ZZ-4321abcd |
| Symbol | `53 59 4d 42 4f 4c 00 00` | SYMBOL |
| PutOrCall | `30` | Put (48, 0x30, '0') |
| StrikePrice | `08 e2 01 00 00 00 00 00` | 12.34 |
| MaturityDate | `24 8d 34 01` | 2022-12-20 |
| MultilegReportingType | `31` | Simple (49, 0x31, '1') |
| ComboOrder | `4e` | No (78, 0x4e, 'N') |
| Account | `41 43 43 54 00 00 00 00 00 00 00 00 00 00 00 00` | ACCT |
| ClearingOptionalData | `43 4f 50 54 44 41 54 41 00 00 00 00 00 00 00 00` | COPTDATA |
| ClearingAccount | `43 41 43 54` | CACT |
| CMTANumber | `22 00 00 00` | 34 |
| FloorTraderAcronym | `41 42 58` | ABX |
| Side | `32` | Sell (50, 0x32, '2') |
| OrderQty | `dc 05 00 00` | 1500 |
| Price | `38 38 03 00 00 00 00 00` | 21.10 |
| ReportTime | `28 c2 bb 34 8a 83 32 17` | 2022-12-20 13:30:41.321321000 |
| OpenClose | `43` | Close (67, 0x43, 'C') |
| FloorTradeTime | `28 8c 56 70 8a 83 32 17` | 2022-12-20 13:30:42.321321000 |
| ContraTrader | `43 54 44 52` | CTDR |
| PriceType | `00` | NotSet (0, 0x00) |
| Scratchpad | `d2 04` | 1234 |

#### DeleteFloorTradeUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `3e 00` | 62 |
| MessageType | `e6 07` | `DeleteFloorTradeUSOptionsV1` (2022, 0x07e6) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `c3 01 00 00` | 451 |
| ClOrdID | `5a 5a 2d 34 33 32 31 61 62 63 64 00 00 00 00 00 00 00 00 00` | ZZ-4321abcd |
| ExecID | `79 57 de 3e 12 00 00 00` | 0100004MX |
| Symbol | `53 59 4d 42 4f 4c 00 00` | SYMBOL |
| PutOrCall | `30` | Put (48, 0x30, '0') |
| StrikePrice | `08 e2 01 00 00 00 00 00` | 12.34 |
| MaturityDate | `24 8d 34 01` | 2022-12-20 |
| Side | `32` | Sell (50, 0x32, '2') |
| Scratchpad | `d2 04` | 1234 |

### Cboe to Member

#### OrderAcknowledgementUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `67 00` | 103 |
| MessageType | `c5 09` | OrderAcknowledgementUSOptionsV1 (2501, 0x09c5) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `f1 fb 09 00` | 654321 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 a8 4a 1c 88 83 32 17` | 2022-12-20 13:30:32.321321 |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| OrderID | `3d 07 7a 13 ee 0e 34 02` | 17FANZAA3D4T |
| Side | `32` | Sell (50, 0x32, '2') |
| Price | `58 86 03 00 00 00 00 00` | 23.10 |
| Symbol | `34 33 32 31 00 00 00 00` | 4321 |
| ClearingFirm | `00 00 00 00` |  |
| LeavesQty | `f4 01 00 00` | 500 |
| DisplayPrice | `00 00 00 00 00 00 00 00` | 0.00 |
| WorkingPrice | `00 00 00 00 00 00 00 00` | 0.00 |
| BaseLiquidityIndicator | `41` | Added (65, 0x41, 'A') |
| SubLiquidityIndicator | `00` | NotSet (0, 0x00) |
| RoutingFirmID | `00 00 00 00` |  |
| RequestReceivedTime | `00 00 00 00 00 00 00 00` | 1970-01-01 00:00:00.000000000 |

#### CrossOrderAcknowledgementUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `9b 00` | 155 |
| MessageType | `c6 09` | CrossOrderAcknowledgementUSOptionsV1 (2502, 0x09c6) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `f2 fb 09 00` | 654322 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 72 e5 57 88 83 32 17` | 2022-12-20 13:30:33.321321 |
| CrossID | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| AuctionID | `00 00 00 00 00 00 00 00` | 000000000000 |
| Price | `58 86 03 00 00 00 00 00` | 23.10 |
| Symbol | `34 33 32 31 00 00 00 00` | 4321 |
| OrderQty | `dc 05 00 00` | 1500 |
| RoutingFirmID | `00 00 00 00` |  |
| RequestReceivedTime | `00 00 00 00 00 00 00 00` | 1970-01-01 00:00:00.000000000 |
| AllocCnt | `02` | 2 |
| allocs.ClOrdID[1/2] | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| allocs.OrderID[1/2] | `3d 07 7a 13 ee 0e 34 02` | 17FANZAA3D4T |
| allocs.Side[1/2] | `32` | Sell (50, 0x32, '2') |
| allocs.AllocQty[1/2] | `00 00 00 00` | 0 |
| allocs.GiveUpFirmID[1/2] | `00 00 00 00` |  |
| allocs.ClOrdID[2/2] | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| allocs.OrderID[2/2] | `3d 07 7a 13 ee 0e 34 02` | 17FANZAA3D4T |
| allocs.Side[2/2] | `32` | Sell (50, 0x32, '2') |
| allocs.AllocQty[2/2] | `00 00 00 00` | 0 |
| allocs.GiveUpFirmID[2/2] | `00 00 00 00` |  |

#### OrderRejectedUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `6d 00` | 109 |
| MessageType | `c7 09` | `OrderRejectedUSOptionsV1` (2503, 0x09c7) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 3c 80 93 88 83 32 17` | 2022-12-20 13:30:34.321321 |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| ClearingFirm | `00 00 00 00` |  |
| RoutingFirmID | `00 00 00 00` |  |
| OrderRejectReason | `41` | A |
| Text | `45 78 61 6d 70 6c 65 20 74 65 78 74 20 66 69 65 6c 64 2e 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` | Example text field. |

#### CrossOrderRejectedUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `69 00` | 105 |
| MessageType | `c8 09` | `CrossOrderRejectedUSOptionsV1` (2504, 0x09c8) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 06 1b cf 88 83 32 17` | 2022-12-20 13:30:35.321321 |
| CrossID | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| RoutingFirmID | `00 00 00 00` |  |
| OrderRejectReason | `41` | A |
| Text | `45 78 61 6d 70 6c 65 20 74 65 78 74 20 66 69 65 6c 64 2e 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` | Example text field. |

#### NewComplexInstrumentAcceptedUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `6b 00` | 107 |
| MessageType | `c9 09` | `NewComplexInstrumentAcceptedUSOptionsV1`(2505, 0x09c9) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `f3 fb 09 00` | 654323 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 d0 b5 0a 89 83 32 17` | 2022-12-20 13:30:36.321321 |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| Symbol | `34 33 32 31 00 00 00 00` | 4321 |
| NoOfSecurities | `00 00 00 00` | 0 |
| LegCnt | `02` | 2 |
| legs.Symbol[1/2] | `34 33 32 31 00 00 00 00` | 4321 |
| legs.MaturityDate[1/2] | `00 00 00 00` | 0000-00-00 |
| legs.StrikePrice[1/2] | `00 00 00 00 00 00 00 00` | 0.00 |
| legs.CFICode[1/2] | `00 00` |  |
| legs.RatioQty[1/2] | `00 00 00 00` | 0 |
| legs.Side[1/2] | `32` | Sell (50, 0x32, '2') |
| legs.Symbol[2/2] | `34 33 32 31 00 00 00 00` | 4321 |
| legs.MaturityDate[2/2] | `00 00 00 00` | 0000-00-00 |
| legs.StrikePrice[2/2] | `00 00 00 00 00 00 00 00` | 0.00 |
| legs.CFICode[2/2] | `00 00` |  |
| legs.RatioQty[2/2] | `00 00 00 00` | 0 |
| legs.Side[2/2] | `32` | Sell (50, 0x32, '2') |

#### NewComplexInstrumentRejectedUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `69 00` | 105 |
| MessageType | `ca 09` | `NewComplexInstrumentRejectedUSOptionsV1`(2506, 0x09ca) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 9a 50 46 89 83 32 17` | 2022-12-20 13:30:37.321321 |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| NoOfSecurities | `00 00 00 00` | 0 |
| OrderRejectReason | `41` | A |
| Text | `45 78 61 6d 70 6c 65 20 74 65 78 74 20 66 69 65 6c 64 2e 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` | Example text field. |

#### OrderModifiedUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `92 00` | 146 |
| MessageType | `cb 09` | `OrderModifiedUSOptionsV1`(2507, 0x09cb) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `f4 fb 09 00` | 654324 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 64 eb 81 89 83 32 17` | 2022-12-20 13:30:38.321321 |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| OrigClOrdID | `5a 5a 2d 34 33 32 32 20 61 61 61 61 00 00 00 00 00 00 00 00` | ZZ-4322 aaaa |
| OrderID | `3d 07 7a 13 ee 0e 34 02` | 17FANZAA3D4T |
| ClearingFirm | `00 00 00 00` |  |
| RoutingFirmID | `00 00 00 00` |  |
| Symbol | `34 33 32 31 00 00 00 00` | 4321 |
| OrderQty | `dc 05 00 00` | 1500 |
| Price | `58 86 03 00 00 00 00 00` | 23.10 |
| OrdType | `32` | Limit (50, 0x32, '2') |
| MaxFloor | `00 00 00 00` | 0 |
| StopPx | `00 00 00 00 00 00 00 00` | 0.00 |
| LeavesQty | `f4 01 00 00` | 500 |
| DisplayPrice | `00 00 00 00 00 00 00 00` | 0.00 |
| WorkingPrice | `00 00 00 00 00 00 00 00` | 0.00 |
| BaseLiquidityIndicator | `41` | Added (65, 0x41, 'A') |
| SecondaryOrderID | `e6 9c 83 13 ee 0e 34 02` | 17FANZAAGTT2 |
| RequestReceivedTime | `00 00 00 00 00 00 00 00` | 1970-01-01 00:00:00.000000000 |

#### ModifyRejectedUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `81 00` | 129 |
| MessageType | `cc 09` | `ModifyRejectedUSOptionsV1`(2508, 0x09cc) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 2e 86 bd 89 83 32 17` | 2022-12-20 13:30:39.321321 |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| ClearingFirm | `00 00 00 00` |  |
| RoutingFirmID | `00 00 00 00` |  |
| OrigClOrdID | `5a 5a 2d 34 33 32 32 20 61 61 61 61 00 00 00 00 00 00 00 00` | ZZ-4322 aaaa |
| ModifyRejectReason | `41` | A |
| Text | `45 78 61 6d 70 6c 65 20 74 65 78 74 20 66 69 65 6c 64 2e 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` | Example text field. |

#### OrderRestatedUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `76 00` | 118 |
| MessageType | `cd 09` | `OrderRestatedUSOptionsV1`(2509, 0x09cd) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `f5 fb 09 00` | 654325 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 f8 20 f9 89 83 32 17` | 2022-12-20 13:30:40.321321 |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| OrderID | `3d 07 7a 13 ee 0e 34 02` | 17FANZAA3D4T |
| ClearingFirm | `00 00 00 00` |  |
| RoutingFirmID | `00 00 00 00` |  |
| Symbol | `34 33 32 31 00 00 00 00` | 4321 |
| OrderRestatementReason | `00` | UNKNOWN (0, 0x00) |
| OrderQty | `dc 05 00 00` | 1500 |
| Price | `58 86 03 00 00 00 00 00` | 23.10 |
| LeavesQty | `f4 01 00 00` | 500 |
| DisplayPrice | `00 00 00 00 00 00 00 00` | 0.00 |
| WorkingPrice | `00 00 00 00 00 00 00 00` | 0.00 |
| BaseLiquidityIndicator | `41` | Added (65, 0x41, 'A') |
| SecondaryOrderID | `e6 9c 83 13 ee 0e 34 02` | 17FANZAAGTT2 |
| LastShares | `20 03 00 00` | 800 |
| LastPx | `40 8a 03 00 00 00 00 00` | 23.20 |

#### CarriedRestatementUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `fa 00` | 250 |
| MessageType | `ce 09` | `CarriedRestatementUSOptionsV1`(2510, 0x09ce) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `f6 fb 09 00` | 654326 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 c2 bb 34 8a 83 32 17` | 2022-12-20 13:30:41.321321 |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| OrderID | `3d 07 7a 13 ee 0e 34 02` | 17FANZAA3D4T |
| Side | `32` | Sell (50, 0x32, '2') |
| Price | `58 86 03 00 00 00 00 00` | 23.10 |
| ExecInst | `00` | NotSet (0, 0x00) |
| OrdType | `32` | Limit (50, 0x32, '2') |
| TimeInForce | `36` | GTD (54, 0x36, '6') |
| MinQty | `00 00 00 00` | 0 |
| Symbol | `34 33 32 31 00 00 00 00` | 4321 |
| Capacity | `41` | Agency (65, 0x41, 'A') |
| Account | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| ClearingFirm | `00 00 00 00` |  |
| ClearingAccount | `00 00 00 00` |  |
| DisplayIndicator | `00` | NotSet (0, 0x00) |
| MaxFloor | `00 00 00 00` | 0 |
| OrderQty | `dc 05 00 00` | 1500 |
| PreventMatch | `00 00 00` |  |
| MaturityDate | `00 00 00 00` | 0000-00-00 |
| StrikePrice | `00 00 00 00 00 00 00 00` | 0.00 |
| PutOrCall | `00` | NotSet (0, 0x00) |
| OpenClose | `00` | NotSet (0, 0x00) |
| LeavesQty | `f4 01 00 00` | 500 |
| DisplayPrice | `00 00 00 00 00 00 00 00` | 0.00 |
| WorkingPrice | `00 00 00 00 00 00 00 00` | 0.00 |
| ExpireTime | `28 fc 1f 23 16 84 32 17` | 2022-12-20 13:40:42.321321 |
| AttributedQuote | `00` | NotSet (0, 0x00) |
| StopPx | `00 00 00 00 00 00 00 00` | 0.00 |
| RoutingInst | `00 00 00 00` |  |
| RoutStrategy | `00 00 00 00 00 00` |  |
| RouteDeliveryMethod | `00 00 00` |  |
| ExDestination | `00` |  |
| TargetPartyID | `00 00 00 00` |  |
| AuctionID | `00 00 00 00 00 00 00 00` | 000000000000 |
| CMTANumber | `00 00 00 00` | 0 |
| RoutingFirmID | `00 00 00 00` |  |
| ClearingOptionalData | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| CumQty | `00 00 00 00` | 0 |
| DrillThruProtection | `00 00 00 00 00 00 00 00` | 0.00 |
| EquityPartyId | `00 00 00 00` |  |
| ClientIDAttr | `00 00 00 00` |  |
| FrequentTraderID | `00 00 00 00 00 00` |  |
| SessionEligibility | `00` | NotSet (0, 0x00) |
| ComboOrder | `00` | NotSet (0, 0x00) |
| Compression | `00` | NotSet (0, 0x00) |
| FloorDestination | `00 00 00 00` |  |
| FloorRoutingInst | `00` | NotSet (0, 0x00) |
| OrderOrigin | `00 00 00` |  |
| PriceType | `00` | NotSet (0, 0x00) |
| StrategyID | `00` | NotSet (0, 0x00) |
| Held | `00` | NotSet (0, 0x00) |

#### DoneForDayUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `38 00` | 56 |
| MessageType | `cf 09` | `DoneForDayUSOptionsV1`(2511, 0x09cf) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `f7 fb 09 00` | 654327 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 8c 56 70 8a 83 32 17` | 2022-12-20 13:30:42.321321 |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| ClearingFirm | `00 00 00 00` |  |
| RoutingFirmID | `00 00 00 00` |  |
| Symbol | `34 33 32 31 00 00 00 00` | 4321 |

#### OrderCancelledUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `42 00` | 66 |
| MessageType | `d0 09` | `OrderCancelledUSOptionsV1`(2512, 0x09d0) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `f8 fb 09 00` | 654328 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 56 f1 ab 8a 83 32 17` | 2022-12-20 13:30:43.321321 |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| CancelReason | `41` | A |
| CancelSubReason | `00` |  |
| ClearingFirm | `00 00 00 00` |  |
| RoutingFirmID | `00 00 00 00` |  |
| Symbol | `34 33 32 31 00 00 00 00` | 4321 |
| RequestReceivedTime | `00 00 00 00 00 00 00 00` | 1970-01-01 00:00:00.000000000 |

#### CrossOrderCancelledUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `5e 00` | 94 |
| MessageType | `d1 09` | `CrossOrderCancelledUSOptionsV1`(2513, 0x09d1) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `f9 fb 09 00` | 654329 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 20 8c e7 8a 83 32 17` | 2022-12-20 13:30:44.321321 |
| CrossID | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| RoutingFirmID | `00 00 00 00` |  |
| CancelReason | `41` | A |
| AllocCnt | `02` | 2 |
| allocs.ClOrdID[1/2] | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| allocs.GiveUpFirmID[1/2] | `00 00 00 00` |  |
| allocs.ClOrdID[2/2] | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| allocs.GiveUpFirmID[2/2] | `00 00 00 00` |  |

#### CancelRejectedUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `6d 00` | 109 |
| MessageType | `d2 09` | `CancelRejectedUSOptionsV1`(2514, 0x09d2) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 ea 26 23 8b 83 32 17` | 2022-12-20 13:30:45.321321 |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| ClearingFirm | `00 00 00 00` |  |
| RoutingFirmID | `00 00 00 00` |  |
| CancelRejectReason | `41` | A |
| Text | `45 78 61 6d 70 6c 65 20 74 65 78 74 20 66 69 65 6c 64 2e 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` | Example text field. |

#### OrderExecutionUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `7e 00` | 126 |
| MessageType | `d3 09` | `OrderExecutionUSOptionsV1`(2515, 0x09d3) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `fa fb 09 00` | 654330 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 b4 c1 5e 8b 83 32 17` | 2022-12-20 13:30:46.321321 |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| ExecID | `79 57 de 3e 12 00 00 00` | 0100004MX |
| LastShares | `20 03 00 00` | 800 |
| LastPx | `40 8a 03 00 00 00 00 00` | 23.20 |
| LeavesQty | `f4 01 00 00` | 500 |
| BaseLiquidityIndicator | `41` | Added (65, 0x41, 'A') |
| SubLiquidityIndicator | `00` | NotSet (0, 0x00) |
| ContraBroker | `00 00 00 00` |  |
| Side | `32` | Sell (50, 0x32, '2') |
| Symbol | `34 33 32 31 00 00 00 00` | 4321 |
| ContraTrader | `00 00 00 00` |  |
| ClearingFirm | `00 00 00 00` |  |
| ContraCapacity | `00` | NotSet (0, 0x00) |
| FeeCode | `00 00` |  |
| MarketingFeeCode | `00 00` |  |
| RoutingFirmID | `00 00 00 00` |  |
| CrossExclusionIndicator | `00` | NotSet (0, 0x00) |
| TradeDate | `00 00 00 00` | 0000-00-00 |
| MultilegReportingType | `00` | UNKNOWN (0, 0x00) |
| SecondaryExecID | `00 00 00 00 00 00 00 00` | 000000000 |
| PriceType | `00` | NotSet (0, 0x00) |
| TradethroughAlertType | `00` | NotSet (0, 0x00) |
| SenderLocationId | `00` | NotSet (0, 0x00) |
| FloorTraderAcronym | `00 00 00` |  |
| FloorTradeTime | `00 00 00 00 00 00 00 00` | 1970-01-01 00:00:00.000000 |
| ExDestination | `00` |  |
| EquityExDestination | `00` | NotSet (0, 0x00) |

#### ComplexQuoteExecutionUSOptionsv1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `85 00` | 133 |
| MessageType | `e3 07` | `AddFloorTradeUSOptionsV1`(2019, 0x07e3) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `c1 01 00 00` | 449 |
| ClOrdID | `5a 5a 2d 34 33 32 31 61 62 63 64 00 00 00 00 00 00 00 00 00` | ZZ-4321abcd |
| Symbol | `53 59 4d 42 4f 4c 00 00` | SYMBOL |
| PutOrCall | `30` | Put (48, 0x30, '0') |
| StrikePrice | `08 e2 01 00 00 00 00 00` | 12.34 |
| MaturityDate | `24 8d 34 01` | 2022-12-20 |
| MultilegReportingType | `31` | Simple (49, 0x31, '1') |
| ComboOrder | `4e` | No (78, 0x4e, 'N') |
| Account | `41 43 43 54 00 00 00 00 00 00 00 00 00 00 00 00` | ACCT |
| ClearingOptionalData | `43 4f 50 54 44 41 54 41 00 00 00 00 00 00 00 00` | COPTDATA |
| ClearingAccount | `43 41 43 54` | CACT |
| CMTANumber | `22 00 00 00` | 34 |
| FloorTraderAcronym | `41 42 58` | ABX |
| Side | `32` | Sell (50, 0x32, '2') |
| OrderQty | `dc 05 00 00` | 1500 |
| Price | `38 38 03 00 00 00 00 00` | 21.10 |
| ReportTime | `28 c2 bb 34 8a 83 32 17` | 2022-12-20 13:30:41.321321000 |
| OpenClose | `43` | Close (67, 0x43, 'C') |
| FloorTradeTime | `28 8c 56 70 8a 83 32 17` | 2022-12-20 13:30:42.321321000 |
| ContraTrader | `43 54 44 52` | CTDR |
| PriceType | `00` | NotSet (0, 0x00) |
| Scratchpad | `d2 04` | 1234 |

#### TradeCancelCorrectUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `84 00` | 132 |
| MessageType | `d4 09` | `TradeCancelCorrectUSOptionsV1`(2516, 0x09d4) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `fb fb 09 00` | 654331 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 7e 5c 9a 8b 83 32 17` | 2022-12-20 13:30:47.321321 |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| OrderID | `3d 07 7a 13 ee 0e 34 02` | 17FANZAA3D4T |
| ExecRefID | `79 57 de 3e 12 00 00 00` | 0100004MX |
| Side | `32` | Sell (50, 0x32, '2') |
| BaseLiquidityIndicator | `41` | Added (65, 0x41, 'A') |
| SubLiquidityIndicator | `00` | NotSet (0, 0x00) |
| ClearingFirm | `00 00 00 00` |  |
| ClearingAccount | `00 00 00 00` |  |
| LastShares | `20 03 00 00` | 800 |
| LastPx | `40 8a 03 00 00 00 00 00` | 23.20 |
| CorrectedPrice | `00 00 00 00 00 00 00 00` | 0.00 |
| CorrectedSize | `00 00 00 00` | 0 |
| OrigTime | `00 00 00 00 00 00 00 00` | 1970-01-01 00:00:00.000000 |
| Symbol | `34 33 32 31 00 00 00 00` | 4321 |
| MaturityDate | `00 00 00 00` | 0000-00-00 |
| StrikePrice | `00 00 00 00 00 00 00 00` | 0.00 |
| PutOrCall | `00` | NotSet (0, 0x00) |
| Capacity | `41` | Agency (65, 0x41, 'A') |
| OpenClose | `00` | NotSet (0, 0x00) |
| MarketingFeeCode | `00 00` |  |
| TargetPartyID | `00 00 00 00` |  |
| CMTANumber | `00 00 00 00` | 0 |

#### QuoteUpdateAcknowledgementUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `43 00` | 67 |
| MessageType | `d5 09` | `QuoteUpdateAcknowledgementUSOptionsV1`(2517, 0x09d5) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 48 f7 d5 8b 83 32 17` | 2022-12-20 13:30:48.321321 |
| QuoteUpdateID | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| RequestReceivedTime | `00 00 00 00 00 00 00 00` | 1970-01-01 00:00:00.000000000 |
| QuoteCnt | `02` | 2 |
| quotes.OrderID[1/2] | `3d 07 7a 13 ee 0e 34 02` | 17FANZAA3D4T |
| quotes.QuoteResult[1/2] | `00` |  |
| quotes.SubLiquidityIndicator[1/2] | `00` | NotSet (0, 0x00) |
| quotes.QuoteRejectSubReason[1/2] | `00` |  |
| quotes.OrderID[2/2] | `3d 07 7a 13 ee 0e 34 02` | 17FANZAA3D4T |
| quotes.QuoteResult[2/2] | `00` |  |
| quotes.SubLiquidityIndicator[2/2] | `00` | NotSet (0, 0x00) |
| quotes.QuoteRejectSubReason[2/2] | `00` |  |

#### QuoteUpdateRejectedUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `25 00` | 37 |
| MessageType | `d6 09` | `QuoteUpdateRejectedUSOptionsV1`(2518, 0x09d6) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 12 92 11 8c 83 32 17` | 2022-12-20 13:30:49.321321 |
| QuoteUpdateID | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| QuoteRejectReason | `00` | UNKNOWN (0, 0x00) |

#### QuoteCancelledUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `35 00` | 53 |
| MessageType | `d7 09` | `QuoteCancelledUSOptionsV1`(2519, 0x09d7) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 dc 2c 4d 8c 83 32 17` | 2022-12-20 13:30:50.321321 |
| QuoteUpdateID | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| OrderID | `3d 07 7a 13 ee 0e 34 02` | 17FANZAA3D4T |
| QuoteSymbol | `00 00 00 00 00 00` |  |
| Side | `32` | Sell (50, 0x32, '2') |
| CancelReason | `41` | A |
| CancelSubReason | `00` |  |

#### QuoteExecutionUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `5e 00` | 94 |
| MessageType | `d8 09` | `QuoteExecutionUSOptionsV1`(2520, 0x09d8) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `fc fb 09 00` | 654332 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 a6 c7 88 8c 83 32 17` | 2022-12-20 13:30:51.321321 |
| QuoteUpdateID | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| OrderID | `3d 07 7a 13 ee 0e 34 02` | 17FANZAA3D4T |
| ExecID | `79 57 de 3e 12 00 00 00` | 0100004MX |
| QuoteSymbol | `00 00 00 00 00 00` |  |
| ClearingFirm | `00 00 00 00` |  |
| LastShares | `20 03 00 00` | 800 |
| LastPx | `40 8a 03 00 00 00 00 00` | 23.20 |
| LeavesQty | `f4 01 00 00` | 500 |
| ContraTrader | `00 00 00 00` |  |
| ContraCapacity | `00` | NotSet (0, 0x00) |
| Side | `32` | Sell (50, 0x32, '2') |
| BaseLiquidityIndicator | `41` | Added (65, 0x41, 'A') |
| SubLiquidityIndicator | `00` | NotSet (0, 0x00) |
| FeeCode | `00 00` |  |
| MarketingFeeCode | `00 00` |  |
| TradeDate | `00 00 00 00` | 0000-00-00 |

#### QuoteRestatedUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `40 00` | 64 |
| MessageType | `d9 09` | `QuoteRestatedUSOptionsV1`(2521, 0x09d9) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `fd fb 09 00` | 654333 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 70 62 c4 8c 83 32 17` | 2022-12-20 13:30:52.321321 |
| QuoteUpdateID | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| OrderID | `3d 07 7a 13 ee 0e 34 02` | 17FANZAA3D4T |
| LeavesQty | `f4 01 00 00` | 500 |
| WorkingPrice | `00 00 00 00 00 00 00 00` | 0.00 |
| QuoteSymbol | `00 00 00 00 00 00` |  |
| Side | `32` | Sell (50, 0x32, '2') |
| RestatementReason | `57` | Wash (87, 0x57, 'W') |

#### ResetRiskAcknowledgementUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `25 00` | 37 |
| MessageType | `da 09` | `ResetRiskAcknowledgementUSOptionsV1`(2522, 0x09da) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `00 00` | 0 |
| RiskStatusID | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| RiskResetResult | `00` |  |
| RequestReceivedTime | `00 00 00 00 00 00 00 00` | 1970-01-01 00:00:00.000000000 |

#### MassCancelAcknowledgementUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `34 00` | 52 |
| MessageType | `db 09` | `MassCancelAcknowledgementUSOptionsV1`(2523, 0x09db) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 3a fd ff 8c 83 32 17` | 2022-12-20 13:30:53.321321 |
| MassCancelID | `6d 61 73 73 63 78 6c 2d 35 35 34 34 00 00 00 00 00 00 00 00` | masscxl-5544 |
| CancelledOrderCount | `00 00 00 00` | 0 |
| RequestReceivedTime | `00 00 00 00 00 00 00 00` | 1970-01-01 00:00:00.000000000 |

#### MassCancelRejectedUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `65 00` | 101 |
| MessageType | `dc 09` | `MassCancelRejectedUSOptionsV1`(2524, 0x09dc) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 04 98 3b 8d 83 32 17` | 2022-12-20 13:30:54.321321 |
| MassCancelID | `6d 61 73 73 63 78 6c 2d 35 35 34 34 00 00 00 00 00 00 00 00` | masscxl-5544 |
| MassCancelRejectReason | `00` |  |
| Text | `45 78 61 6d 70 6c 65 20 74 65 78 74 20 66 69 65 6c 64 2e 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` | Example text field. |

#### PurgeAcknowledgementUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `35 00` | 53 |
| MessageType | `dd 09` | `PurgeAcknowledgementUSOptionsV1`(2525, 0x09dd) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 ce 32 77 8d 83 32 17` | 2022-12-20 13:30:55.321321 |
| MassCancelID | `6d 61 73 73 63 78 6c 2d 35 35 34 34 00 00 00 00 00 00 00 00` | masscxl-5544 |
| CancelledOrderCount | `00 00 00 00` | 0 |
| SourceMatchingUnit | `00` | 0 |
| RequestReceivedTime | `00 00 00 00 00 00 00 00` | 1970-01-01 00:00:00.000000000 |

#### PurgeRejectedUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `65 00` | 101 |
| MessageType | `de 09` | `PurgeRejectedUSOptionsV1`(2526, 0x09de) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 98 cd b2 8d 83 32 17` | 2022-12-20 13:30:56.321321 |
| MassCancelID | `6d 61 73 73 63 78 6c 2d 35 35 34 34 00 00 00 00 00 00 00 00` | masscxl-5544 |
| PurgeRejectReason | `41` | A |
| Text | `45 78 61 6d 70 6c 65 20 74 65 78 74 20 66 69 65 6c 64 2e 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` | Example text field. |

#### PurgeNotificationUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `38 00` | 56 |
| MessageType | `df 09` | `PurgeNotificationUSOptionsV1`(2527, 0x09df) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 62 68 ee 8d 83 32 17` | 2022-12-20 13:30:57.321321 |
| MassCancelID | `6d 61 73 73 63 78 6c 2d 35 35 34 34 00 00 00 00 00 00 00 00` | masscxl-5544 |
| CancelledOrderCount | `00 00 00 00` | 0 |
| SourceMatchingUnit | `00` | 0 |
| ClearingFirm | `00 00 00 00` |  |
| RiskRoot | `00 00 00 00 00 00` |  |
| MassCancelLockout | `00` | UNKNOWN (0, 0x00) |

#### AddFloorTradeRejectedUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `65 00` | 101 |
| MessageType | `e3 09` | `AddFloorTradeRejectedUSOptionsV1` (2531, 0x09e3) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `01 00` | 1 |
| TransactionTime | `28 e6 20 fc 93 83 32 17` | 2022-12-20 13:31:23.321321000 |
| ClOrdID | `5a 5a 2d 34 33 32 31 61 62 63 64 00 00 00 00 00 00 00 00 00` | ZZ-4321abcd |
| OrderRejectReason | `41` | A |
| Text | `45 78 61 6d 70 6c 65 20 74 65 78 74 20 66 69 65 6c 64 2e 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` | Example text field. |

#### FloorTradeConfirmationRejectedUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `6d 00` | 109 |
| MessageType | `e4 09` | `FloorTradeConfirmationRejectedUSOptionsV1`(2532, 0x09e4) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `01 00` | 1 |
| TransactionTime | `28 b0 bb 37 94 83 32 17` | 2022-12-20 13:31:24.321321000 |
| ClOrdID | `5a 5a 2d 34 33 32 31 61 62 63 64 00 00 00 00 00 00 00 00 00` | ZZ-4321abcd |
| ExecID | `79 57 de 3e 12 00 00 00` | 0100004MX |
| OrderRejectReason | `41` | A |
| Text | `45 78 61 6d 70 6c 65 20 74 65 78 74 20 66 69 65 6c 64 2e 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` | Example text field. |

#### FloorOrderRepresentedUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `3c 00` | 60 |
| MessageType | `e7 09` | `FloorOrderRepresentedUSOptionsV1`(2535, 0x09e7) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `ff fb 09 00` | 654335 |
| InFlight | `01 00` | 1 |
| TransactionTime | `28 0e 8c ea 94 83 32 17` | 2022-12-20 13:31:27.321321000 |
| ClOrdID | `5a 5a 2d 34 33 32 31 61 62 63 64 00 00 00 00 00 00 00 00 00` | ZZ-4321abcd |
| OrderID | `3d 07 7a 13 ee 0e 34 02` | 17FANZAA3D4T |
| ClearingFirm | `43 46 52 4d` | CFRM |
| RoutingFirmID | `52 46 49 44` | RFID |
| FloorTraderAcronym | `41 42 58` | ABX |
| OrderRestatementReason | `57` | Wash (87, 0x57, 'W') |

#### DeleteFloorTradeRejectedUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `6d 00` | 109 |
| MessageType | `e5 09` | `DeleteFloorTradeRejectedUSOptionsV1`(2533, 0x09e5) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `01 00` | 1 |
| TransactionTime | `28 44 f1 ae 94 83 32 17` | 2022-12-20 13:31:26.321321000 |
| ClOrdID | `5a 5a 2d 34 33 32 31 61 62 63 64 00 00 00 00 00 00 00 00 00` | ZZ-4321abcd |
| ExecID | `79 57 de 3e 12 00 00 00` | 0100004MX |
| OrderRejectReason | `41` | A |
| Text | `45 78 61 6d 70 6c 65 20 74 65 78 74 20 66 69 65 6c 64 2e 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` | Example text field. |

#### DeleteFloorTradeAcknowledgementUSOptionsV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `30 00` | 48 |
| MessageType | `e6 09` | `DeleteFloorTradeAcknowledgementUSOptionsV1` (2534, 0x09e6) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `01 00` | 1 |
| TransactionTime | `28 7a 56 73 94 83 32 17` | 2022-12-20 13:31:25.321321000 |
| ClOrdID | `5a 5a 2d 34 33 32 31 61 62 63 64 00 00 00 00 00 00 00 00 00` | ZZ-4321abcd |
| ExecID | `79 57 de 3e 12 00 00 00` | 0100004MX |

## Appendix B - Architectural Diagrams

Simple architectural diagrams of the BOEv3 port deployments.

_(Figure: Figure 1. BOEv3u Port Deployment Diagram (BZX Only))_

Note that members using BOEv3u ports interact directly with the BOEv3u process, however a separate TCP connection is required for each unit.

BOEv3u Ports provide an expedited processing path to the Matching Engine over that of other inbound paths on a best effort basis. Under routine circumstances, the System will process pending purge messages from BOEv3u ports before processing other inbound paths. Exceptions to this approach exist with regard to various flow control and rate limiters that are incorporated into the mechanism.

Example of the Processing under routine circumstances:

1. Process pending purge messages from BOEv3u ports within a bounded network window
2. Process all other pending messages from BOEv3u ports, not to exceed bounded network window from step 1
3. Process pending messages from Convenience ports, not to exceed bounded network window from step 1

_(Figure: Figure 2. BOEv3c Port Deployment Diagram (C1, C2, and EDGX Only))_

C1, C2, and EDGX Options Exchanges are set up with all port types residing in a "convenience" style architecture. All ports have access to all Matching Units. All customer messaging is processed at the Matching Engine in the order that it arrives at each Matching Engine NIC.

## Appendix C - Login Playbook

Please note that for brevity these examples assume an exchange having 4 matching units. The actual number per options exchange will vary, typically in the range of 31-35 units.

### Login Message Flow

On a successful login, the following is the sequence of messages to expect. Note that after sending a Login Request, members should wait for both a `Login Response` message of Accepted as well as a `Replay Complete` message before sending new application messages.

| Direction | Message |
|---|---|
| Member → Cboe | Login Request |
| Member ← Cboe | Login Response ( `A` = Accepted) |
| Member ← Cboe | For each matching unit, all messages for the member having sequence number greater than the seq # in the login request for that unit. Possibly no such messages are transmitted, for instance on the first login of the day. |
| Member ← Cboe | Replay Complete |
| Member ←→ Cboe | (Begin normal flow: Order traffic, or Heartbeats at 1/sec) |

### Recommended Login - Convenience Port

Request a replay of everything that you missed.

The login protocol supports a variety of options for how a member may want to approach reconciling sequence numbers and messages after a disconnection. For most members, the following Login strategy is the simplest approach to support a robust, lossless login experience. Note that unlike unitized ports, a convenience port is capable of replaying all of the messages for the business day on that port.

| Field Name | Value | Comment |
|---|---|---|
| StartOfMessage | BO E3 |  |
| MessageLength | 2F 00 | 47 |
| MessageType | 01 00 | 1 (login request) |
| MatchingUnit | 00 |  |
| Reserved | 00 |  |
| SequenceNumber | 00 | (unsequenced) |
| SessionId | 41 42 43 44 | (ex. "ABCD") - Session Id as supplied by Cboe |
| SessionSubId | 30 30 30 31 | (ex. "0001") Session Sub Id as supplied by Cboe |
| Password | 61 62 63 64 65 66 67 68 69 6A | (ex. "abcdefghij") Password |
| ReplayInstruction | 52 | "R" - Replay unknown units. |
| NumberOfUnits | 04 | There are 4 rows in the array below, representing the 4 system matching units (a Cboe US Options deployment will have > 30). |
| →UnitNumber | 01 | Matching unit #1 |
| →UnitSequence | 00 00 00 00 | Last SequenceNumber that member received with MatchingUnit=1. Zero if member has not received anything for MatchingUnit=1, for instance as the first login of the day. |
| →UnitNumber | 02 | Matching unit #2 |
| →UnitSequence | 00 00 00 00 | Last SequenceNumber that member received with MatchingUnit=2. Zero if member has not received anything for MatchingUnit=2, for instance as the first login of the day. |
| →UnitNumber | 03 | Matching unit #3 |
| →UnitSequence | 00 00 00 00 | Last SequenceNumber that member received with MatchingUnit=3. Zero if member has not received anything for MatchingUnit=3, for instance as the first login of the day. |
| →UnitNumber | 04 | Matching unit #4 |
| →UnitSequence | 00 00 00 00 | Last SequenceNumber that member received with MatchingUnit=4. Zero if member has not received anything for MatchingUnit=4, for instance as the first login of the day. |

### Recommended Login - Unitized Port (BZX Only)

Request a replay of everything that you missed.

The login protocol supports a variety of options for how a member may want to approach reconciling sequence numbers and messages after a disconnection. For most members, the following Login strategy is the simplest approach to support a robust, lossless login experience.

Unlike convenience ports, a unitized port is capable of replaying a limited window of messages for the port. If the number of messages needed exceeds the available window, the login will be rejected with LoginResponseStatus = R (replay too deep). In such cases, members may either elect skip undelivered messages (see No Replay) or use a deep replay strategy (see Deep Replay - Unitized (BZX Only)).

| Field Name | Value | Comment |
|---|---|---|
| StartOfMessage | BO E3 |  |
| MessageLength | 20 00 | 32 |
| MessageType | 01 00 | 1 (login request) |
| MatchingUnit | 00 |  |
| Reserved | 00 |  |
| SequenceNumber | 00 | (unsequenced) |
| SessionId | 41 42 43 44 | (ex. "ABCD") - Session Id as supplied by Cboe |
| SessionSubId | 30 30 30 31 | (ex. "0001") Session Sub Id as supplied by Cboe |
| Password | 61 62 63 64 65 66 67 68 69 6A | (ex. "abcdefghij") Password |
| ReplayInstruction | 52 | R - Replay unknown units. |
| NumberOfUnits | 01 | The single unit for the unitized port is specified |
| →UnitNumber | 03 | Matching unit #3 |
| →UnitSequence | 00 00 00 00 | Last SequenceNumber that member received with MatchingUnit=3. Zero if member has not received anything for MatchingUnit=3, for instance as the first login of the day. |

### Deep Replay - Unitized (BZX Only)

If the sequence gap on login is greater than 1,000 messages, the login request will be rejected by Cboe with a reason of `R` (replay too deep). To recover the messages from the exchange, firms may login to an inactive (typically secondary or DR) BOE3 port and request a "deep replay" to recover the missing messages. See Failover and Disaster Recovery (DR) for additional details.

For a fully lossless experience, the login sequence would include a recovery path to secondary/DR port on a login failure due to "replay too deep":

| Direction | Message |
|---|---|
| Member → Cboe (primary A) | Login Request (to primary connection A) |
| Member ← Cboe (primary A) | Login Response is rejected (R = `replay too Deep`) |
| Member → Cboe (DR C) | Login Request (ReplayInstruction=D "deep replay") |
| Member ← Cboe (DR C) | Login Response (A=accepted) |
| Member ← Cboe (DR C) | (Replay of messages) |
| Member ← Cboe (DR C) | Replay Complete |
| Member ← Cboe (DR C) | Logout Response (LogoutReason=A (Admin)); an unsolicited logout |
| Member → Cboe (primary A) | Login Request (to primary connection A), using the updated sequence #. |
| Member ← Cboe (primary A) | Login Response is accepted ( `A`=Accepted) |
| Member ← Cboe (primary A) | For each matching unit, all messages for the member having sequence number greater than the seq # in the login request for that unit. Possibly no such messages are transmitted. |
| Member ← Cboe (primary A) | Replay Complete |
| Member ←→ Cboe (primary A) | (Begin normal flow: Order traffic, or Heartbeats at 1/sec) |

**Table 1. Deep Replay Login Request**

| Field Name | Value | Comment |
|---|---|---|
| StartOfMessage | BO E3 |  |
| MessageLength | 20 00 | 32 |
| MessageType | 01 00 | 1 (login request) |
| MatchingUnit | 00 |  |
| Reserved | 00 |  |
| SequenceNumber | 00 | (unsequenced) |
| SessionId | 41 42 43 44 | (ex. "ABCD") - Session Id as supplied by Cboe |
| SessionSubId | 30 30 30 31 | (ex. "0001") Session Sub Id as supplied by Cboe |
| Password | 61 62 63 64 65 66 67 68 69 6A | (ex. "abcdefghij") Password |
| ReplayInstruction | 52 | "D" - Deep replay request. |
| NumberOfUnits | 01 | The single unit for the unitized port is specified |
| →UnitNumber | 02 | Matching unit #2 |
| →UnitSequence | 52 0D 67 00 | Last SequenceNumber that member received with MatchUnit=2. Zero if member has not received anything for MatchUnit=2, for instance as the first login of the day. |

### Other Login Strategies

#### No Replay

"Just start with the next live event"

If the member is confident that they are disinterested in any missed messages, they may elect to Skip (S) unspecified units and specify no units. This can be used as an initial login. Differences from the recommended login are in Bold.

| Field Name | Value | Comment |
|---|---|---|
| StartOfMessage | BO E3 |  |
| MessageLength | 1B 00 | 27 |
| MessageType | 01 00 | 1 (login request) |
| MatchingUnit | 00 |  |
| Reserved | 00 |  |
| SequenceNumber | 00 | (unsequenced) |
| SessionId | 41 42 43 44 | (ex. "ABCD") - Session Id as supplied by Cboe |
| SessionSubId | 30 30 30 31 | (ex. "0001") Session Sub Id as supplied by Cboe |
| Password | 61 62 63 64 65 66 67 68 69 6A | (ex. "abcdefghij") Password |
| ReplayInstruction | 53 | "S" - Skip replay of unspecified units. |
| NumberOfUnits | 00 | There are no rows in the array below. |

#### Fail Login if any units are unspecified

A minor variation on the Recommended Login - Convenience Port, this strategy will fail the login if not all known units are specified. This would provide some protection against a misconfiguration, or the unexpected introduction of additional matching units at Cboe (although Cboe would provide extensive notice and planning before introducing additional units). Differences from the recommended login are in Bold.

| Field Name | Value | Comment |
|---|---|---|
| StartOfMessage | BO E3 |  |
| MessageLength | 2F 00 | 47 |
| MessageType | 01 00 | 1 (login request) |
| MatchingUnit | 00 |  |
| Reserved | 00 |  |
| SequenceNumber | 00 | (unsequenced) |
| SessionId | 41 42 43 44 | (ex. "ABCD") - Session Id as supplied by Cboe |
| SessionSubId | 30 30 30 31 | (ex. "0001") Session Sub Id as supplied by Cboe |
| Password | 61 62 63 64 65 66 67 68 69 6A | (ex. "abcdefghij") Password |
| ReplayInstruction | 46 | "F" - Fail unknown units. |
| NumberOfUnits | 04 | There are 4 rows in the array below, representing the 4 system matching units. |
| →UnitNumber | 01 | Matching unit #1 |
| →UnitSequence | 00 00 00 00 | Last SequenceNumber that member received with MatchUnit=1. Zero if member has not received anything for MatchUnit=1, for instance as the first login of the day. |
| →UnitNumber | 02 | Matching unit #2 |
| →UnitSequence | 00 00 00 00 | Last SequenceNumber that member received with MatchUnit=2. Zero if member has not received anything for MatchUnit=2, for instance as the first login of the day. |
| →UnitNumber | 03 | Matching unit #3 |
| →UnitSequence | 00 00 00 00 | Last SequenceNumber that member received with MatchUnit=3. Zero if member has not received anything for MatchUnit=3, for instance as the first login of the day. |
| →UnitNumber | 04 | Matching unit #4 |
| →UnitSequence | 00 00 00 00 | Last SequenceNumber that member received with MatchUnit=3. Zero if member has not received anything for MatchUnit=4, for instance as the first login of the day. |

## Revision History

| Version | Date | Description |
|---|---|---|
| 1.0.0 | 02/09/24 | Initial version for publication. |
| 1.0.1 | 04/03/24 | Added ShortBinaryPrice type to "1.4 Data Types". Added ScratchPad field to ModifyOrder and CancelOrder. Added Symbol field to OrderModified, OrderCancelled, OrderRestated, DoneForDay. Added InFlight field to MassCancelRejected. Updated description of LegCnt in New Complex Order regarding the treatment of an empty leg position effect array. Added Reserved field to ModifyOrder and to "5. List Of Message Fields". Corrected field label from OpenClose to OrderID at offset 42 in New Order Acknowledgment. Added TradeDate to QuoteExecution. Updated size of MassCancelInst from 16 to 8 bytes. Updated OrderQty and Price to smaller lengths (2 and 4, respectively) in QuoteUpdateShort. Updated examples for affected messages. Clarified the CrossInitiator (C1 and EDGX only) description to indicate that the MPID field is required on cross orders routed to destinations via NYSE Chicago using EquityExDestination (22016). |
| 1.0.2 | 04/25/24 | Updated the diagram in "Appendix B - Architectural Diagram". Updated text of CrossInitiator field in "5 List of Message Fields". |
| 1.0.3 | 05/01/24 | Updated descriptive text in "Appendix B - Architectural Diagram". |
| 1.0.4 | 05/08/24 | Updated descriptive text in "Appendix B - Architectural Diagram". |
| 1.0.5 | 05/23/24 | Clarified the InFlight description to indicate the total number of messages "in-flight" from the port can includes messages queued to send as well messages already sent. Updated the QuoteCnt description to indicate the maximum number of quotes in the message is 20. |
| 1.0.6 | 06/11/24 | Updated Login Request Session message Type value. |
| 1.0.7 | 07/01/24 | Added LogoutReason value ‘E’ for End of Day to the `Logout Response` message. Clarified that there is no longer a systematically enforced limit on the number of open orders or quotes a firm may have entered on the exchange from a unitized port. Clarified that RiskResetResult value `<space>` = Ignored; exceeds 1 reset per 100 milliseconds . Clarified that `Done For Day` messages represent orders persisted during the current day session to carry over to the next session. Added ExDestination (100) = `w` (MIAX Sapphire) and ContraBroker (375) = `SPHR` . Clarified that using RiskRoot and TargetMatchingUnit at the same time will result in a reject with RiskResetResult = M, even if TargetMatchingUnit is otherwise correct for the given RiskRoot . |
| 1.0.8 | 07/11/24 | Updated diagram and descriptive text in "Appendix B - Architectural Diagram". |
| 1.0.9 | 07/31/24 | Added new Section 1.2 - Certification Requirement. Added RestatementReason value ‘K’ for price sliding reprice (BZX only). Updated OrderRestatedUSOptionsV1 message RestatementReason field to OrderRestatementReason . Updated the Done for Day Restatements and Carried Order Restatements sections and removed Carried Order Restatements and Done for Day Restatements port attributes. Updated `Purge Orders, Mass Cancel Acknowledgment` , and `Purge Acknowledgement` messages descriptions and the MassCancelInst field description to correctly identify the usage of the request and response message types. Updated ‘Note’ for message types not yet accepted to indicate that they are subject to change ( `New Order Cross, New Complex Instrument, New Complex Order, New Order Cross Multileg` ). Corrected length of MassCancelInst in "List of Message Fields" from 16 to 8. |
| 1.0.10 | 08/12/24 | Added NewOrderUSOptionsV1 to Message Type List for Member to Cboe. Updated MassCancelInst to indicate that a self-imposed lockout can be release by sending a `Reset Risk` message. |
| 1.0.11 | 01/15/25 | Updated MaturityDate , PutOrCall , and StrikePrice descriptions in List of Message Fields . Clarified `CarriedRestatementUSOptionsV1` and `DoneForDayUSOptionsV1` messages are sequenced. Updated with Cboe Titanium branding. |
| 1.0.12 | 01/23/25 | Updated RequestReceivedTime description in List of Message Fields. Removed Send Trade Breaks and Symbol Order Rate Threshold from Port Attributes. Added Symbol Order Rate threshold is no longer an available risk port attribute for BOEv3 to the Differences with prior version of BOE section. |
| 1.0.13 | 03/05/25 | Members can optionally choose to reject the AIM auction rather than have the starting price adjusted to meet NBBO requirements using AutoMatch (9040) options '3' and '4'. AutoMatchPrice (9044) will be required if AutoMatch is set to '2' or '4' (C1 and EDGX only). Removed "or correct unit" from MatchingUnit field description in PurgeOrdersUSOptionsV1 Message Fields . Removed note that Market orders imply TimeInForce of IOC. |
| 1.0.14 | 03/18/25 | Added new section to Drill-Through Protection for Simple Limit Orders for Wide Market Protection (effective04/03/25 TBD (EDGX) and 04/07/25 TBD (C1, C2, BZX)). |
| 1.0.15 | 03/28/25 | Updated Wide Market Protection effective date to TBD. |
| 1.0.16 | 04/11/25 | Added z (invalid reduce size restriction) to Quote Reason Codes . Effective 04/25/25 on EDGX and 04/28/25 on BZX, C1, and C2, any `Quote Update` message with a QuoteCnt larger than '1' and a PostingInstruction = `I` (Book Only, IOC) will be rejected. |
| 1.0.17 | 07/08/25 | Effective 09/08/25, the DateTime data type will begin populating the nanoseconds portion. Added "Send Nanoseconds" port attribute (effective 09/08/25). |
| 1.0.18 | 07/24/25 | Added z (invalid reduce size restriction) to Quote Reason Codes . Added CrossInitiator , CrossOnBehalfofID , and UseDrillThruOverride fields to `NewComplexOrderUSOptionxV1` message. Specification updated to indicate complex functionality is available for all Cboe Options Exchanges, with BZX Options complex functionality effective on 10/13/25. |
| 1.0.19 | 07/25/25 | Updated Cowen to TD Securities (USA) LLC. |
| 1.0.20 | 07/28/25 | Added `LegCnt` = 0 (no LegPositionEffect provided) will cause al legs to have a LegPositionEffect of N (none). to the description of the LegCnt field in `NewComplexOrderShortOptionsV1` message. |
| 1.0.21 | 08/12/25 | Updated Quote Update Acknowledgment message to indicate that for quotes which may remove liquidity or which may post and cause additional Matching Engine action to be taken QuoteResult values of `D` or `d` will be returned. In these cases, executions, cancellations, or modifications (as needed) will immediately follow as additional messages. |
| 1.0.22 | 08/15/25 | Updated CustomGroupIDCnt description to indicate a maximum of 10 integers are allowed. |
| 1.0.23 | 08/20/25 | Updated Carried Order Restatements to indicate that GTC and GTD orders entered during partial holiday sessions can also persist between multiple trading sessions. Updated Cancellation of Carried Orders Between Trading Sessions to indicate that at the scheduled end of trading for a product, cancellation requests for persisted orders in that product will be rejected with reason `O: Order known, but cannot be canceled at this time until after the system restart completes.` |
| 1.0.24 | 08/22/25 | Removed and clarified language in Drill-Through Protection for Simple Limit Orders. Added and clarified language in Market/Limit Order Drill-Through for Complex Orders. |
| 1.0.25 | 09/08/25 | Removed "Send Nanoseconds" port attribute. |
| 1.0.26 | 09/11/25 | Updated List of Message Fields to include new StrategyID (C1 Only) values `F` = CompressionForum ,`B` = BoxSpread, and `A` = BoxSwap. |
| 1.0.27 | 10/03/25 | Removed Complex Order language from Drill-Through Protection for Simple Limit Orders . Clarified language in Market/Limit Order Drill-Through for Complex Orders . |
| 1.0.28 | 10/20/25 | Renamed "Drill-Through Protection for Simple Limit Orders" to "Drill-Through Protection for Simple Orders". Updated Hours of Operation to remove reference to specific products traded in GTH, replacing it with "GTH-eligible Products". |
| 1.1.0 | 10/31/25 | Added new messages and updated Appendix B - Architectural Diagram to support adding C1, C2, and EDGX to the Cboe Titanium U.S. Options BOEv3 Specification. `PurgeOrdersUSOptionsV1` message is supported on BZX only and will be sunset on 03/23/26. Added `PurgeOrdersUSOptionsV2` message (effective 01/12/26). |
| 1.1.1 | 11/21/25 | Updated MessageType description from 2017,0x07E1 to 2018,0x07E2 in `ComplexQuoteUpdateShortUSOptionsV1` message. |
| 1.1.2 | 11/25/25 | Removed Stale NBBO from the Cboe Titanium U.S. Options BOEv3 specification. |
| 1.1.3 | 12/08/25 | Added Wide Market Protection (C1 only) and updated Drill-Through Protection for Simple Orders (effective 12/15/25). |
| 1.1.4 | 12/15/25 | Removed BOE Purge Ports note that since Purge Ports are also provisioned per matching unit, a purge request will be limited to the symbol range populated in TargetMatchingUnit. |
| 1.1.5 | 01/12/26 | Updated Carried Order Restatements to explain restatements will be sent at the new order carry over time (effective 02/02/26). |
| 1.1.6 | 01/13/26 | Added `NewComplexOrderUSOptionsV2` message, added StopPxType field, and updated StopPx field description to include complex orders (effective TBD 05/18/26 TBD). |
| 1.1.7 | 01/20/26 | Updated tables in Exchange Default Fat Finger Limits to clarify relevant products. |
| 1.1.8 | 02/10/26 | Updated Nasdaq BX to Nasdaq Texas. Added TargetMatchingUnit to the set of values that make a `Reset Risk` message unique (effective 02/16/26). |
| 1.1.9 | 02/27/26 | Updated New Complex Instrument Message Fields to indicate complex orders are restricted to a minimum of 2 legs and a maximum of 16 legs. In Wide Market Protection, updated WMP Determinants table to include all proprietary index products (effective 03/09/26). |
| 1.1.10 | 04/06/26 | In NewComplexOrderUSOptionsV1 , updated the example in the Price field. In Port Attributes , updated Maximum Order Size to include the maximum order size of 99,000 for C1 only . Updated effective date to TBD 05/18/26 : Added `NewComplexOrderUSOptionsV2` message, added StopPxType field, and updated StopPx field description to include complex orders. The `NewComplexOrderUSOptionsV1` message will be sunset TBD 07/20/26 . |
| 1.1.11 | 4/14/26 | Updated MassCancelInst value `F` to indicate that all orders that were sent under the clearing relationship specified in ClearingFirm field. If `F` is specified and ClearingFirm not provided, the `Mass Cancel` or `Purge` request will be rejected in List of Message Fields . Updated Purge Orders Message Fields to indicate that on BZX Purge messages are available only on a unitized purge port and on C1, C2, and EDGX, CustomGroupID or EFID ( ClearingFirm ) purges with no RiskRoot may be directed to a specific matching unit using the TargetMatchingUnit field. Updated EFID Filter for Purge Ports port attribute to indicate that a purge request (with the first character of MassCancelInst = `F` ) specifies an EFID not included in the list of configured EFIDs, the purge request will be rejected. If a purge port is configured with multiple EFIDs and a purge request is sent (with the first character of MassCancelInst = `A` ) without any EFIDs specified, the purge will be applied only to the list of configured EFIDs.​ |
| 1.1.12 | 04/15/26 | Updated Exchange Default Fat Finger Limits, Cancellation of Carrier Orders Between Trading Sessions, Holiday Sessions (C1 Only), and Hours of Operation to reflect planned expansion of C1 trading hours for select equity options, including the addition of a morning Global Trading Hours (GTH) session and afternoon Curb session, subject to regulatory review (effective 07/13/26 08/17/26). |
| 1.1.13 | 05/14/26 | Updated effective date to TBD: Added `NewComplexOrderUSOptionsV2` message, added StopPxType field, and updated StopPx field description to include complex orders. The `NewComplexOrderUSOptionsV1` message will be sunset TBD. |
| 1.1.14 | 06/12/26 | Updated planned expansion of C1 trading hours for select equity options to 08/17/26. |
| 1.1.15 | 06/29/26 | Updated Mass Cancel Order Message Fields and List of Message Fields to deprecate Lockout instruction on Mass Cancel messages (effective 08/24/26). |
| 1.1.16 | 06/30/26 | Updated RoutingInst in List of Message FIelds, indicating `S`=Expose order via Step-Up Mechanism (SUM) will be applicable to C2 effective 09/04/26. |
| 1.1.17 | 07/06/26 | Updated ClearingOptionalData to indicate it is passed through to clearing and is included in Execution Reports on FIX DROP feeds List of Message Fields . Updated ​ Account to indicate that when clearing OCC, the value is passed to clearing in the Clearing Member Optional Data field (16 characters) and the Customer ID field (10 characters). When clearing Cboe Clear U.S., the value is passed in the Customer Account Number field on List of Optional Fields . |
| 1.1.18 | 07/07/26 | Updated Order Reason Codes to add code 4=After volatility cutoff. Updated List of Message Types to indicate `DeleteFloorTradeAcknowledgementUSOptionsV1` and `FloorTradeNotificationUSOptionsV1` are unsequenced Cboe to Member messages. |
| 1.1.19 | 08/06/26 | Added ContraBroker values IEX and MXTO, and ExDestination values I and J for IEX Options and MX2 Options. |
| 1.1.20 | 08/14/26 | Noted that Cabinet and Sub-Cabinet Orders (C1 Only) require direct or default floor routing instructions. |
| 1.1.21 | 08/17/26 | Effective 08/24/26, the drill-through preset duration will be 100 ms for all products on all Exchanges, and WMP will be initiated up until the close of the RTH or Curb trading sessions. Updated effective date to 09/28/26 for deprecate Lockout instruction on Mass Cancel messages. |