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

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

BOEv3 fulfills the following requirements:

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

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

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

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

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

All communication is via standard TCP/IP.

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

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

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

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

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

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

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

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

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

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

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

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

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.

Refer to the website for the CFE Hours and Holidays.

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The following table describes the CFE symbol distribution across units.

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

Minimum Price Checks:

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

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

Maximum Price Checks:

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

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

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

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

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

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

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

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

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

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

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

Unsequenced messages will not be included during replay.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

New Order messages sent from TPH to CFE.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Time priority is maintained on a replacement quote in the following cases:
  • A decrease in OrderQty with no other changes
  • A decrease in OrderQty, a change to the OEOID and/or the ManualOrderIndicator, and no other changes.

    Product Type	Zero Size	Zero Price	SizeModifier	Result
    Trade At Settlement ("TAS")	Y	Y	0	Quote is cancelled
    	Y	N	0	Quote is cancelled
    	N	Y	0	Quote price updated
    	Y	Y	R	Quote price updated
    	Y	N	R	Quote price updated
    	N	Y	R	Quote size and price updated
    Standard (non-TAS)	Y	Y	0	Quote is cancelled
    	Y	N	0	Quote is cancelled
    	N	Y	0	Quote is cancelled
    	Y	Y	R	Quote is cancelled
    	Y	N	R	Quote price updated
    	N	Y	R	Quote is cancelled

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Order Cancelled messages indicates an order has been cancelled.

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

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.

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

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

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

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

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

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

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

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.