Cboe Futures Exchange (CFE) Trading Privilege Holders (TPHs) use a subset of the FIX 4.2 protocol for order entry and drop copies. Order entry for both futures instruments and options instruments will be available on the same FIX session. Features only applicable to Options on Futures will be notated with (Options Only).

It is assumed that the reader is familiar with the FIX 4.2 protocol as described at https://www.fixtrading.org. This document describes the differences between the CFE implementation and the FIX 4.2 standard.

Please refer to https://www.cboe.com/us/futures for updates and further information on CFE policies and procedures.

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.

All orders are live upon acceptance by CFE. Orders are rejected if they are received outside the sessions as defined in the associated product contract specifications.

For more information on the CFE Opening Process, please refer to theCboe Titanium Cboe Futures Exchange Opening Process.

CFE trading hours on vary by 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. See the product contract specifications for details on trading hours for each product, which may differ for expiring and non-expiring contracts.

FIX sessions are available for connection on Sunday starting at 10:30 a.m. CT. FIX 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. FIX 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.

All FIX timestamps are GMT as per the FIX standard. TPHs are expected to synchronize their clocks with an external time source.

Price fields (e.g., Price (55), LastPx, (31), StopPx (99), AvgPx (6)) can contain positive, negative and zero values as a result of Spread instrument support. Order prices (e.g., Price (44), StopPx (99)), must comply with product-specific minimum trading price increments as specified in associated product contract specifications.

TPHs should program systems to allow execution prices to be returned with up to four decimals.

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.

Each FIX 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 FIX ports. The Cboe NOC should be contacted in the event that a Member desires to connect from a new source IP range.

Each FIX 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.

Effective 07/13/26:

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 entered during partial holiday sessions can result in orders persisting between sessions. The CFE FIX protocol provides a mechanism for clients to request restatement of orders that have been carried forward from the previous business day trading session. See FIX Order Entry Port Attributes for information on available port attributes, including Carried Order Restatements.

When enabled, Carried Order Restatements are sent to connected clients for each product on the CFE for which orders have been carried forward from the previous business day trading session. Carried Order Restatements are sent approximately 10 minutes before the pre-open period for each product.

Carried Order Restatements are represented using Execution Report messages with the following optional attributes set:

• ExecTransType = 3 (Status)
• ExecType = D (Restated)
• ExecRestatementReason:
  • GTC, GTD: ExecRestatementReason = 1 (GT renewal)
  • Day: ExecRestatementReason = 4 (Day order restatement)

To receive Carried Order Restatements, the Carried Order Restatement port attribute must be set (contact CFE Trade Desk). Since the Carried Order Restatement Execution Report messages are delivered to the session handler before the TPH connects, the MsgSeqNum (34) field of the Logon Message received by the TPH reflects the number of Carried Order Restatements that are available to retrieve by using a subsequent Resend Request message.

Note that no notification is provided at the end of a trading session to indicate when GTC, GTD, or Day orders on partial holiday sessions are persisted to carry over to the next trading sessions. Instead, Carried Order Restatements can be used by members to be notified of orders 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 is limited to three GTC/GTD orders per session per matching unit, for a total of six GTC/GTD orders per session.

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.

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

Execution prices of TAS trades will 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 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 will be resolved by updating the execution price and changing the symbol to the associated futures contract. TAS trades will be cleared as regular futures contract (i.e. VX) trades.

Trades executed intraday are acknowledged back to participants using standard Execution Report messages. The first Execution Report message received in these products is considered a Pending trade. CFE follows up each initial (i.e., pending) TAS execution with post-settlement Execution Report messages with the following field values:

• ExecTransType = 2 (Correct)
• ExecType = D (Restated)

In addition, custom fields are added to the follow-up Execution Report messages (see Custom FIX Fields). The following summarizes the restatement details for each product:

TAS trades will be 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 respectively. The symbol with which the TAS execution will clear (i.e., the VX symbol with the equivalent expiration as the as-executed VXT symbol) will be contained in the ClearingSymbol (21053) field. The price with which the TAS execution will clear (i.e., the as-executed price from the LastPx field offset by the settlement price of the associated VX contract) will be contained in the ClearingPrice (21050) field.

Post-execution restatement Execution Report messages associated with orders originally submitted with TimeInForce (59) = 4 (FOK) will contain TimeInForce = 3 (IOC) rather than the originally specified 4 value.

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 ratios of each leg is one, which means one unit of the spread contract is equivalent to selling 1 unit of the first expiration and buying one unit of the second expiration.

The bold two leg spread - 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 simplest two leg spread VX1:VX2 comprising selling one unit of the VX1 contract and buying one unit of the VX2 contract. To illustrate how buyers can get paid and sellers can pay, we examine spread pricing in Contango and Backwardated price environments.

Figure 1 below 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 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. Figure 2 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 it is 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).

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

The exchange limits the Maximum number of open orders allowed on a FIX port to 100,000 per port. New orders will be rejected once this limit is breached until the number of open orders drops back below 100,000.

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

FIX messages are ASCII formatted. The TPH will be provided with a SenderCompID and SenderSubId that must be sent on every message. The TargetCompID for all messages the TPH sends will be CFE. All messages the TPH receives will have the Sender and Target fields swapped.

FIX Tags not defined in this specification will be ignored and will not be returned on Execution Reports back to the TPH.

Sequence numbers, both inbound and outbound, will be reset to one daily between 4:00 p.m. CT and 4:45 p.m. CT. Existing FIX connections will be forcibly disconnected at that time each day.

Messages are processed in sequence order. Behind sequence messages (other than Sequence Reset) cause immediate logout. Ahead of sequence messages (other than a Resend Request) trigger a message recovery via a Resend Request.

CFE uses the FIX 4.2 session protocol.

The following session messages are supported in both directions:

For information on connectivity options to CFE, refer to the Cboe Titanium Cboe Futures Exchange Connectivity Manual.

Logon must be the first message sent by the TPH after the TCP connection is established. EncryptMethod is ignored (FIX level encryption is not supported).

CFE will wait one second after a Logon is received to ensure that no Resend Request messages are in flight from the TPH. A Heartbeat will be sent to indicate that the one second wait period has ended. TPHs should not send any orders prior to receiving this first Heartbeat from CFE.

The IP Address of the TPH, the SenderCompID, SenderSubID, TargetCompID, and TargetSubID ( TEST/PROD) will be validated. If validation fails the connection will be dropped without a reject (to avoid corrupting the TPHs sequence in the case that the TPH merely mistakenly connected to the wrong port).

If connection is unexpectedly broken, upon reconnection the TPH may receive a login reply with a sequence number greater than expected. This means that in-flight messages were missed (likely important execution reports). The TPH should issue a Resend Request to retrieve the missed messages.

Similarly CFE will issue a Resend Request to the TPH for messages that it missed. The TPH may wish to send gap fill messages in place of new orders to avoid re-submission of potentially stale orders.

HeartbeatInterval must be specified by the TPH in the Logon message. This value will be clamped between five and 300 seconds and returned in the logon reply message. We recommend using as low a value as the reliability and latency of your telecommunications channel will allow.

If the Carried Order Restatements port attribute is set, unsolicited Execution Report messages representing carried orders loaded by the system at startup will be sent after the Logon response. Carried orders are orders that persist across a trading segment. Trading segments are delimited by periods of time in which the exchange is closed for trading. Good ‘til Cancel (GTC), Good ‘til Date-Time, and Day orders persisting across holiday trading segments comprising a single business date are the only order types that will appear in Carried Order Restatements.

Carried GTC, GTD, and Day orders that span holiday trading segments within a single Business day will use ExecTransType= 3 (status), ExecType= D (Restated) and ExecRestatementReason= 1 (GT renewal / restatement) for GTC and GTD orders and 4 for Day orders.

A Heartbeat message should be sent if the agreed upon HeartbeatInterval has elapsed since the last message sent. If any message has been sent during the preceding HeartbeatInterval a Heartbeat message need not be sent.

If a HearbeatInterval + one seconds have elapsed since the last message received, a Test Request should be issued. If another HearbeatInterval + one seconds go by without receiving a message the TCP connection should be dropped. This ensures that a broken TCP connection will be detected even if the TCP stack doesn't notice (this has been observed to happen in WAN environments, particularly when a VPN is involved).

A Resend Request message should be processed even if it is received ahead of sequence. Only after resending the requested range (all marked PossDup= Y, including any gap fills) should Resend Request be issued in the opposite direction.

As discussed in the FIX 4.2 specification, it is possible to send an open or closed sequence range in a Resend Request (an open range uses sequence zero as the EndSeqNo). CFE will honor either type of request, but will always issue Resend Requests with a closed sequence range.

Session level rejects are used to indicate violations of the session protocol, or missing (or bogus) fields. These are to be expected during development and certification, while the TPH is being adapted for CFE, but should be extremely rare in production. Application layer rejects (like Order Reject and Cancel Reject) are normal.

Either side may issue a Logout to gracefully close the session. The side that issues the logout should process messages normally until it sees the logout reply, and then break the TCP connection. CFE will typically only request Logout after the scheduled end of FIX session.

This includes the pausing of a session due to holidays.

The following FIX fields in the user defined tag range 5,000-9,999 are used by CFE:

The following FIX fields in the custom tag range 20,000-39,999 are used by CFE:

Order Protocol - TPH to CFE contains New Order Single, Order Cancel Request, Order Cancel/Replace Request, and Security Definition Request (Options only) information.

Request the cancellation of a single order or multiple orders (Mass Cancel) on the FIX session. Note that Order Cancel Requests do not apply to open orders across multiple sessions unless submitted on a Purge Port.

The system limits the rate at which identical Mass Cancel 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.

Price, OrderQty, OrdType, StopPx, ManualOrderIndicator, OEOID, CustOrderHandlingInst, and FrequentTraderID may be adjusted. 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 cancel/replace 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.

Other fields will be ignored, and the value from the original order will be reused.

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 replace request overlaps partial fills for the current order, leaving the TPH in total control of the exposure of the order.

A Cancel/Replace should not be issued until the ack for the previous Cancel/Replace has been received for that order (or the New Order Ack for the first Cancel/Replace). The FIX handler will reject a new Cancel/Replace if it has not seen the prior Cancel/Replace return from the Matching Engine.

Cancel/Replace requests that merely reduce OrderQty may be overlapped if the existing ClOrdID is re-used. This is the only case where re-use of the existing ClOrdID is allowed.

A maximum of 1,679,615 Cancel/Replace 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 an Order Cancel Request.

A Security Definition Request 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 Security Definition message with the Cboe symbol in Symbol (55). 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 Protocol - CFE to TPH contains Execution Report, Cancel Reject, Trade Cancel/Correct, and Security Definition (Options only) information.

Please note that Execution Reports with ExecType (150) = M are responses to Mass Cancel requests. Mass Cancel Execution Reports are compact and will only carry fields as stated in the description of ExecType that follows.

The MultilegReportingType (442) field can be used to determine whether a fill or partial fill corresponds to a Spread instrument, a Single leg instrument that is part of a Spread instrument execution or a Single leg instrument fill only (field will not be present in this case). Similarly, the SecondaryExecID (527) field can be used to distinguish Single leg instrument executions from Spread instrument executions and to identify Single leg instrument executions that comprise a Spread instrument execution.

• If the SecondaryExecId (527) field is not present, the Execution Report is associated with a Simple instrument.
• If the SecondaryExecId (527) field is present and is identical to the ExecId (17) field, the Execution Report represents a Spread instrument execution for which associate individual leg Execution Reports will follow.
• If the SecondaryExecId (527) field is present and not identical to the ExecId (17) field, the Execution Report represents a Simple instrument execution that comprises a Spread execution and the SecondaryExecId (527) field is set to the ExecId (17) field of the associated Spread execution.

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.

Rejects a Cancel or Cancel/Replace request.

When a Cancel/Replace is rejected, by default the original order is left alive. A Cancel Reject should not be used as a sign that the original order has been cancelled. Even if the CancelOrigOnReject = Y option is being used a separate unsolicited cancel will be sent to close out the original order.

Sends a trade/cancel or correct message for trade breaks and adjustments.

Trade Cancel/Correct (UCC) is an optional message that must be enabled at the port level. It may be enabled for current-day only or for all cancels and corrections. Only the Price of a trade may be corrected, all other details remain the same. Trade cancels and corrections do not alter live order state.

This message is a response to a Security Definition Request where the Security Definition Request is accepted or rejected.

A Purge Port may be created using either the FIX or BOE protocol. For BOE Purge Port messaging please refer to the Cboe Titanium Cboe Futures Exchange BOE Version 3 Specification.

The system limits the rate at which identical Mass Cancel 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 the cancellation of a subset (or all) open orders across multiple logical ports/sessions (i.e. match capacity allocations).

This differs from a Mass Cancel sent via an Order Cancel Request as the Purge Request is applied across all the TPH’s sessions, not just the session on which the Order Cancel Request was received. In addition, the Purge Request message optionally accepts a list of one or more CustomGroupID (7699) values as part of the order matching filter.

• Purge Request requires sending MassCancelInst (7700).
• Optionally, OnBehalfOfCompID (115), Symbol (55), MassCancelID (7695) and list of CustomGroupID (7699) values may also be sent.
• Symbol (55) and CustomGroupID (7699) are mutually exclusive. Messages containing both will be rejected.
• A maximum of 10 CustomGroupID (7699) values may be sent in one message.
• If cancelling by OnBehalfOfCompID (115) by using F as the first character of MassCancelInst (7700) in combination with one or more CustomGroupId (7699), only orders entered matching both CustomerGroupId (7699) and the EFID will be cancelled.
• A Purge Acknowledgement (35= 8, 150= M) may be requested by setting the Acknowledgement Style to S or B, in which case the MassCancelID (7695) field must be provided or the Purge Request will be rejected.

  Tag		Field Name	Req’d	Description
  35		Standard Message Header	Y	MsgType=‘F’
  97		PossResend	N	Y = Indicates an application level unsolicited resend. If ClOrdID has not yet been seen, the cancel is treated as normal. If ClOrdID already exists, the resent cancel is ignored. N = (default) indicates a new cancel.
  60		TransactTime	Y	Time cancel initiated/released. Required by FIX 4.2.
  7700		MassCancelInst	Y	At least one character must be provided (Clearing Firm Filter). Contiguous characters must be specified up to total length. Truncated/unspecified characters will default to values indicated (Default) below. 1st Character : Clearing Firm Filter A = No filtering by clearing firm relationship is performed. F = All orders sent under the clearing relationship specified in OnBehalfOfCompId (115) will be cancelled. 2nd Character : Acknowledgement Style M = (Default) Individual Execution Reports are sent for each cancelled order. S = Single summary Execution Report sent once all cancels have been processed. Single Execution Report will contain MassCancelId (7695) and CancelledOrderCount (7696). MassCancelId (7695) must be specified or the Order Cancel Request will be rejected. B = Both individual Execution Reports and single summary Execution report. Also requires MassCancelId (7695) to be specified. 3rd Character : Lockout Instruction N = (Default) No lockout L = Lockout until corresponding Risk Reset received. Lockout can be used only with Clearing Firm Filter set to ‘F’, otherwise the Order Cancel Request will be rejected. Lockout will apply to all new orders and cancel/replace orders for the EFID (and Symbol (55) or CustomGroupId (7699), if specified), regardless of other filtering in the MassCancelInst. 4th Character : Instrument Type Filter B = (Default) Cancel both Simple and Spread orders S = Cancel Simple orders only C = Cancel Spread orders only 5th Character : GTC Order Filter C = (Default) Cancel GTC and GTD orders P = Don’t cancel (preserve) GTC and GTD orders 6th Character : Security Type F = (D) Cancel orders (Futures only) O = Cancel orders (Options only) A = Cancel Both Futures and Options orders If Symbol (55) is specified, it must contain a valid product symbol (e.g., ‘VX’), in which case only orders associated with the specified product will be cancelled. A self-imposed lockout can be released using the RiskReset (7692) field of the New Order Single message. If Symbol (55) is not specified a zero CustomGroupId (7699) values are specified, a Firm level reset is required. If Symbol is specified, a Product level reset is required. If one or more CustomGroupId values are provided a Custom Group level reset is required. For more information, refer to the CFE Risk Management Specification.
  7695		MassCancelID	N	This field will be echoed back in the resulting order execution report when the Acknowledgement Style value of the MassCancelInst (7700) = S or ‘B’. Purge requests containing a MassCancelID that is currently outstanding will be rejected.
  55		Symbol	N	Futures product symbol (upper case). Limits cancellations to only orders with the specified product.
  7698 Repeating Group		CustomGroupIDCnt	N	Number of repeating CustomGroupIDs (7699) included in this message. Integer 0-10
  ➔	7699	CustomGroupID	N	CustomGroupID (7699) to cancel. Only present if CustomGroupIDCnt (7698) is non-zero. Number of repeating groups must match number specified in CustomGroupIDCnt (7698).
  1028		ManualOrderIndicator	Y	Y = Manual order entry N = Automated order entry
  25004		OEOID	Y	Identifies the Order Entry Operator responsible for this message. Minimum and maximum length is 3 and 18 characters, respectively. Characters in ASCII range 33-126 are allowed, except for comma, semicolon, and pipe.
  		Standard Message Trailer	Y

Purge Port Protocol - CFE to TPH contains Purge Acknowledgement and Purge Reject information.

A response to a Purge Request will only be sent when the MassCancelID (7695) is populated on a Purge Request. This includes cases where the Acknowledgement Style of MassCancelInst = S or B.

Rejects a Purge Request.

Open orders for a TPH will be cancelled automatically if no messages have been received from the TPH for two heartbeat intervals. The set of open orders cancelled will include Good 'Til Cancel (GTC) and Good 'Til Date-Time (GTD) orders if the Cancel On Disconnect port setting is configured to include GTC and GTD orders. This is done to prevent orders from being stuck in an unknown state in the event of telecommunications failure. TPHs should choose their heartbeat interval carefully based on the latency and reliability of their telecommunications channel. The minimum supported interval is 5 seconds, and this is also the recommended interval if the latency and reliability of your telecommunications channel support it. Execution reports for the automatically cancelled orders are available upon reconnection. TPHs are responsible for rerouting orders to other market centers based on their business needs. This should be rare, but all open orders may also be cancelled in the event of a complete or partial system malfunction.

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.

Service Bureaus require special configuration. OnBehalfOfCompID should be set for New Order, Order Cancel and Cancel/Replace messages sent to CFE. Orders with an unknown OnBehalfOfCompID will be rejected. ClOrdId values are required to be unique only within a given OnBehalfOfCompID.

Execution Report and Cancel Reject messages sent by CFE will have the DeliverToCompID set.

Orders must be cancelled or replaced using the same OnBehalfOfCompID as was sent on the Order.

CFE uses FIX 4.2 as specified by the FPL document Version 4.2 (with Errata 20010501) with business level extensions described in our own FIX spec. The session level of the FPL spec is followed as closely as possible.

The version with errata cleared up many ambiguities with session level present in the earlier Version 4.2 (March 1, 2000).

Important notes direct from the public FPL spec (bold is emphasis/notes added by CFE):

The FIX protocol assumes complete ordered delivery of messages between parties. Implementers should consider this when designing message gap fill processes. Two options exist for dealing with gaps, either request all messages subsequent to the last message received or ask for the specific message missed while maintaining an ordered list of all newer messages. For example, if the receiver misses the second of five messages, the application could ignore messages 3 through 5 and generate a resend request for messages 2 through 5, or, preferably 2 through 0 (where 0 represents infinity). Another option would involve saving messages 3 through 5 and resending only message 2. In both cases, messages 3 through 5 should not be processed before message 2.

After the initiator has been authenticated, the acceptor will respond immediately with a confirming Logon message.

When the incoming sequence number does not match the expected number corrective processing is required. Note that the SeqReset-Reset message (CFE: this refers only to GapFillFlag=No 123=N) to be used only to recover from a disaster scenario vs. normal resend request processing) is an exception to this rule as it should be processed without regards to its MsgSeqNum. If the incoming message has a sequence number less than expected and the PossDupFlag is not set, it indicates a serious error. It is strongly recommended that the session be terminated and manual intervention be initiated. If the incoming sequence number is greater than expected, it indicates that messages were missed and retransmission of the messages is requested via the Resend Request (see Ordered Message Processing).

If there are consecutive administrative messages to be resent, it is suggested that only one SeqReset-GapFill message be sent in their place. The sequence number of the SeqReset-GapFill message is the next expected outbound sequence number. The NewSeqNo field of the GapFill message contains the sequence number of the highest administrative message in this group plus 1. For example, during a Resend operation there are 7 sequential administrative messages waiting to be resent. They start with sequence number 9 and end with sequence number 15. Instead of transmitting 7 Gap Fill messages (which is perfectly legal, but not network friendly), a SeqResetGapFill message may be sent. The sequence number of the Gap Fill message is set to 9 because the remote side is expecting that as the next sequence number. The NewSeqNo field of the GapFill message contains the number 16, because that will be the sequence number of the next message to be transmitted.

Sequence number checking is a vital part of FIX session management. However, a discrepancy in the sequence number stream is handled differently for certain classes of FIX messages. The table below lists the actions to be taken when the incoming sequence number is greater than the expected incoming sequence number.

NOTE: In *ALL* cases except the Sequence Reset - Reset message, the FIX session should be terminated if the incoming sequence number is less than expected and the PossDupFlag is not set. A Logout message with some descriptive text should be sent to the other side before closing the session.

....

Note: the sending application may wish to consider the message type when resending messages; e.g. if a new order is in the resend series and a significant time period has elapsed since its original inception, the sender may not wish to retransmit the order given the potential for changed market conditions. (The Sequence Reset-GapFill message is used to skip messages that a sender does not wish to resend.)

The sequence reset message is used by the sending application to reset the incoming sequence number on the opposing side. This message has two modes: Sequence Reset-Gap Fill when GapFillFlag is Y and Sequence Reset-Reset when GapFillFlag is N or not present. The Sequence Reset-Reset mode should ONLY be used to recover from a disaster situation which cannot be otherwise recovered via Gap Fill mode. The sequence reset message can be used in the following situations:

• During normal resend processing, the sending application may choose not to send a message (e.g. an aged order). The Sequence Reset - Gap Fill is used to mark the place of that message.

• During normal resend processing, a number of administrative messages are not resent, the Sequence Reset - Gap Fill message is used to fill the sequence gap created.

...

The sending application will initiate the sequence reset. The message in all situations specifies NewSeqNo to reset as the value of the next sequence number immediately following the messages and/or sequence numbers being skipped.

...

If GapFillFlag is present (and equal to Y), the MsgSeqNum should conform to standard message sequencing rules (i.e. the MsgSeqNum of the Sequence Reset-GapFill message should represent the beginning MsgSeqNum in the GapFill range because the remote side is expecting that next message).

The sequence reset can only increase the sequence number. If a sequence reset is received attempting to decrease the next expected sequence number the message should be rejected and treated as a serious error. It is possible to have multiple ResendRequests issued in a row (i.e. 5 to 10 followed by 5 to 11). If sequence number 8, 10, and 11 represent application messages while the 5-7 and 9 represent administrative messages, the series of messages as result of the Resend

Request may appear as SeqReset-GapFill with NewSeqNo of 8, message 8, SeqReset-GapFill with NewSeqNo of 10, and message 10. This could then followed by SeqReset-GapFill with NewSeqNo of 8, message 8, SeqReset-GapFill with NewSeqNo of 10, message 10, and message 11. One must be careful to ignore the duplicate SeqReset-GapFill which is attempting to lower the next expected sequence number. This can be detected by checking to see if its MsgSeqNum is less than expected. If so, the SeqReset-GapFill is a duplicate and should be discarded.

CFE offers two types of FIX Drop ports (Standard FIX Drop and Order by Order FIX Drop). Both port types do not accept orders. Their purpose is to provide real time information about order flow. They may be configured to send order flow based on various combinations of information relating to specific TPH firms, clearing EFIDs, and/or sessions. With proper authorization (e.g., clearing relationships), a single FIX Drop session can be used to obtain information about multiple TPHs.

Standard FIX Drop ports only send execution information comprising Execution Report messages for Filled (150= 2), Partially Filled (150= 1) and Restated (150= D) for post-settlement restatement of TAS executions.

Block and ECRP executions are sent over Standard FIX Drop ports.

Order by Order FIX Drop ports are designed to send more than execution information.

All order message types are supported including, but not limited to Acknowledgements (150= 0), Partially Filled (150= 1), Filled (150= 2), Cancelled (150= 4), Replaced (150= 5), Rejected (150= 8), Restated (150= D), Order Cancel Rejects (35= 9) and optionally (if configured at the port level) Trade Breaks (35= UCC). If the Rejects/Cancels are due to incomplete clearing information, they may be unavailable on Order by Order FIX Drop ports.

Reject messages will be sent which originate from a FIX order entry session. However, rejects originating from a BOE order entry session will be suppressed. Block and ECRP executions are not sent over Order by Order FIX Drop ports.

Users of Order by Order FIX Drop must always be prepared to receive new/unknown FIX tag and FIX tag values for BOE/FIX ports being monitored. CFE reserves the right to add new FIX tags and to update values distributed on Order by Order FIX Drop with no notice.

Execution Report messages sent on FIX and Order By Order Drop ports will always contain both Expiration and Mapped Symbology. For Expiration Symbology, Symbol (55) contains the product identifier (e.g., VX) and MaturityMonth (200) and MaturityDay (205) specify the expiration date of the associated symbol. For Mapped Symbology, SecurityID (48) will contain the 6 character mapped symbol representation. It should be noted that Expiration Symbology is insufficient to uniquely identify the traded instrument in the case of Spread instrument executions.

Unless specified, both types of FIX Drop ports can be configured with the following features:

The table below lists FIX order entry port attributes that are configurable on the port or firm level. Changes to these attributes can be made by submitting a request through the Logical Port Request form.

^† Port attribute can be overridden via FIX on an order by order basis.

^{^} Requires certification.

The following is a list of all reason codes used by CFE. These reason codes are used in a variety of contexts (order cancellations, order rejections, etc.). 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. CFE may add additional reason codes without notice. Members must gracefully ignore unknown values.

For more information on CFE Opening Process, please refer to the Cboe Titanium Cboe Futures Exchange Opening Process.

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