# Cboe Titanium U.S. Equities BOEv3 Specification

Version 1.0.12 · August 4, 2026

## Introduction

This document describes Binary Order Entry, version 3 (BOEv3), the Cboe proprietary order entry protocol used by members to send orders 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 Fields.

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. The `Logout Response` message no longer returns the LastReceivedSequenceNumber, nor the highest available sequence numbers of the matching unit(s).
3. BOEv3 requires the 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.
4. When logging in, members may specify a behavior of "Fail" for unspecified matching units (fail the login if a matching unit was not specified). For more information about Fail, Skip, and Replay behaviors, see For more information about Fail, Skip, and Replay behaviors.
5. 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.
6. 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.
7. An InFlight field has been added to most return messages, informing the member of the total number of messages received by the BOEv3 order handler which have not yet been acknowledged by the matching engine.
8. BOEv3 `Trade Cancel` or `Correct`messages are not suppressible by port parameter.
9. 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 via BOEv2.
10. For sequenced messages from the member to Cboe, a sequence number of `0` will always be accepted and is treated as if it were the next expected sequence number.
11. Symbol Order Rate threshold is no longer an available risk port attribute for BOEv3.
12. Sustained Order Rate thresholds are no longer available, and instead the use of rate limiting via pause is recommended.
13. LocateReqd on NewOrderShortUSEquitiesV1 is implied to be a value of 'N', and thus is not a field on the message itself.
14. Binary Price and Short Binary Price data types have been expanded to have six implied decimals rather than four.
15. For the Symbol field, only Cboe symbology is now supported, thus the BOEv2 field SymbolSfx is no longer utilized.
16. BOEv3 will echo reject messages to ODROP.
17. BOEv3 will exclusively use `Order Restated` message for any MTP activity, including all MTP cancels. In BOEv2 MTP decrements or cancels was provided to customers via a mix of `Order Restated` and `Order Cancelled` messages.

### 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 |
|---|---|---|---|
| NewOrderUSEquitiesV1 | `New Order` | US Equities | V1 |

This allows for ease of distinction between similar message types between markets (for example, JP Equities compared to U.S. 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.

### 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 Equities Exchanges (BZX Equities Exchange BZX only, BYX Equities Exchange BYX only, EDGA Equities Exchange EDGA only, and EDGX Equities Exchange EDGX only).

### Hours of Operation

All times noted are Eastern Time zone (ET) based.

Refer to the website for the Cboe Holiday schedule.

Cboe BZX Equities Exchange (BZX) supports an opening and closing auction for BZX listed securities (refer to the Cboe Titanium U.S. Equities Auction Process Specification for more information).

Orders entered prior to the start of the Regular Trading Session which are accepted will be queued for trading in the session designated by the order. Once trading begins, queued orders will be released to the respective book and crossing orders will be matched by time priority. Refer to the Cboe Titanium U.S. Equities Opening Process Specification for more information.

Orders are rejected if they are received outside the hours Cboe is available for trading or queuing. All orders remaining after the Post Market Session will be cancelled automatically (Execution Reports will be delivered).

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

### 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 six implied decimal places. So, if the value is 12,340,000, the actual value considering implied decimal places is 12.340000.
  - `20 4B BC 00 00 00 00 00` = 12,340,000/1,000,000 = 12.340000
  - `E0 B4 43 FF FF FF FF FF` = -12,340,000/1,000,000 = -12.340000
- Short Binary Price: Little Endian byte order value, signed two's complement, four bytes in size, with six implied decimal places. So, if the value is 12,340,000, the actual value considering implied decimal places is 12.340000.
  - `20 4B BC 00` = 12,340,000/1,000,000 = 12.340000
  - `E0 B4 43 FF` = -12,340,000/1,000,000 = -12.340000
- Access Fee: Little Endian byte order value, signed two's complement, eight bytes in size, with five implied decimal places. So, if the value is 141,341, the actual value considering implied decimal places is 1.41341. 1D 28 02 00 00 00 00 00 = 141,341/100,000 = 1.41341 E3 D7 FD FF FF FF FF = -141,341/100,000 = -1.41341
- 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).
  - `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.

Some blank Alpha and Text fields (entirely filled with ASCII NUL (0x00)) are eligible to be populated with a port default value. See US Equities BOE 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 process 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.

Each BOE order handler will connect, using a proprietary UDP protocol, to all matching units. Connections from order handlers to matching engines are latency equalized. The connections between order handlers and matching units are governed by an internal flow control mechanism to control burst rates.

The number of messages in flight between each order handler and matching engine is 32. 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 each new order, cancel/replace, or cancel message will count as one message.

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 with at least two weeks’ notice. Cboe reserves the ability to increase either limit immediately with notice.

#### Dedicated Cores

Cboe offers an optional Dedicated Cores service that allows Members and Sponsored Access Participants to host their specific BOE logical order entry ports on their own dedicated CPU core(s). By utilizing the full processing power of a dedicated CPU core — rather than sharing a core among multiple logical order entry ports on a given server — Dedicated Cores may provide reduced latency, enhanced throughput, and improved performance.

Firms may operate across a mix of shared and dedicated CPU cores, enabling additional flexibility for risk and capacity management. There are no changes to the BOE order entry protocol associated with the use of Dedicated Cores.

Each Dedicated Core supports a single BOE logical port. When requesting a new BOE logical port, firms wishing to utilize this service must request that the new logical port be hosted on a Dedicated Core. Risk settings for BOE logical ports on Dedicated Cores can be managed independently; firms utilizing such ports are encouraged to confirm risk settings prior to use.

- The maximum number of Dedicated Cores allowed for each Member is 170.
- The maximum number of Dedicated Cores for each Sponsored Access Participant access relationship with a Sponsoring Member is 85.

Firms may request Dedicated Cores using the Logical Port Request Tool within the Cboe Customer Web Portal. Standard monthly logical port fees apply in addition to applicable Dedicated Core fees. For current fee schedules, refer to the applicable U.S. Equities Exchange fee schedule.

#### Cboe Market Close (BZX Only)

Cboe Market Close on BZX allows for Members to submit buy and sell Market-On-Close orders designated for participation in CMC in order to obtain the official closing price for any matched shares. Any remaining shares will be cancelled back to Members.

At 2:30 a.m. ET, Members may enter new orders to participate in CMC. Members will populate the following BOE fields to send a CMC order.

**Table 1. CMC `New Order` Fields**

| Field Name | Req'd | Description |
|---|---|---|
| OrdType | Y | `1`=Market |
| TimeInForce | Y | `7`=At the Close |
| RoutingInst | Y | `B`=Book Only |
| CmcSessions | N | `A` = 3:15 p.m. `D` = 3:30 p.m. `L` = 3:49 p.m. `S` = 3:54 p.m. (Nasdaq-listed only) |

An `Order Restated` message will be sent for any fully or partially matched CMC order after the order executes in a CMC matching session. A standard `Order Canceled` message will be sent for any CMC order that does not have any matched quantity after the final CMC session when the eligible order has finished. The restatement will contain the following fields:

**Table 2. CMC `Order Restated` Fields**

| Field Name | Description |
|---|---|
| RestatementReason | `C`=CMC Restatement |
| LastShares | Number of Shares Cancelled (if any) |
| LeavesQty | Quantity of unexecuted shares. Will include shares already matched in a previous session. |
| CmcMatchQty | Matched size for CMC matching session. |

After the closing price is received one or more `Order Execution` messages, totaling the sum of the matched size from each restatement, will be sent for each CMC order. The execution message will contain the following fields:

**Table 3. CMC `Order Execution` Fields**

| Field Name | Description |
|---|---|
| LastShares | Execution Size |
| LastPx | Execution Price (official close price) |

If a closing price is not received from the primary listing exchange by 8:00 p.m. ET, then all CMC matched shares will be cancelled. In the event that a closing price is updated by the primary listing exchange after its initial publication, then a Trade Cancel or Correct message will be sent to update the execution price for each CMC execution impacted by the changed closing price.

#### Periodic Auctions (BYX Only)

The Periodic Auction process is a price forming auction that runs for a fixed time period of 100 milliseconds and is only available during the regular trading session. A Periodic Auction starts when two opposite side Periodic Auction orders of either type can match. Continuous book displayed and non-displayed orders are not eligible to initiate a Periodic Auction but may be swept into the auction at the end of the auction process. Members can populate the following instructions to send a Periodic Auction order.

**Table 1. Periodic Auctions Fields**

| Field Name | Req’d | Description |
|---|---|---|
| CrossTradeFlag | Y | Can be entered on individual orders or as a port setting. `0` = None (to override port settings if necessary) `1` = Periodic Auction Only `2` = Periodic Auction Eligible |
| TimeInForce | Y | `R` = Regular Hours only (Required for Periodic Auction Only orders) All TIFs except FOK and IOC supported for Periodic Auction Eligible orders. |
| DisplayIndicator | Y | `I` = Invisible |
| MinQty | N | Minimum total fill quantity, which may be made up of several consecutive smaller fills. If Enable True MinQty port attribute is set to `Yes` , orders will be converted into standard MinQty during a Periodic Auction. Periodic Auction Eligible orders will remain as True MinQty in the continuous book. |
| ExecInst | N | If OrdType (40) = `P` , only the following are accepted for Periodic Auction Only orders: `R` = Primary Peg `M` = Midpoint Peg If OrdType (40) = `P` , all instructions allowed for Periodic Auction Eligible orders. If ExecInst = `m` , the No Trade in a Locked Market instruction will only be applied when the PAE order is live in continuous book trading and will not apply to either initiating a Periodic Auction or to executing at the conclusion of the Periodic Auction. |
| PegDifference | N | For Periodic Auction Only Orders, aggressive offsets only for primary peg orders. Orders with passive offsets will be rejected. No restrictions for Periodic Auction Eligible Orders. |

The Execution Report will contain a new SubLiquidityIndicator value for Periodic Auction orders.

**Table 2. Periodic Auctions Execution Report Field**

| Field Name | Req’d | Description |
|---|---|---|
| SubLiquidityIndicator | Y | `P` = Periodic Auction |

#### Maximum Open Order Limits

The exchange limits the maximum number of open orders allowed on a BOE port to 100,000 per port (BYX/EDGA) and 300,000 per port (BZX/EDGX). New orders will be rejected once this limit is breached until the number of open orders drops back below the limit.

#### Stale NBBO

A stale NBBO will occur when the Cboe trading system determines that one or more SIP quote channels is impaired or down completely. If the trading system detects that an NBBO is stale, new orders for the affected symbol(s) will be rejected. Any existing orders will remain on the book but will not be allowed to update (user updates, peg movements, or sliding updates). Members will be allowed to cancel any open orders. Regular trading will resume when the NBBO for a given symbol is determined to be healthy by the Cboe trading system.

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

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). 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 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. Like 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` 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 and will then respond with its own `Logout` 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` message.

## 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=`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 for UnitSequence .

**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. Must be one of: `F` = fail if unit not specified `R` = replay any unspecified unit from zero `S` = skip replay of unspecified units |
| NumberOfUnits | 31 | 1 | Binary | The number (possibly 0) of unit/sequence pairs to follow, one per unit from which the 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` | BOE3 (58288, 0xe3b0) |
| MessageLength | `28 00` | 40 |
| MessageType | `01 00` | LoginRequest (1, 0x0001) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| SessionId | `00 00 00 00` |  |
| SessionSubId | `00 00 00 00` |  |
| Password | `00 00 00 00 00 00 00 00 00 00` |  |
| ReplayInstruction | `46` | Fail (70, 0x46, 'F') |
| NumberOfUnits | `02` | 2 |
| loginRequestUnits.UnitNumber[1/2] | `00` | 0 |
| loginRequestUnits.UnitSequence[1/2] | `00 00 00 00` | 0 |
| loginRequestUnits.UnitNumber[2/2] | `00` | 0 |
| loginRequestUnits.UnitSequence[2/2] | `00 00 00 00` | 0 |

#### 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` | BOE3 (58288, 0xe3b0) |
| MessageLength | `0a 00` | 10 |
| MessageType | `02 00` | LogoutRequest (2, 0x0002) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |

#### 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` | BOE3 (58288, 0xe3b0) |
| MessageLength | `0a 00` | 10 |
| MessageType | `03 00` | ClientHeartbeat (3, 0x0003) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |

### Cboe to Member

#### Login Response Message Fields

A `Login Response` message is sent in response to a `Login Request` message. On a successful login, 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. All units will be included in a successful `Login Response` message, regardless of whether all units were listed in the `Login Request` message.

**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 `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` | BOE3 (58288, 0xe3b0) |
| MessageLength | `56 00` | 86 |
| MessageType | `f5 01` | LoginResponse (501, 0x01f5) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| LoginResponseStatus | `00` | UNKNOWN (0, 0x00) |
| LoginResponseText | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |
| ClientSequence | `00 00 00 00` | 0 |
| NumberOfUnits | `02` | 2 |
| loginResponseUnits.UnitNumber[1/2] | `00` | 0 |
| loginResponseUnits.UnitSequence[1/2] | `00 00 00 00` | 0 |
| loginResponseUnits.UnitNumber[2/2] | `00` | 0 |
| loginResponseUnits.UnitSequence[2/2] | `00 00 00 00` | 0 |

#### 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` | BOE3 (58288, 0xe3b0) |
| MessageLength | `0a 00` | 10 |
| MessageType | `f6 01` | ReplayComplete (502, 0x01f6) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |

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

**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 `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` | BOE3 (58288, 0xe3b0) |
| MessageLength | `47 00` | 71 |
| MessageType | `f7 01` | LogoutResponse (503, 0x01f7) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| LogoutReason | `00` | UNKNOWN (0, 0x00) |
| LogoutReasonText | `00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00` |  |

#### 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` | BOE3 (58288, 0xe3b0) |
| MessageLength | `0a 00` | 10 |
| MessageType | `f8 01` | ServerHeartbeat (504, 0x01f8) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |

## Application Messages

### Member to Cboe

#### New Order Message Fields

Submission of a new order to Cboe.

##### NewOrderUSEquitiesV1 Message Fields

**Table 1. NewOrderUSEquitiesV1 Message Fields**

| Field | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `0xB0 0xE3` |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | `0x0FA1` |
| 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 | Text |  |
| Capacity | 72 | 1 | Text |  |
| RoutingInst | 73 | 4 | Text |  |
| Account | 77 | 16 | Text |  |
| DisplayIndicator | 93 | 1 | Text |  |
| DiscretionAmount | 94 | 2 | Binary |  |
| PegDifference | 96 | 8 | BinaryPrice |  |
| PreventMatch | 104 | 3 | Text |  |
| LocateReqd | 107 | 1 | Text |  |
| ExpireTime | 108 | 8 | DateTime |  |
| AttributedQuote | 116 | 1 | Text |  |
| ExtExecInst | 117 | 1 | Text |  |
| DisplayRange | 118 | 4 | Binary |  |
| StopPx | 122 | 8 | BinaryPrice |  |
| RoutStrategy | 130 | 6 | Text |  |
| RouteDeliveryMethod | 136 | 3 | Text |  |
| ExDestination | 139 | 1 | Text |  |
| RiskGroupID | 140 | 2 | Binary |  |
| CrossTradeFlag | 142 | 1 | Text |  |
| LocateBroker | 143 | 4 | Text |  |
| StepUpAmount | 147 | 4 | ShortBinaryPrice |  |
| CmcSessions | 151 | 2 | Alpha |  |

##### NewOrderShortUSEquitiesV1 Message Fields

**Table 1. NewOrderShortUSEquitiesV1 Message Fields**

| Field | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `0xB0 0xE3` |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | `0x0FA6` |
| 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 | Text |  |
| Capacity | 64 | 1 | Text |  |
| ShortRoutingInst | 65 | 1 | Text |  |
| ShortAccount | 66 | 10 | Text |  |
| DisplayIndicator | 76 | 1 | Text |  |
| RiskGroupID | 77 | 2 | Binary |  |
| LocateBroker | 79 | 4 | Text |  |

#### Cancel Order Message Fields

Request to cancel a single order.

##### CancelOrderUSEquitiesV1 Message Fields

**Table 1. CancelOrderUSEquitiesV1 Message Fields**

| Field | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `0xB0 0xE3` |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | `0x0FA3` |
| MatchingUnit | 6 | 1 | Binary | Zero (from member message) |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary |  |
| OrigClOrdID | 12 | 20 | Text |  |
| ClearingFirm | 32 | 4 | Alpha |  |

#### Modify Order Message Fields

Request to modify an order. Price, Side, OrderQty, StopPx, MaxFloor, and OrdType may be adjusted. Modifies will result in a loss of time priority unless the modification involves a decrease in OrderQty, a change to MaxFloor, a change to StopPx, or a change in Side from sell long to sell short or vice-versa.

Other fields (including ExecInst) will be ignored, and the value from the original order will be reused. In particular, note that when a Day ISO is modified, the ISO designation is applied to the new order.

A change in MaxFloor takes effect on the next reserve reload. A zero value for MaxFloor will be ignored. If MaxFloor is to be removed completely, then the order should be cancelled and a new order sent.

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 a new order) or `Order Modified` message (for a prior order modification) has been received. The BOE handler will reject a new `Modify Order` message if the prior order has not been accepted or the result of the prior modification from the Matching Engine has not been received. However, `Modify Order` requests that merely reduce OrderQty may be overlapped if the existing ClOrdID is reused - this is the only case where ClOrdID reuse is allowed. This exception only applies to orders currently on the local book. If the order has been routed away, a `Modify Rejected` message will be returned for the second or overlapping `Modify Order`.

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

##### BOEv2 to BOEv3 Migration Notice

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

##### ModifyOrderUSEquitiesV1 Message Fields

**Table 1. ModifyOrderUSEquitiesV1 Message Fields**

| Field | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | `0x0FA2` |
| MatchingUnit | 6 | 1 | Binary | Zero - from member message |
| Reserved | 7 | 1 | Binary | MUST be zero from member |
| SequenceNumber | 8 | 4 | Binary | The sequence number for this message. |
| ClOrdID | 12 | 20 | Text |  |
| OrigClOrdID | 32 | 20 | Text |  |
| ClearingFirm | 52 | 4 | Alpha |  |
| Symbol | 56 | 8 | Text |  |
| OrderQty | 64 | 4 | Binary |  |
| Price | 68 | 8 | BinaryPrice |  |
| OrdType | 76 | 1 | Text |  |
| Side | 77 | 1 | Text |  |
| MaxFloor | 78 | 4 | Binary |  |
| StopPx | 82 | 8 | BinaryPrice |  |
| CancelOrigOnReject | 90 | 1 | Text |  |
| LocateBroker | 91 | 4 | Text |  |

#### Purge Orders

Request to cancel a group of orders across all of the firm’s sessions. `Purge Orders` messages are only accepted on dedicated BOE Purge Ports. The MassCancelInst optional field is required and must be selected and populated. In addition, a firm may choose to implement one or more filters:

- ClearingFirm Filter - optionally cancel based on ClearingFirm. This is required for any self-imposed lockouts or for service bureaus. Set using first character of MassCancelInst and sending ClearingFirm.
- Symbol Filter - optionally cancel based on symbol. Set by sending a valid symbol. Cannot be combined with RiskGroupID filter.
- RiskGroupID Filter - optionally cancel based on RiskGroupID. A maximum of 10 RiskGroupIDs may be included on a single `Purge Orders` message. Set by populating RiskGroupIDCnt to a non-zero value. Cannot be combined with symbol filter.
- TargetMatchingUnit Filter - RiskGroupID or MPID purges with no Symbol filter may be directed to a specific matching unit using the TargetMatchingUnit field. If TargetMatchingUnit is zero or not specified, then these purge types will be sent to all matching units. Note that this may result in self-imposed, risk lockouts occurring on select units while other units are still trading.

A firm may use the second character of MassCancelInst to set the acknowledgment style. If a single `Purge Acknowledgment` message is selected, then MassCancelID must be sent.

A firm may also impose a lockout using the third character of MassCancelInst, which cancels any open orders and causes inbound orders received after the lockout to be rejected. A self-imposed lockout requires an MPID (ClearingFirm) to be sent. The firm may also choose to lockout by symbol or RiskGroupID but not by both.

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

An identical purge message is defined as a message having all of the same RiskGroupID, Symbol, ClearingFirm, TargetMatchingUnit, and Lockout Instruction field values, as a previously received message.

##### PurgeOrdersUSEquitiesV1 Message Fields

**Table 1. PurgeOrdersUSEquitiesV1 Message Fields**

| Field | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `0xB0 0xE3` |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | `0x0FA5` |
| 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 |  |
| MassCancelInst | 36 | 8 | Text |  |
| Symbol | 44 | 8 | Text |  |
| TargetMatchingUnit | 52 | 1 | Binary |  |
| RiskGroupIDCnt | 53 | 1 | Binary |  |
| → RiskGroupID | 54 | 2 | Binary | (Repeats RiskGroupIDCnt times) |

#### Reset Risk Message Fields

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

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

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

##### ResetRiskUSEquitiesV1 Message Fields

**Table 1. ResetRiskUSEquitiesV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x0FA4 |
| 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 |  |
| Symbol | 40 | 8 | Text |  |
| TargetMatchingUnit | 48 | 1 | Binary |  |
| RiskGroupID | 49 | 2 | Binary |  |

### Cboe to Member

#### Order Acknowledgment Message Fields

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

##### OrderAcknowledgementUSEquitiesV1 Message Fields

**Table 1. OrderAcknowledgementUSEquitiesV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x1195 (4501) |
| 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 |  |
| OrdType | 59 | 1 | Text |  |
| Symbol | 60 | 8 | Text |  |
| ClearingFirm | 68 | 4 | Alpha |  |
| LeavesQty | 72 | 4 | Binary |  |
| DisplayPrice | 76 | 8 | BinaryPrice |  |
| WorkingPrice | 84 | 8 | BinaryPrice |  |
| BaseLiquidityIndicator | 92 | 1 | Text |  |
| SubLiquidityIndicator | 93 | 1 | Text |  |

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

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

##### OrderRejectedUSEquitiesV1 Message Fields

**Table 1. OrderRejectedUSEquitiesV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x1196 (4502) |
| 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 |  |
| OrderRejectReason | 46 | 1 | Text |  |
| Text | 47 | 60 | 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.

##### OrderModifiedUSEquitiesV1 Message Fields

**Table 1. OrderModifiedUSEquitiesV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x1197 (4503) |
| 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 |  |
| Symbol | 74 | 8 | Text |  |
| Side | 82 | 1 | Text |  |
| Price | 83 | 8 | BinaryPrice |  |
| OrdType | 91 | 1 | Text |  |
| MaxFloor | 92 | 4 | Binary |  |
| OrderQty | 96 | 4 | Binary |  |
| StopPx | 100 | 8 | BinaryPrice |  |
| LeavesQty | 108 | 4 | Binary |  |
| DisplayPrice | 112 | 8 | BinaryPrice |  |
| WorkingPrice | 120 | 8 | BinaryPrice |  |
| BaseLiquidityIndicator | 128 | 1 | Text |  |
| SecondaryOrderID | 129 | 8 | Binary |  |

#### 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.
- An order's remaining quantity was decremented because of a prevented wash trade.
- 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. In addition, all MTP related cancels will be sent using an `Order Restated` message with LeavesQty set to zero. This is necessary since in BOEv3 only the `Order Restated` message contains the MTP-related fields: SecondaryOrderID, LastShares, and LastPx. Members are advised that in FIX-formatted drop copies the MTP-related cancel messages will appear as standard FIX cancels.

##### OrderRestatedUSEquitiesV1 Message Fields

**Table 1. OrderRestatedUSEquitiesV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x1199 (4505) |
| 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 |  |
| Symbol | 54 | 8 | Text |  |
| OrderRestatementReason | 62 | 1 | Text |  |
| OrderQty | 63 | 4 | Binary |  |
| Price | 67 | 8 | BinaryPrice |  |
| LeavesQty | 75 | 4 | Binary |  |
| DisplayPrice | 79 | 8 | BinaryPrice |  |
| WorkingPrice | 87 | 8 | BinaryPrice |  |
| BaseLiquidityIndicator | 95 | 1 | Text |  |
| SecondaryOrderID | 96 | 8 | Binary |  |
| LastShares | 104 | 4 | Binary |  |
| LastPx | 108 | 8 | BinaryPrice |  |
| CmcMatchQty | 116 | 4 | Binary |  |

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

##### ModifyRejectedUSEquitiesV1 Message Fields

**Table 1. ModifyRejectedUSEquitiesV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x1198 (4504) |
| 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 |  |
| ClearingFirm | 22 | 4 | Alpha |  |
| ClOrdID | 26 | 20 | Text |  |
| OrigClOrdID | 46 | 20 | Text |  |
| ModifyRejectReason | 66 | 1 | Text |  |
| Text | 67 | 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` or a `Purge Orders` message.

For all MTP related cancels, Members should expect to receive an `Order Restated` message with LeavesQty = 0 and the full set of MTP-related fields. Refer to Order Restated message fields for further information.

##### OrderCancelledUSEquitiesV1 Message Fields

**Table 1. OrderCancelledUSEquitiesV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x119A (4506) |
| 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 |  |
| ClearingFirm | 22 | 4 | Alpha |  |
| ClOrdID | 26 | 20 | Text |  |
| CancelReason | 46 | 1 | Text |  |

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

##### CancelRejectedUSEquitiesV1 Message Fields

**Table 1. CancelRejectedUSEquitiesV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | `0xB0 0xE3 (58288)` |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | `0x119B (4507)` |
| 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 |  |
| ClearingFirm | 22 | 4 | Alpha |  |
| ClOrdID | 26 | 20 | Text |  |
| CancelRejectReason | 46 | 1 | Text |  |
| Text | 47 | 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.

##### OrderExecutionUSEquitiesV1 Message Fields

**Table 1. OrderExecutionUSEquitiesV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x119C (4508) |
| 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 |  |
| ClearingFirm | 22 | 4 | Alpha |  |
| ClOrdID | 26 | 20 | Text |  |
| ExecID | 46 | 8 | Binary |  |
| LastShares | 54 | 4 | Binary |  |
| LastPx | 58 | 8 | BinaryPrice |  |
| LeavesQty | 66 | 4 | Binary |  |
| BaseLiquidityIndicator | 70 | 1 | Text |  |
| SubLiquidityIndicator | 71 | 1 | Text |  |
| ContraBroker | 72 | 4 | Alphanumeric |  |
| Side | 76 | 1 | Text |  |
| Symbol | 77 | 8 | Text |  |
| FeeCode | 85 | 2 | Alphanumeric |  |
| AccessFee | 87 | 8 | AccessFee |  |

#### Trade Cancel or Correct Message Fields

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

##### TradeCancelCorrectUSEquitiesV1Block Message Fields

**Table 1. TradeCancelCorrectUSEquitiesV1Block Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x119D (4509) |
| 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 |  |
| OrigTime | 89 | 8 | DateTime |  |
| Symbol | 97 | 8 | Text |  |
| Capacity | 105 | 1 | Text | NotSet (0, 0x00) |

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

##### PurgeRejectedUSEquitiesV1 Message Fields

**Table 1. PurgeRejectedUSEquitiesV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x11A0 (4512) |
| 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.

##### ResetRiskAcknowledgementUSEquitiesV1 Message Fields

**Table 1. ResetRiskAcknowledgementUSEquitiesV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x119E (4510) |
| 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 |  |

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

##### PurgeAcknowledgementUSEquitiesV1 Message Fields

**Table 1. PurgeAcknowledgementUSEquitiesV1 Message Fields**

| Field Name | Offset | Length | Data Type | Description |
|---|---|---|---|---|
| StartOfMessage | 0 | 2 | Binary | 0xB0 0xE3 (58288) |
| MessageLength | 2 | 2 | Binary |  |
| MessageType | 4 | 2 | Binary | 0x119F (4511) |
| 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 |  |

## List of Message Fields

The following are descriptions of message 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. Reflected back on execution reports associated with this order. May be made available in the Member’s clearing file. Allowed characters are alphanumeric and colon. |  |  |  |  |  |  |  |  |
| AccessFee | 8 | AccessFee | Transaction fee or rebate, inclusive of earned tiers, for the trade. |  |  |  |  |  |  |  |  |
| AttributedQuote | 1 | Alphanumeric | Optional. Allows for an order to be attributed to a firm's MPID or optionally RTAL (for retail firms) in Cboe’s market data feeds. The order may also be included in attributed summary information displays related to quote/trade information on the Cboe website. Must opt-in to support through the Cboe Trade Desk. `N` = Do not attribute firm MPID to this order `Y` = Attribute firm MPID to this order `R` = Attribute RTAL to this order |  |  |  |  |  |  |  |  |
| 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 `W` = Waiting for execution at pre-market time as dictated by TimeInForce value and "Hold Early to 7am" port setting. Only applied on the initial order acknowledgment. |  |  |  |  |  |  |  |  |
| 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 for a list of possible reasons |  |  |  |  |  |  |  |  |
| CancelRejectReason | 1 | Text | Single character code for the cancellation Rejection reason. See Reason Codes or a list of possible reasons |  |  |  |  |  |  |  |  |
| CancelledOrderCount | 4 | Binary | Number of orders cancelled. This field corresponds to CancelledOrderCount (7696) in Cboe FIX |  |  |  |  |  |  |  |  |
| Capacity | 1 | Alpha | Corresponds to OrderCapacity (47) in Cboe FIX. `A` = Agency `P` = Principal `R` = Riskless Principal |  |  |  |  |  |  |  |  |
| 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, the 'at' symbol and double quotes. 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. However, we strongly recommend that you keep your ClOrdID values unique |  |  |  |  |  |  |  |  |
| ClearingAccount | 4 | Text | Corresponds to OnBehalfOfSubID (116) and ClearingAccount (440) in Cboe FIX. Supplemental identifier. Recorded and made available in execution reports. Available via Drop feeds. |  |  |  |  |  |  |  |  |
| ClearingFirm | 4 | Alpha | Corresponds to OnBehalfOfCompID (115) and ClearingFirm (439) Cboe FIX. MPID that will clear the trade. Must be an allowed NSCC MPID. Port attribute value of `Default EFID` is used if not provided. |  |  |  |  |  |  |  |  |
| CmcMatchQty | 4 | Binary | Corresponds to CmcMatchQty (25023) in Cboe FIX. Matched size for CMC matching session. |  |  |  |  |  |  |  |  |
| CmcSessions | 2 | Text | 2 character field. Specifies the range of CMC sessions the order is eligible to participate in. If not specified CMC orders will be eligible to participate in all CMC matching sessions. 1st Character: First CMC session the order is eligible to participate in. If the second character is not provided the order will only participate in this session. 2nd Character: If provided, specifies the final CMC session the order is eligible to participate in. `A` = 3:15 p.m. `D` = 3:30 p.m. `L` = 3:49 p.m. `S` = 3:54 p.m. (Nasdaq-listed only) |  |  |  |  |  |  |  |  |
| ContraBroker | 4 | Alphanumeric | Corresponds to ContraBroker (375) in Cboe FIX. All externally matched (routed) executions will identify the away exchange. `AMEX` = Routed to NYSE American `ARCA` = Routed to NYSE Arca `BEX` = Routed to Nasdaq Texas `CHX` = Routed to NYSE Texas `ICRS` = Routed to Intelligent Cross (pending approval) `IEX` = Routed to Investors Exchange `INET` = Routed to Nasdaq `LTSE` = Routed to Long Term Stock Exchange `MEMX` = Routed to Members Exchange `NYSE` = Routed to NYSE `PERL` = Routed to MIAX PEARL Exchange `PSX` = Routed to Nasdaq PSX `NSX` = Routed to NYSE National `DRT` = Routed to DRT Pool `TFXE` = Routed to 24X `TXSE` = Routed to Texas Stock Exchange `BATS` = Routed to Cboe BZX Exchange * `BYXX` = Routed to Cboe BYX Exchange * `EDGA` = Routed to Cboe EDGA Exchange * `EDGX` = Routed to Cboe EDGX Exchange * *Internally matched if ContraBroker matches the identifier of the local trading platform's book. |  |  |  |  |  |  |  |  |
| CorrectedPrice | 8 | Binary | Price For trade corrections, this is the new trade price. For trade breaks, this is set to 0. |  |  |  |  |  |  |  |  |
| CrossTradeFlag (BYX Only) | 1 | Alphanumeric | Corresponds to CrossTradeFlag (9355) in Cboe FIX. Used to set eligibility for Periodic Auctions. Can be entered on individual orders or as a port setting. `0` = None (to override port setting as necessary) `1` = Periodic Auction Only `2` = Periodic Auction Eligible |  |  |  |  |  |  |  |  |
| DiscretionAmount | 2 | Binary | Corresponds to DiscretionAmount (9622) in Cboe FIX. Two implied decimal places (e.g., 10 = $0.10) Discretion is implicitly added to bid prices and subtracted from offer prices Order will be displayed at Price, but can be executed in the discretionary range. A discretionary order will use the minimum amount of discretion necessary to achieve execution. Maximum range is -9999 to 9999 (i.e., -99.99 to 99.99) May not be used with IOC orders. May not be used with Post Only orders. |  |  |  |  |  |  |  |  |
| DisplayIndicator | 1 | Alphanumeric | Corresponds to DisplayIndicator (9479) in Cboe FIX. Re-pricing Options: `V` = Default. As determined by port level setting (defaults to `S` ) `P` = Price Adjust `m` = Multiple Price Adjust `R` = Cancel back the order if it cannot be booked and displayed without adjustment `r` = Hidden; cancel back the order if it cannot be booked without adjustment `S` = Display Price Sliding (this is to override an opt-out of Display Price Siding at the port level) `L` = Display Price Sliding, but cancel back if order crosses the NBBO on entry `M` = Multiple Display Price Sliding `h` = Hidden Multiple Price Slide (effective 09/04/26) Other Options: `v` = Visible (for visible peg orders only; others will be rejected) `I` = Invisible (implied for Midpoint Peg orders) `N` = No Rescrape at Limit. Applicable only to fully routable, IOC orders ( RoutingInst = `R` and TimeInForce = `3` ). After walking the price to the limit, there will be no final scrape at Cboe and the cancel reason code will state `X` (Expired) rather than `N` (No Liquidity) . |  |  |  |  |  |  |  |  |
| 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. Present for hidden orders, indicating the price the order would have been displayed at. |  |  |  |  |  |  |  |  |
| 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. |  |  |  |  |  |  |  |  |
| ExDestination | 1 | Text | Corresponds to ExDestination (100) in Cboe FIX. Used to specify the designated away venue for RoutStrategy = `DIRC` and for RoutingInst = `A` (Post to Away) . `A` = NYSE American 1 `B` = Nasdaq Texas 1 `C` = NYSE National `F` = Texas Stock Exchange 1 `G` = 24X `H` = MIAX Pearl `I` = Investors Exchange `J` = EDGA 1 `K` = EDGX 1,2 `L` = Long Term Stock Exchange `M` = NYSE Texas `N` = NYSE 1 `P` = NYSE Arca 1 `Q` = Nasdaq 1 `T` = Intelligent Cross (pending approval) `U` = MEMX `X` = Nasdaq PSX `Y` = BYX 1 `Z` = BZX 1 1 Post to Away option available for ROUT and ROUX only. 2 Post to EDGX (for ROUT, ROUX, ROUZ, and RDOT). |  |  |  |  |  |  |  |  |
| 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 ODROP and 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 |  |  |  |  |  |  |  |  |  |  |
| ExecInst | 1 | Text | Corresponds to ExecInst (18) in Cboe FIX. `f` = Intermarket Sweep (Directed or Book/Post only) `P` = Market Peg (peg Buy [Sell] to NBBO Offer [Bid]) `Q` = Market Maker Peg (see Cboe Titanium U.S. Equities Market Maker Specification ) `R` = Primary Peg (peg Buy [Sell] to NBB Bid [Offer]) `U` = Supplemental Peg Order `M` = Midpoint (peg to NBBO Midpoint) `m` = Midpoint (peg to NBBO Midpoint, but do not match when NBBO is locked) `L` = Alternate Midpoint (less aggressive of midpoint and 1 tick inside NBBO) EDGA and EDGX: `d` = Midpoint Discretionary Order `e` = Midpoint Discretionary Order with Quote Depletion Protection BZX: `r` = Late (for use with Auction Only orders); see the Cboe Titanium U.S. Equities Auction Process Specification . BZX and EDGX: `o` = Listing Market Opening (for ROOC RoutStrategy only) `c` = Listing Market Close (for ROOC RoutStrategy only) `a` = Both Listing Market Open and Close (for ROOC RoutStrategy strategy only; also eligible for participation in halt auctions) |  |  |  |  |  |  |  |  |
| ExecRefID | 8 | Binary | Corresponds to ExecRefID (19) in Cboe FIX. Refers to the ExecID of the fill being cancelled or corrected. |  |  |  |  |  |  |  |  |
| 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. |  |  |  |  |  |  |  |  |
| ExtExecInst | 1 | Text | Corresponds to ExtendedExecInst (9416) in Cboe FIX. `N` = None `R` = Retail Order, eligible for Retail rebate. BYX and EDGX: `P` = Retail Order (Price Improvement Only) `T` = Retail Price Improving Order EDGX: `X` = Retail Priority Order, eligible for Retail Priority and Retail rebate rate. |  |  |  |  |  |  |  |  |
| 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. |  |  |  |  |  |  |  |  |
| InFlight | 2 | Binary | Total number of messages received by the order handler which have not yet been acknowledged by the matching engine. |  |  |  |  |  |  |  |  |
| LastPx | 8 | Binary Price | Corresponds to LastPx (31) in Cboe FIX. Price of this fill. In MTP restatements, the price at which LastShares would have matched. |  |  |  |  |  |  |  |  |
| LastShares | 4 | Binary | Corresponds to LastShares (32) in Cboe FIX. Executed share quantity. In MTP restatements, this is the number of shares that would have matched. |  |  |  |  |  |  |  |  |
| LeavesQty | 4 | Binary | Corresponds to LeavesQty (151) in Cboe FIX. Quantity still open for further execution. If zero, the order is complete. |  |  |  |  |  |  |  |  |
| LocateBroker | 4 | Alpha | Corresponds to LocateBroker (5700) in Cboe FIX. Used for short sale orders to identify the broker that the short seller has identified as the source from which they will borrow the securities they are selling short. |  |  |  |  |  |  |  |  |
| LocateReqd | 1 | Alpha | Corresponds to LocateReqd (114) in Cboe FIX. Optional, only processed for Sell Short and Sell Short Exempt orders. `N` = Client affirms ability to borrow (default) `Y` = Client does not affirm ability to borrow (results in reject) |  |  |  |  |  |  |  |  |
| MassCancelID | 20 | Text | Corresponds to MassCancelID (7695) in Cboe FIX. Copied from the MassCancelID passed on the original `Purge Orders` message. |  |  |  |  |  |  |  |  |
| MassCancelInst | 8 | Text | Corresponds to MassCancelInst (7700) in Cboe FIX. Used for specification of `Purge Orders` message functionality. At least one character must be provided (MPID Filter). Contiguous characters must be specified up to total length. Truncated/unspecified characters will default to values indicated (D) below. 1st Character: MPID Filter `A` = No filtering by MPID 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: Acknowledgment Style `M` = (D) Order Cancelled messages are sent for each cancelled order. If `M` is set and the MassCancelID optional field is specified, the MassCancelID value is ignored. `S` = A single `Purge Acknowledgment` message is sent once all cancels have been processed. The MassCancelID optional field must be specified or the o `Purge Orders` message will be rejected. `B` = Both individual `Order Cancelled` and `Purge Acknowledgment` messages will be sent. Also requires MassCancelID optional field to be specified or the `Purge Orders` message will be rejected. 3rd Character: Lockout Instruction `N` = (D) No lockout `L` = Lockout until corresponding RiskReset received. Lockout can be used only with MPID Filter set to `F` , otherwise the `Purge Orders` message will be rejected. Lockout will apply to all `New Order` and `Modify Order` messages for the ClearingFirm (and symbol or RiskGroupIDs , if specified). A self-imposed lockout can be released using the `ResetRiskUSEquitiesV1` message. |  |  |  |  |  |  |  |  |
| MaxFloor | 4 | Binary | Corresponds to MaxFloor (111) in Cboe FIX. Portion of OrderQty to display. The balance is reserve. 0 displays the entire quantity. The displayed quantity of each order at a price level is decremented first. When the displayed quantity is decremented below one round lot, it is is reloaded up to MaxFloor from reserve. `Default` = 0 |  |  |  |  |  |  |  |  |
| MinQty | 4 | Binary | Corresponds to MinQty (110) in Cboe FIX. Minimum fill quantity for non-routable hidden or non-routable IOC orders which only interact with liquidity on the target Cboe Exchange. Ignored if Enable True MinQty = `No` and the order is a routable displayed or routable IOC. Order is rejected if Enable True MinQty = `Yes` and the order is a routable displayed or routable IOC. Default is zero. Odd lot and mixed lot quantities allowed. When the remaining size on an order is less than the defined MinQty , then MinQty will be automatically set to the remaining size. When Enable True MinQty = `No` , the minimum total fill size may be made up of several consecutive smaller fills. Setting this port attribute to `Yes` will require every fill to meet the defined MinQty . See US Equities BOE Port Attributes for details. If Enable True MinQty = `Yes` , orders will be converted into standard MinQty during a Periodic Auction. Periodic Auction Eligible orders will remain as True MinQty in the continuous book (BYX Only) . |  |  |  |  |  |  |  |  |
| ModifyRejectReason | 1 | Text | Single character code for the Modify Rejection reason. See Reason Codes for a list of possible reasons |  |  |  |  |  |  |  |  |
| OrderQty | 4 | Binary | Corresponds to OrderQty (38) in Cboe FIX. Order quantity. System limit is 999,999 shares. On `Order Restated` messages, the OrderQty may be updated (for example, for SWP or CMC restatements). |  |  |  |  |  |  |  |  |
| OrderRestatementReason | 1 | Text | The reason for this Order Restated message. `C` = Cboe Market Close (CMC) `L` = Reload `P` = Peg or Price Sliding Reprice `Q` = Liquidity Updated `R` = Reroute `S` = Reduction of OrderQty due to SWP `W` = Wash or MTP Decrement Cboe reserves the right to add new values as necessary without prior notice. |  |  |  |  |  |  |  |  |
| OrdType | 1 | Alphanumeric | Corresponds to OrdType (40) in Cboe FIX. `1` = Market `2` = Limit (default) `3` = Stop `4` = Stop Limit `P` = Pegged Pegged requires ExecInst be set to `L` , `M` , `m` , `P` , `Q` , or `R` . Market implies a TimeInForce of Day. Market day orders post in LULD straddle state or if a short sale during a Regulation SHO short sale circuit breaker. Pegged orders may not be routable except for midpoint pegs BYX where RoutStrategy = `RMPT` , `RMPL` , or `DIRC` . Effective 12/07/26 , Pegged orders entered without a Price (44) are only accepted during RTH. |  |  |  |  |  |  |  |  |
| OrderID | 8 | Binary | Corresponds to OrderID (37) in Cboe FIX. Base 36 ASCII. Order identifier supplied by Cboe. This identifier corresponds to the identifiers used in Cboe market data products. |  |  |  |  |  |  |  |  |
| OrderRejectReason | 1 | Text | Single character code for an order rejection reason. See Reason Codes for a list of possible reasons |  |  |  |  |  |  |  |  |
| OrigClOrdID | 20 | Text | Corresponds to OrigClOrdID (41) in Cboe FIX. |  |  |  |  |  |  |  |  |
| OrigTime | 8 | DateTime | Corresponds to OrigTime (42) in the Cboe FIX. The date and time of the original trade, in GMT |  |  |  |  |  |  |  |  |
| PegDifference | 8 | Signed Binary Price | Corresponds to PegDifference (211) in Cboe FIX. Optional signed value up to four decimal places 1 , when the peg difference is below $1.00, is added to the result of peg calculation. When the peg difference is above $1.00 a maximum of two decimal places can be specified. Previously was required to be only a non-aggressive offset. Must be zero for non-pegged orders. Default is zero for Midpoint Discretionary Orders with ExecInst = `d` . Default is $0.01 (-$0.01) for sell (buy) Midpoint Discretionary Orders with ExecInst (18) = `e` . Displayed Primary Peg orders with non-aggressive offset must have TimeInForce = `R` (Regular Hours Only) or `0` (Day) . Day orders must be submitted after 9:30 a.m. ET. On BYX and EDGX : If ExtExecInst = `T` (Retail Price Improving order) : May be priced in $0.001 increments Must be ≥ 0 for Buy orders Must be ≤ 0 for Sell orders 1 PegDifference is rounded (down for buy, up for sell) to fit the tick size. For Periodic Auction Only orders, aggressive offsets only for primary peg orders. No restrictions for Periodic Auction Eligible orders. Orders with passive offsets will be rejected. |  |  |  |  |  |  |  |  |
| PreventMatch | 3 | Alpha | Corresponds to PreventMemberMatch (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 MPID Level `X` = Prevent Match at the Affiliate (Exchange Member) or Sponsored Participant 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, OrderQty as well). Match Trade Prevention will be supported for Periodic Auctions (BYX only) . |  |  |  |  |  |  |  |  |
| Price | 8 | Binary Price | Corresponds to Price (44) in Cboe FIX. Limit price. Six implied decimal places. Required for limit orders ( OrdType = `2` ). If specified on market order ( OrdType = `1` ), the order will be rejected. This field is also used to specify an optional cap price for pegged orders. |  |  |  |  |  |  |  |  |
| PurgeRejectReason | 1 | Text | Single character code for a purge rejection reason. See Reason Codes or a list of possible reasons |  |  |  |  |  |  |  |  |
| RiskGroupID | 2 | Binary | Corresponds to RiskGroupID (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 RiskGroupIDs . |  |  |  |  |  |  |  |  |
| RiskGroupIDCnt | 1 | Binary | Number of repeating RiskGroupID values included in this message. |  |  |  |  |  |  |  |  |
| RiskReset | 8 | Text | Corresponds to RiskReset (7692) in Cboe FIX. For use by customers to release MPID, symbol or RiskGroupID level lockout conditions resulting from self-imposed lockouts issued via `Purge Orders` messages. Single Character Values: `S` = Symbol level lockout reset `F` = MPID level lockout reset `C` = RiskGroupID lockout reset Values may be combined together to allow for resets of multiple self-imposed lockouts in a single message. For example, `FS` , `SC` , `FC` , and `SFC` are all acceptable values. If orders have been locked out any level, inbound orders for the locked symbol MPID or RiskGroupID will be rejected until this field is filled with the appropriate value on a `ResetRiskUSEquitiesV1` message. |  |  |  |  |  |  |  |  |
| 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. |  |  |  |  |  |  |  |  |
| 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` , `ROUX` , and `ROUE` . |  |  |  |  |  |  |  |  |
| RoutingInst | 4 | Text | Corresponds to RoutingInst (9303) in Cboe FIX. 1st character: `B` = Book Only (not routable, will remove from local book) 1 `P` = Post Only (not routable) 2 `R` = Routable `S` = Super Aggressive - Cross or Lock (order will be removed from the book and routed to any away quote that is locking or crossing the order). May remove liquidity after posting. `X` = Aggressive - Cross or Lock (order will be removed from the book and routed to any away quote that is locking or crossing the order) `K` = Super Aggressive When Odd Lot (routable order will be automatically assigned Super Aggressive status when it becomes an odd lot) `A` = Post to Away (a limit order that will post remainder to an away venue specified in ExDestination for applicable routing strategies) `N` = Non-Displayed Swap - Book only, Hidden order that may remove liquidity after posting. Requires DisplayIndicator = `I` . 2nd character (for use with RoutStrategy = `DIRC` , `TRIM` , `SLIM` , `SLIM+` only): `D` = Eligible to route to DRT `L` = Route to displayed markets only |  |  |  |  |  |  |  |  |
| RoutStrategy | 6 | Text | Corresponds to RoutStrategy (9400) in Cboe FIX. Please note: DRT: Dark Routing Technique LCPMC: Low Cost Protected Market Centers All exchanges: `ALLB` = Book + IOC Other Cboe Exchanges `RDOT` = Book + DRT + IOC/Day NYSE `ROUT` = Book + DRT + Street (default) `ROUX` = Book + Street `ROUZ` = Book + DRT `SWPA` = ISO Sweep of All Protected Markets `DIRC` = Book + DRT + Directed IOC or Directed ISO if ExecInst = `f` . ExDestination must also be sent. EDGA/EDGX: `ROUC` = Book + DRT + LCPMC + All Other Protected Markets + Posts to EDGX (EDGX only) or EDGA (EDGA only) BYX: `DIRC` = Book + Midpoint IOC IEX (also requires Ordtype = `P` , ExecInst = `M` or `m` , and ExDestination = `I` ) `RMPT` = Book + Midpoint IOC Select DRT/Lit Venues + Post to Local Book if non-IOC (must be used in conjunction with Midpoint Peg order type) `RMPL` = Book + Midpoint IOC RMPT Venues + Midpoint IOC RMPL Venues + Post to Local Book if non-IOC (must be used in conjunction with Midpoint Peg order type) BYX: `TRIM` = Book + NYSE National + Nasdaq Texas + (DRT) `SLIM` = Book + LCPMC + (DRT) + LCPMC + All other protected markets BZX: `TRIM` = Book + BYX + NYSE National + Nasdaq Texas + NYSE American + (DRT) `SLIM` = Book + BYX + LCPMC + (DRT) + LCPMC + All other protected markets `SLIM+` = BYX + BZX + LCPMC + (DRT) + LCPMC + All other protected markets 1 BZX/EDGX: `ROOC` = Listing Market Open + Book + DRT + Street + Listing Market Close 2 1 Route to BYX prior to scraping BZX unless price improvement is available. 2 Can be used with ExecInst = `a` , `c` , or `o` to specify listing market opening/closing eligibility. |  |  |  |  |  |  |  |  |
| 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. |  |  |  |  |  |  |  |  |
| ShortAccount | 10 | Text | See Account. |  |  |  |  |  |  |  |  |
| ShortRoutingInst | 1 | Text | See RoutingInst, first character only. |  |  |  |  |  |  |  |  |
| Side | 1 | Alphanumeric | Corresponds to Side (54) in Cboe FIX. `1` = Buy `2` = Sell `5` = Sell Short (client affirms ability to borrow) `6` = Sell Short Exempt |  |  |  |  |  |  |  |  |
| StepUpAmount (BYX only) | 4 | Short Binary Price | Corresponds to StepUpAmount (25025) in Cboe FIX. StepUpAmount is implicitly added to bid prices and subtracted from offer prices for Enhanced RPI (Retail Price Improvement) orders. The StepUpAmount value is specified in 0.001 minimum increments. The minimum value is 0.000 (default). The maximum value is 99.999. |  |  |  |  |  |  |  |  |
| StopPx | 8 | Binary Price | Corresponds to StopPx (99) in Cboe FIX. 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. |  |  |  |  |  |  |  |  |
| 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 `E` = Trade added RPI liquidity ( BYX and EDGX only ) `H` = Trade added hidden liquidity `I` = Trade added hidden liquidity that was price improved `J` = Execution from first order to join the NBBO `P` = Periodic Auction (BYX Only) `S` = NBBO-Setter fee eligible `V` = Visible liquidity add trade that was price improved `m` = Midpoint peg order `s` = Order set the NBBO but is not fee eligible |  |  |  |  |  |  |  |  |
| Symbol | 8 | Text | Corresponds to Symbol (55) in Cboe FIX. Entire Cboe format |  |  |  |  |  |  |  |  |
| TargetMatchingUnit | 1 | Binary | Corresponds to MatchingUnit (25017) in Cboe FIX. Matching unit number the `Purge Orders` message will be sent toward. If blank or `0` , the `Purge Orders` message will be sent to all units. Incompatible with symbol-level purges, specifying both symbol and TargetMatchingUnit will cause the `Purge Orders` message to be rejected. If both MassCancelInst = `L` and a MatchingUnit parameter specified, a lockout will occur and will impact only the specified matching unit. Subsequent risk resets will clear risk locks on all units. |  |  |  |  |  |  |  |  |
| Text | 60 | Text | Human readable text with more information about the reject reason. |  |  |  |  |  |  |  |  |
| TimeInForce | 1 | Alphanumeric | Corresponds to TimeInForce (59) in Cboe FIX. `0` = Day (default) (Early Trading Session until end of Regular Session) (EDGX only effective 12/07/26: Overnight Trading Session until end of Regular Session) `1` = GTC (allowed, but treated as Day) `2` = At the Open ( BZX only and Cboe listed securities only) `3` = IOC (Portion not filled immediately is cancelled) `4` = FOK (an IOC where the entire size must be filled, else the order will be cancelled back) `5` = GTX (Early Trading Session until end of Post-Market Session) (EDGX only effective 12/07/26: Overnight Trading Session until end of Post-Market Session) `6` = GTD (Early Trading Session; expires at earlier of ExpireTime or end of Post-Market Session) (EDGX only effective 12/07/26: expires at earlier of specified ExpireTime or end of Post-Market Session ) `7` = At the Close ( BZX only and applicable to Cboe Listed securities and Cboe Market Close symbols `E` = PRE (Pre-Market Trading Session until end of Regular Session) `R` = RHO (Regular Hours/Session Only) `T` = PTD (Pre-Market Trading Session; expires at earlier of specified ExpireTime or end of Post-Market Session) `X` = PTX (Pre-Market Trading Session until end of Post-Market Session) |  |  |  |  |  |  |  |  |
| WorkingPrice | 8 | Binary Price | Corresponds to WorkingPrice (9690) in Cboe FIX. If price had to be adjusted to a less aggressive value for some reason, then the adjusted price will be reported here, otherwise equals Price . |  |  |  |  |  |  |  |  |

## Reason Codes

The following is a list of all 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 test 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. Reason Codes**

| Code | Description |
|---|---|
| A | Admin |
| C | Capacity undefined |
| D | Duplicate identifier (e.g., ClOrdID) |
| E | Size reduction due to SWP restatement |
| F | Failed to quote |
| 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 |
| S | Short sale price violation |
| 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 |
| f | Risk management MPID or RiskGroupID level |
| m | Market access risk limit exceeded |
| o | Max open orders count exceeded |
| r | Reserve reload |
| s | Risk management symbol level |
| u | Limit Up Limit Down (LULD) |
| w | Would remove on unslide |
| x | Crossed market |
| y | Order received by Cboe during replay |
| z | Session end |

## US Equities BOE Port Attributes

The table below lists BOE port attributes that are configurable on the port or firm level. Changes to these attributes can be made by contacting the Cboe Trade Desk.

**Table 1. US Equities BOE Port Attributes**

| Attribute | Default | Description |
|---|---|---|
| All Routable to Halt Auction (BZX and EDGX Only) | No | Send all routable orders to the halt auction on the primary listing exchange. This applies to all routing strategies. |
| Allow Directed ISO1 | Yes | Allow or disallow ISO orders directed to other market centers. |
| Allow ISO1 | Yes | Allow or disallow ISO orders. |
| Allow MTP Decrement Override1,3 | No | Overrides the exception that requires both the resting and inbound order to be marked as Decrement. |
| Allow Post-Market | Yes | Allow orders to be entered after the Regular Session close. |
| Allow Pre-Market | Yes | Allow orders to be entered prior to Regular Session open. |
| Allow Sponsored Participant MTP Control1,3 | No | Allow Sponsored Participant 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 MPIDs1 | All MPIDs | MPID(s) allowed for trading on the port. If Sponsored Port attribute is enabled, only one Clearing MPID is allowed for trading on that port. |
| Cancel on Disconnect | Option 1 | Cancels open orders upon order handler session disconnect; both graceful and ungraceful. If Cancel On Disconnect is set, open orders in Symbols that are not in Closed state at the time of the disconnect are cancelled. `1` = Cancel continuous book orders only (default) `2` = Cancel all open orders (continuous + auction) * `3` = Do not cancel any open orders *If disconnect occurs during the cut-off period for an auction, On-Open, On-Close and Late orders that are to participate in the auction will not be cancelled. |
| Cancel on ME Disconnect | Yes | When set to `No`, this setting allows orders to remain open on a Matching Unit failover. When set to `Yes`, all open orders associated with a session are immediately cancelled in the event of loss of connectivity to a Matching Unit. In any event, if a failover takes longer than five minutes, all orders are cancelled unconditionally. |
| Cancel on Regulatory Halt | No | Cancels open orders upon receipt of a Regulatory Halt. |
| Cancel on Reject 2 | No | Cancels an order upon a modify reject. |
| Cancel Open Orders on DROP Port Disconnect1 | 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. `No` = Disabled `Yes` = Cancel all open orders Note this parameter applies to Standard FIX DROP ports and not Order-By-Order DROP ports (ODROP). |
| Capacity Override | None | When set, the capacity of individual orders received on the port will default to the Member specified order capacity. `None` = No override (default) `A` = Agency `P` = Principal `R` = Riskless Principal |
| 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 which cause a loss in priority will result in a cancel of the original order if the NBBO is crossed upon receipt of the modify request. |
| Default Attributed Quote 1,2 | (see description) | Default value for AttributedQuote (9732). May override at order level. `Yes` = Attribute to MPID `RTAL` = Attribute as RTAL `No` = Don’t Attribute (may override at order level) `Never` = Never Attribute * *May only change this setting to `Yes` or `No` after executing Attribution Addendum to Exchange User Agreement. |
| Default CrossTradeFlag (BYX Only) 1,2 | 0 | Sets default CrossTradeFlag for inbound orders to designate Periodic Auction eligibility. `0` = None (default) `1` = Periodic Auction Only `2` = Periodic Auction Eligible `3` = Midpoint Peg - Periodic Auction Only When set to `2` : IOC, FOK, and displayed orders are not converted to a Periodic Auction Eligible order and are sent to the book as-is. DisplayIndicator (9479) will be ignored if ExecInst (18) = `m` or `M` . When set to `3` : IOC, FOK, IOC/FOK orders with ExecInst (18) = `M` , and all other orders where ExecInst (18) != `m` will not be converted and will be sent to the book as-is. All non-IOC/FOK orders with ExecInst (18) = `M` will be converted to RHO Midpoint Peg - Periodic Auction Only order. Orders with the following RPI instructions will set this port attribute to `0` : ExtendedExecInst (9416) = `R` or `P` , plus is an IOC ExtendedExecInst = `T` |
| Default Exec Instruction 1,2 | (None) | Default execution instruction for new orders. See ExecInst for details. If a port level setting is present, new orders sent with a value of NULL 0x00 will use the port level setting. |
| Default MPID | None | Default MPID to use if none is sent on a `New Order` message. |
| Default MTP Value1,2,3 | None | Specifies default value for PreventMatch. When set to `X`, Affiliate Firm’s or Sponsored Participant’s match trade prevention will be used by default. |
| Default Price Sliding(Hidden Order Override)2 | S | Default price sliding behavior for hidden orders. See DisplayIndicator for details. |
| Default Price Sliding 2 | S | Default price sliding behavior. See DisplayIndicator for details. |
| Default Routing Instruction (Hidden Order Override)2 |  | Specifies a default value for RoutingInst that is applied to hidden orders only. |
| Default Routing Instruction2 |  | Specifies a default value for routing. Fields can be overridden at the order level. The defaults are RoutingInst = `R`, RouteDeliveryMethod = `RTI`, and RoutStrategy = `ROUT` |
| Default to Retail Order1,2,3 | None | Default ExtExecInst = `R` or `P` |
| Default True MinQty | No | Do not aggregate multiple contra orders to meet the MinQty specified on an order. If set to `Yes` , orders will be converted into standard MinQty during a Periodic Auction. Periodic Auction Eligible orders will remain as True MinQty in the continuous book (BYX Only) . |
| Disallow Market Orders | Option 1 | Controls the acceptance or rejection of inbound Market orders during continuous trading. `1` = Do not restrict Market orders `2` = Reject Market orders during continuous trading,but allow Market orders during openings, re-openings, auctions, and auction routing (e.g. ROOC) `3` = Reject all Market orders except MOO and MOC orders (including CMC orders) |
| Duplicative Order Protection Action | Option 1 | Action taken when Duplicative Order Protection criteria is met: `1` = Not enabled `2` = Reject new 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. |
| Early Trading Session Opt-Out ​ (Sunset Effective 12/07/26) ​ | No | Allows orders to be executable during the Early Trading Session . If set to `Yes` , the following TimeInForce values will be translated: 0 (DAY) → E (PRE) 5 (GTX) → X (PTX) 6 (GTD) → T (PTD) |
| Enforce Rate Limit via Pause | False | When set to `False` , the existing Port Order Rate Threshold, Sustained Port Order Rate Threshold, Symbol Order Rate Threshold, and Sustained Symbol Order Rate Threshold port attributes will be enforced by rejects (as described). When set to `True` , Port Order Rate Threshold, Sustained Port Order Rate Threshold, Symbol Order Rate Threshold, and Sustained Symbol Order Rate Threshold port attributes will be enforced by read pause instead of by rejects. |
| Fat Finger Protection1 | None | 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 https://cdn.cboe.com/resources/membership/US_EQUITIES_OPTIONS_WEB_PORTAL_PORT_CONTROLS_SPECIFICATION.pdf for complete details. |
| Force MDO with QDP (EDGA and EDGX Only) | n | When set, midpoint and standard MDO order types will default to MDO with QDP orders. `n` = Do nothing (default) `b` = Book only MDO with QDP `p` = Post only MDO with QDP |
| Hold Early Orders Until (BZX and EDGX Only) (Effective 12/07/26) | False | If configured, the system will use the later of the start time specified here or the start time of the TimeInForce value specified on the order. Start times may be set in 1/2 hour increments up to 9:00 a.m. ET. |
| Hold Early to 7am (BZX and EDGX Only) (Sunset Effective 12/07/26) | False | Controls the executable time of orders submitted prior to 7:00 a.m. ET with a TimeInForce (59) that allows trading in the Early Trading Session. `False` = Orders may enter the book and trade as early as 4:00 a.m. ET. `True` = Orders will be queued until 7:00 a.m. ET. |
| Lock Auction Orders (BYX Only) | False | Disallow order cancellation during periodic auction. `False` = Allow cancellations `True` = Do not allow cancellations |
| Maximum Order Dollar Value1 | Unlimited | Maximum dollar value per order. |
| Maximum Order Size1 | 25,000 | Maximum order quantity |
| MPID 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. |
| Port Order Rate Threshold | 5,000 msgs/s | The maximum allowed message rate on the session. When the first non-session level message is received, a one second window begins. During the second no more than 4,999 additional non-session level messages will be allowed within that window. If the rate is exceeded, all new orders in the time window are rejected, modifies are treated as cancels, and cancels are processed. Note: Order handler burst rates towards each matching unit may be limited as described in Architecture and Message in Flight Settings . |
| Reject Market Orders Without NBBO | No | Reject Market Orders (including unpriced Peg Orders and Stop Orders) when there is no NBBO on the opposite side. |
| Reject Orders on DROP Port Disconnect1 | No | If all associated 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 has been reestablished. Note this parameter does not apply to Order-By-Order drop ports (ODROP). |
| Reject Orders on DROP Port Timeout (seconds)1 | 30 seconds | Only applicable if Reject Orders on DROP Port Disconnect has been 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. |
| Risk Group Id(s) | No | A comma separated list of values that, if configured, will cause orders without one of the listed RiskGroupIDs to be rejected. |
| Routing Retail Indicator (EDGX Only) | No | Mark orders as retail when routing to dark liquiditypools. |
| Send All Local Rejects1 | No | Make all order, cancel, and modify rejects available via ODROP. By default, some rejects are discarded if they would violate the port rate limit. Note: choosing true for this attribute will enforce a hard 6,000 requests per second limit that is enforced by a read pause on this port. |
| Single Order ADV Check | None | Reject orders when order size exceeds a specified percentage of the 20-day ADV. Members may also specify a 20-day ADV amount below which the check will not be applied. |
| Sponsored Port | No | Designates that the session will carry Sponsored flow. |
| Sponsoree Firm ID | None | Only available when Sponsored Port is set to `Yes`. Will be populated with the Sponsored Firm's Firm ID. |

1Sponsored Participants require written approval from Sponsors to update these settings on ports associated to a Sponsor’s MPID.

2Port attribute can be overridden on an order by order basis.

3Requires certification.

## Appendix A: Example Application Messages

### Member to Cboe

#### NewOrderUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `97 00` | 151 |
| MessageType | `a1 0f` | NewOrderUSEquitiesV1 (4001, 0x0fa1) |
| 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 | `60 7a 60 01 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 | `41 41 50 4c 00 00 00 00` | AAPL |
| 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) |
| DiscretionAmount | `00 00` | 0 |
| PegDifference | `00 00 00 00 00 00 00 00` | 0.00 |
| PreventMatch | `00 00 00` |  |
| LocateReqd | `00` | NotSet (0, 0x00) |
| ExpireTime | `28 18 14 cf 13 84 32 17` | 2022-12-20 13:40:32.321321 |
| AttributedQuote | `00` | NotSet (0, 0x00) |
| ExtExecInst | `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` |  |
| RiskGroupID | `12 00` | 18 |
| CrossTradeFlag | `00` | NotSet (0, 0x00) |
| LocateBroker | `00 00 00 00` |  |
| StepUpAmount | `00 00 00 00` | 0.00 |
| CmcSessions | `00 00` |  |

#### NewOrderShortUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `51 00` | 81 |
| MessageType | `a6 0f` | NewOrderShortUSEquitiesV1 (4006, 0x0fa6) |
| 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 | `60 7a 60 01 00 00 00 00` | 23.10 |
| ExecInst | `00` | NotSet (0, 0x00) |
| OrdType | `32` | Limit (50, 0x32, '2') |
| TimeInForce | `36` | GTD (54, 0x36, '6') |
| Symbol | `41 41 50 4c 00 00 00 00` | AAPL |
| Capacity | `41` | Agency (65, 0x41, 'A') |
| RoutingInst | `00` |  |
| Account | `41 41 41 41 00 00 00 00 00 00` | AAAA |
| DisplayIndicator | `00` | NotSet (0, 0x00) |
| RiskGroupID | `12 00` | 18 |
| LocateBroker | `00 00 00 00` |  |

#### ModifyOrderUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `5d 00` | 93 |
| MessageType | `a2 0f` | ModifyOrderUSEquitiesV1 (4002, 0x0fa2) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `b2 01 00 00` | 434 |
| 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` |  |
| Symbol | `41 41 50 4c 00 00 00 00` | AAPL |
| OrderQty | `dc 05 00 00` | 1500 |
| Price | `60 7a 60 01 00 00 00 00` | 23.10 |
| OrdType | `32` | Limit (50, 0x32, '2') |
| Side | `32` | Sell (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') |
| LocateBroker | `00 00 00 00` |  |

#### CancelOrderUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `22 00` | 34 |
| MessageType | `a3 0f` | CancelOrderUSEquitiesV1 (4003, 0x0fa3) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `b3 01 00 00` | 435 |
| 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` |  |

#### ResetRiskUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `31 00` | 49 |
| MessageType | `a4 0f` | ResetRiskUSEquitiesV1 (4004, 0x0fa4) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `b4 01 00 00` | 436 |
| 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` |  |
| Symbol | `41 41 50 4c 00 00 00 00` | AAPL |
| TargetMatchingUnit | `00` | 0 |
| RiskGroupID | `12 00` | 18 |

#### PurgeOrdersUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `38 00` | 56 |
| MessageType | `a5 0f` | PurgeOrdersUSEquitiesV1 (4005, 0x0fa5) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `b5 01 00 00` | 437 |
| 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` |  |
| MassCancelInst | `41 00 00 00 00 00 00 00` | A |
| Symbol | `41 41 50 4c 00 00 00 00` | AAPL |
| TargetMatchingUnit | `00` | 0 |
| RiskGroupIDCnt | `02` | 2 |
| customGroups.RiskGroupID[1/2] | `12 00` | 18 |
| customGroups.RiskGroupID[2/2] | `13 00` | 19 |

### Cboe to Member

#### CancelRejectedUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `69 00` | 105 |
| MessageType | `9b 11` | CancelRejectedUSEquitiesV1 (4507, 0x119B) |
| 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 |
| ClearingFirm | `00 00 00 00` |  |
| ClOrdID | `5a 5a 2d 34 33 32 31 20 61 62 63 64 00 00 00 00 00 00 00 00` | ZZ-4321 abcd |
| 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 |

#### OrderAcknowledgementUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `5c 00` | 92 |
| MessageType | `95 11` | OrderAcknowledgementUSEquitiesV1 (4501, 0x1195) |
| 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.321321000 |
| 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 | `60 7a 60 01 00 00 00 00` | 23.10 |
| OrdType | `32` | Limit (50, 0x32, '2') |
| Symbol | `41 41 50 4c 00 00 00 00` | AAPL |
| 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) |

#### OrderRejectedUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `69 00` | 105 |
| MessageType | `96 11` | OrderRejectedUSEquitiesV1 (4502, 0x1196) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 72 e5 57 88 83 32 17` | 2022-12-20 13:30:33.321321000 |
| 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` |  |
| 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. |

#### OrderModifiedUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `87 00` | 135 |
| MessageType | `97 11` | OrderModifiedUSEquitiesV1 (4503, 0x1197) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `f2 fb 09 00` | 654322 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 3c 80 93 88 83 32 17` | 2022-12-20 13:30:34.321321000 |
| 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` |  |
| Symbol | `41 41 50 4c 00 00 00 00` | AAPL |
| Side | `32` | Sell (50, 0x32, '2') |
| Price | `60 7a 60 01 00 00 00 00` | 23.10 |
| OrdType | `32` | Limit (50, 0x32, '2') |
| MaxFloor | `00 00 00 00` | 0 |
| OrderQty | `dc 05 00 00` | 1500 |
| 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 |

#### ModifyRejectedUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `7d 00` | 125 |
| MessageType | `98 11` | ModifyRejectedUSEquitiesV1 (4504, 0x1198) |
| 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.321321000 |
| ClearingFirm | `00 00 00 00` |  |
| 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 |
| 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. |

#### OrderRestatedUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `76 00` | 118 |
| MessageType | `99 11` | OrderRestatedUSEquitiesV1 (4505, 0x1199) |
| 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.321321000 |
| 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` |  |
| Symbol | `41 41 50 4c 00 00 00 00` | AAPL |
| OrderRestatementReason | `57` | Wash (87, 0x57, 'W') |
| OrderQty | `dc 05 00 00` | 1500 |
| Price | `60 7a 60 01 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 | `00 00 00 00 00 00 00 00` | 0.00 |
| CmcMatchQty | `00 00 00 00` | 0 |

#### OrderCancelledUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `2d 00` | 45 |
| MessageType | `9a 11` | OrderCancelledUSEquitiesV1 (4506, 0x119a) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `f4 fb 09 00` | 654324 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 9a 50 46 89 83 32 17` | 2022-12-20 13:30:37.321321000 |
| ClearingFirm | `00 00 00 00` |  |
| 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 |

#### OrderExecutionUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `5d 00` | 93 |
| MessageType | `9c 11` | OrderExecutionUSEquitiesV1 (4508, 0x119c) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `f5 fb 09 00` | 654325 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 2e 86 bd 89 83 32 17` | 2022-12-20 13:30:39.321321000 |
| ClearingFirm | `00 00 00 00` |  |
| 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 | `00 00 00 00 00 00 00 00` | 0.00 |
| 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 | `41 41 50 4c 00 00 00 00` | AAPL |
| FeeCode | `00 00` |  |
| AccessFee | `e3 d7 fd ff ff ff ff ff` | -1.41341 |

#### ResetRiskAcknowledgementUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `1d 00` | 29 |
| MessageType | `9e 11` | ResetRiskAcknowledgementUSEquitiesV1 (4510, 0x119e) |
| 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` |  |

#### PurgeAcknowledgementUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `2c 00` | 44 |
| MessageType | `9f 11` | PurgeAcknowledgementUSEquitiesV1 (4511, 0x119f) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 c2 bb 34 8a 83 32 17` | 2022-12-20 13:30:41.321321000 |
| 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 |

#### PurgeRejectedUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `65 00` | 101 |
| MessageType | `a0 11` | PurgeRejectedUSEquitiesV1 (4512, 0x11a0) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 8c 56 70 8a 83 32 17` | 2022-12-20 13:30:42.321321000 |
| 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. |

#### TradeCancelCorrectUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `68 00` | 104 |
| MessageType | `9d 11` | TradeCancelCorrectUSEquitiesV1 (4509, 0x119d) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `f6 fb 09 00` | 654326 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 f8 20 f9 89 83 32 17` | 2022-12-20 13:30:40.321321000 |
| 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 | `00 00 00 00 00 00 00 00` | 0.00 |
| CorrectedPrice | `00 00 00 00 00 00 00 00` | 0.00 |
| OrigTime | `00 00 00 00 00 00 00 00` | 1970-01-01 00:00:00.000000000 |
| Symbol | `41 41 50 4c 00 00 00 00` | AAPL |
| Capacity | `41` | NotSet (0, 0x00) |

### Cboe to Member

#### OrderAcknowledgementUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `5c 00` | 92 |
| MessageType | `95 11` | OrderAcknowledgementUSEquitiesV1 (4501, 0x1195) |
| 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.321321000 |
| 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 | `60 7a 60 01 00 00 00 00` | 23.10 |
| OrdType | `32` | Limit (50, 0x32, '2') |
| Symbol | `41 41 50 4c 00 00 00 00` | AAPL |
| 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) |

#### OrderRejectedUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `69 00` | 105 |
| MessageType | `96 11` | OrderRejectedUSEquitiesV1 (4502, 0x1196) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 72 e5 57 88 83 32 17` | 2022-12-20 13:30:33.321321000 |
| 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` |  |
| 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. |

#### OrderModifiedUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `87 00` | 135 |
| MessageType | `97 11` | OrderModifiedUSEquitiesV1 (4503, 0x1197) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `f2 fb 09 00` | 654322 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 3c 80 93 88 83 32 17` | 2022-12-20 13:30:34.321321000 |
| 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` |  |
| Symbol | `41 41 50 4c 00 00 00 00` | AAPL |
| Side | `32` | Sell (50, 0x32, '2') |
| Price | `60 7a 60 01 00 00 00 00` | 23.10 |
| OrdType | `32` | Limit (50, 0x32, '2') |
| MaxFloor | `00 00 00 00` | 0 |
| OrderQty | `dc 05 00 00` | 1500 |
| 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 |

#### ModifyRejectedUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `7d 00` | 125 |
| MessageType | `98 11` | ModifyRejectedUSEquitiesV1 (4504, 0x1198) |
| 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.321321000 |
| ClearingFirm | `00 00 00 00` |  |
| 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 |
| 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. |

#### OrderRestatedUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `76 00` | 118 |
| MessageType | `99 11` | OrderRestatedUSEquitiesV1 (4505, 0x1199) |
| 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.321321000 |
| 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` |  |
| Symbol | `41 41 50 4c 00 00 00 00` | AAPL |
| OrderRestatementReason | `57` | Wash (87, 0x57, 'W') |
| OrderQty | `dc 05 00 00` | 1500 |
| Price | `60 7a 60 01 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 | `00 00 00 00 00 00 00 00` | 0.00 |
| CmcMatchQty | `00 00 00 00` | 0 |

#### OrderCancelledUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `2d 00` | 45 |
| MessageType | `9a 11` | OrderCancelledUSEquitiesV1 (4506, 0x119a) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `f4 fb 09 00` | 654324 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 9a 50 46 89 83 32 17` | 2022-12-20 13:30:37.321321000 |
| ClearingFirm | `00 00 00 00` |  |
| 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 |

#### OrderExecutionUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `5d 00` | 93 |
| MessageType | `9c 11` | OrderExecutionUSEquitiesV1 (4508, 0x119c) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `f5 fb 09 00` | 654325 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 2e 86 bd 89 83 32 17` | 2022-12-20 13:30:39.321321000 |
| ClearingFirm | `00 00 00 00` |  |
| 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 | `00 00 00 00 00 00 00 00` | 0.00 |
| 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 | `41 41 50 4c 00 00 00 00` | AAPL |
| FeeCode | `00 00` |  |
| AccessFee | `e3 d7 fd ff ff ff ff ff` | -1.41341 |

#### ResetRiskAcknowledgementUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `1d 00` | 29 |
| MessageType | `9e 11` | ResetRiskAcknowledgementUSEquitiesV1 (4510, 0x119e) |
| 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` |  |

#### PurgeAcknowledgementUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `2c 00` | 44 |
| MessageType | `9f 11` | PurgeAcknowledgementUSEquitiesV1 (4511, 0x119f) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 c2 bb 34 8a 83 32 17` | 2022-12-20 13:30:41.321321000 |
| 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 |

#### PurgeRejectedUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `65 00` | 101 |
| MessageType | `a0 11` | PurgeRejectedUSEquitiesV1 (4512, 0x11a0) |
| MatchingUnit | `00` | 0 |
| Reserved | `00` | 0 |
| SequenceNumber | `00 00 00 00` | 0 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 8c 56 70 8a 83 32 17` | 2022-12-20 13:30:42.321321000 |
| 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. |

#### TradeCancelCorrectUSEquitiesV1

| Field | Hexadecimal | Description |
|---|---|---|
| StartOfMessage | `b0 e3` | BOE3 (58288, 0xe3b0) |
| MessageLength | `68 00` | 104 |
| MessageType | `9d 11` | TradeCancelCorrectUSEquitiesV1 (4509, 0x119d) |
| MatchingUnit | `01` | 1 |
| Reserved | `00` | 0 |
| SequenceNumber | `f6 fb 09 00` | 654326 |
| InFlight | `00 00` | 0 |
| TransactionTime | `28 f8 20 f9 89 83 32 17` | 2022-12-20 13:30:40.321321000 |
| 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 | `00 00 00 00 00 00 00 00` | 0.00 |
| CorrectedPrice | `00 00 00 00 00 00 00 00` | 0.00 |
| OrigTime | `00 00 00 00 00 00 00 00` | 1970-01-01 00:00:00.000000000 |
| Symbol | `41 41 50 4c 00 00 00 00` | AAPL |
| Capacity | `41` | NotSet (0, 0x00) |

## Appendix B: Login Playbook

### Login Message Flow

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

**Table 1. Login Message Flow**

| 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

"Request replay of everything that you missed"

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

**Table 1. Recommended Login**

| Field Name | Value | Comment |
|---|---|---|
| StartOfMessage | BO E3 |  |
| MessageLength | 1E 00 | 30 |
| MessageType | 01 00 | 1 (login request) |
| MatchingUnit | 00 |  |
| Reserved | 00 |  |
| SequenceNumber | 00 |  |
| 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 | 02 | There are 2 rows in the array below, representing the 2 system matching units. |
| →UnitNumber | 01 | Matching unit #1 |
| →UnitSequence | 00 00 00 00 | Last SequenceNumber that participant received with MatchUnit=1. Zero if participant 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 participant received with MatchUnit=2. Zero if participant 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 participant 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.

**Table 1. Other Login Strategies**

| Field Name | Value | Comment |
|---|---|---|
| StartOfMessage | BO E3 |  |
| MessageLength | 1E 00 | 30 |
| 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", 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.

**Table 2. Fail Login if Any Units are Unspecified**

| Field Name | Value | Comment |
|---|---|---|
| StartOfMessage | BO E3 |  |
| MessageLength | 1E 00 | 30 |
| 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 | 02 | There are 2 rows in the array below, representing the 2 system matching units. |
| →UnitNumber | 01 | Matching unit #1 |
| →UnitSequence | 00 00 00 00 | Last SequenceNumber that participant received with MatchUnit=1. Zero if participant 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 participant received with MatchUnit=2. Zero if participant has not received anything for MatchUnit=2, for instance as the first login of the day. |

## Revision History

| Version | Date | Description |
|---|---|---|
| 1.0.0 | 10/08/25 | Initial version for publication. |
| 1.0.1 | 11/03/25 | Added AccessFee to List of Message Fields (effective 02/02/26). |
| 1.0.2 | 12/30/25 | Updated RiskReset value U = MPID level lockout reset to F = MPID level lockout reset Updated RoutStrategy in List of Message Fields to remove references to `ROBB` and `ROCO` . Added StepUpAmount to List of Message Fields (effective 1/30/26) |
| 1.0.3 | 01/26/26 | Effective 03/27/26, Cboe will begin populating the nanoseconds portion for the DateTime data type. |
| 1.0.4 | 01/30/26 | Added OrderRestatementReason to List of Message Fields. Updated Nasdaq BX to Nasdaq Texas. Added "Send All Local Rejects" to Port Attributes . |
| 1.0.5 | 03/23/26 | Updated Capacity description to NotSet (0, 0x00) for TradeCancelCorrectUSEquitiesV1 and TradeCancelCorrectUSEquitiesV1Block messages. Removed Trading Sessions table from Hours of Operations and added a link to the trading hours on the Cboe website . Updated SubLiquidityIndicator , ExtExecInst , and PegDifference in List of Message Fields to indicate RPI will apply to BYX and EDGX (effective 04/10/26). |
| 1.0.6 | 04/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 MPID Filter for Purge Ports port attribute to indicate that if 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. Added ContraBroker and ExDestination values for Texas Stock Exchange. |
| 1.0.7 | 04/24/26 | Added section for Dedicated Cores. |
| 1.0.8 | 05/14/26 | Added Reason Code z (session end). Clarified `Modify Order` and ClOrdId behavior in Modify Order Message Fields . |
| 1.0.9 | 05/18/26 | Updated Login Request Message Fields to indicate 0 is the only allowed value for UnitSequence , and removed sentence stating the number of the port's unit as the only UnitNumber accepted. Updated Login Request Message Example . Added footnotes to Default CrossTradeFlag (BYX only) in US Equities BOE Port Attributes . Added multiple message types to List of Message Fields . Added `CancelRejectedUSEquitiesV1` under Cboe to Member in Appendix A: Example Application Messages . In Appendix B: Login Playbook , added ReplayInstruction to Recommended Login and Other Login Strategies . |
| 1.0.10 | 06/30/26 | Pegged orders entered without a Price (44) are only accepted during RTH (effective 12/07/26). Updated TimeInForce language for EDGX 23x5 trading (effective 12/07/26). "Early Trading Session Opt-out" and "Hold Early to 7am" port attributes will be sunset 12/07/26. Added new "Hold Early Orders Until" port attribute (effective 12/07/26). |
| 1.0.11 | 07/06/26 | Added that BOEv3 will exclusively use `Order Restated` message for any MTP activity in Differences with prior versions of BOE . Noted that all MTP related cancels will be sent using an `Order Restated` message with LeavesQty set to zero in Order Restated Message Fields and Order Cancelled Message Fields . Updated LastShares and LastPx description in List of Message Fields . Updated Symbol data type to Text. |
| 1.0.12 | 08/04/26 | Added DisplayIndicator (FIX Tag 9479) value of h = Hidden Multiple Price Slide (effective 09/04/26). |