# Cboe Titanium U.S. Options Risk Management Specification

Version 1.7.4 · August 10, 2026

## Introduction

Cboe Titanium U.S. Options Risk Management has been designed to assist BZX Options, Cboe Options (C1), C2 Options, and EDGX Options customers in managing the risk of over-executing. Customers can design a risk profile that defines execution limits as a function of time or absolute limits. These rules can be applied to unique EFID Group Level, EFID Level and Risk Root (Symbol) (see Risk Limit Types). When these limits are reached, additional executions will be prevented, outstanding orders/quotes will be cancelled, new orders/quotes rejected, and customers can control when they are willing to trade again. Risk profiles will apply to both single leg and complex orders/quotes. For information on how risk will be applied on complex orders, see the Cboe Titanium U.S. Options Complex Book Process. Risk Management will not be applied to floor-routed orders on the C1 Exchange.

### Risk Type Levels

#### Risk Root (Symbol) Level

Symbol-level rules are based on the Risk Root. The Risk Root is defined as the underlying symbol.

All Risk Limit Types except Rate Based Risk Trips and Absolute Risk Trips are supported at the Risk Root level. A Risk Root level limit can also be thought of as EFID + Risk Root since a single EFID is required to be identified on each Risk Root rule. This is the most specific level available and allows for rules to operate within the Matching Engine process for a given Risk Root. This provides the most control in preventing unwanted over-execution.

For example, a corporate action can result in multiple OSI roots (XYZ, XYZ1, XYZ2) that share the same underlying symbol (XYZ). Only a single Risk Root (symbol) level rule for underlying XYZ is allowed in this scenario.

On C1 only, SPX and SPXW can be configured with separate risk root limits even though they share the same underlying symbol (SPX) due to the fact that those two osi roots exist on separate Matching Engines. Customers are to be advised that a limit in SPX will not immediately apply to SPXW. Customers are recommended to upload separate risk settings for SPX and SPXW options and should note that a trip on either a SPX or SPXW risk root level rule will result in a message being sent to trip the other symbol on a best efforts basis. For example, if a firm trips a rate_count limit on SPX a message will be sent from the SPX Matching Unit to the SPXW Matching Unit and all SPXW orders or quotes will be cancelled on a best-effort basis.

Customers must ensure that executing firm ids (EFID) and the risk roots (option underlying) in risk rule specifications are aligned with respect to associated clearinghouse. For example, a risk rule could be specified with an OCC EFID and a risk root corresponding to a CCUS-cleared option. The result of a risk rule configured this way is that the risk rule will never trip. The onus is on the customer to ensure alignment of EFIDs and risk roots with respect to clearinghouse.

#### EFID Level

Risk limits that apply across all symbols are configured by not specifying a Risk Root in a Risk Profile entry. A single EFID risk limit specified with no Risk Root is referred to as an "EFID Level" risk limit.

Consider a "rate count" risk limit that is configured with one EFID and no Risk Root (i.e., EFID Level rate limit). If the specified rate of trades across all symbols for the EFID is exceeded, all orders for the EFID will be canceled in all symbols.

Implementation of EFID and EFID Group Level risk limits requires monitoring across multiple Matching Engines, which occurs in a process outside of a single Matching Engine. As a result, these types of risk limits are best-effort. When an EFID or EFID Group Level risk limit trips, each Matching Engine is notified in a distributed fashion and as a result slight differences in application time at each Matching Engine will occur (i.e., best-effort).

#### EFID Group Level

Combining multiple EFIDs into a group with a defined risk limit specified and with no Risk Root is referred to as an "EFID Group Level" risk limit.

Consider a "rate count" risk limit that is configured with multiple EFIDs and no Risk Root (i.e., EFID Group Level rate limit). If the specified rate of trades across all symbols and across the multiple EFIDs group is exceeded, all orders for all specified EFIDs in the group will be canceled in all symbols.

The only limit types that can be specified at the EFID Group Level are rate-based and absolute risk limits. No other risk limit types may be used at the EFID Group level.

As with EFID Level risk limits, all EFID Group Level trips are best-effort.

### Atomic vs. Best-Effort Limit ​​

Risk limits that are specified with a Risk Root are atomic limits. Since they are specified with a Risk Root they are implemented within the context of a single Matching Engine. As a result, there are no race conditions associated with distributed processing.

Risk limits that are specified without a Risk Root (i.e., EFID Level and EFID Group Level) must consider trading in all options. Distributed processing across Matching Engines is required to determine when to trigger risk trips. For this reason, EFID Level and EFID Group Level risk limits are referred to as best-effort limits.

Customers can opt-in to an optimization that affects best-effort risk limits only. Using the Risk Management application in the Customer Web Portal or the Secure Web API, customers can opt-in to a Risk Limit Control named "Atomic EFID/EFID Group Limits". By default the option is not enabled. Customers must explicitly opt-in to the functionality.

For additional information, see Risk Type Levels and Risk Limit Controls.

### Risk Limit Types

Risk limit rules are defined by specifying an EFID or EFID Group, an optional Risk Root, a risk limit type and the risk limit threshold value. A collection of risk limit rules comprise a "Risk Profile".

When a risk limit rule threshold value is exceeded, trading will stop, open orders/quotes will be canceled and any new orders/quotes received will be rejected for the EFID(s) and Risk Root (if any) associated with the risk limit.

Both the cancel and reject acknowledgments returned to the customer over the order entry session will carry a specific reason code that allows customers to identify whether an EFID Level, EFID Group Level or Risk Root (Symbol) Level or a risk lockout by CustomGroupID has occurred.

.

| Limit Type | Description |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Rate Based Risk Trips (EFID Group Level only) | Risk Trips is computed as the sum of all Rate Based and Absolute Risk Limit Types for Notional, Volume, Count and Percentage of Quote risk trips. For example, if a customer specifies a limit of five Risk Trips per second across EFIDs ABCD and WXYZ, order/quote cancellation and rejection will occur following the fifth risk trip. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Rate Based Notional (Risk Root or EFID Level) | Notional is computed as the sum of the products of premium multiplied by number of contracts with no netting of buy or sell legs in complex instruments applied. Full executions of all contracts for an order/quote will not be avoided to prevent exceeding notional rate limits. For example, if the customer’s notional rate limit is $25 per second and 2 executions occur, one for 5 contracts at $3, and one for 7 contracts at $2, then the notional would be computed as: (5 * $3) + (7 * $2) = $29 Both executions will occur, followed by cancellations of pending orders/quotes and rejects of new orders/quotes. Rate based notional limits are defined by the two parameters notional value and number of milliseconds . Any time the notional value executed exceeds the notional value specified within the specified number of milliseconds, the limit is triggered. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Rate Based Volume (Risk Root or EFID Level) | Volume is computed as the sum of the number of contracts executed. When the total number of contracts executed exceeds the specified value within the specified number of milliseconds, the limit is triggered. Full execution of all contracts for an order/quote will not be avoided to prevent exceeding volume rate limit. For example, if a customer specifies a limit of 20 contracts per second and receives an execution for 10 contracts followed by a second execution for 15 contracts (10 + `15` = 25 contracts) within a single second, both executions will occur followed by cancellations of pending orders/quotes and rejects of new orders/quotes. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Rate Based Count (Risk Root or EFID Level) | Count is computed as the number of executions. Premium and number of contracts have no bearing on this computation. If a customer specified a limit of 10 executions per second, the 10th execution within a single second will trigger the rate limit and prevent additional executions. Cancellations will be issued and rejects of new orders/quotes will occur. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Rate Percentage of Quote (Risk Root or EFID Level) | Percentage of Quote is computed as the sum of the overall percentage of executions as a percentage of order/quote volume outstanding for each order/quote in a particular OSI Risk Root during the specified time period. Note that executions resulting from IOC orders will be included in the Percentage of Quote calculation. For example: An Options Exchange customer specifies a Percentage of Quote limit of 200% with four resting quotes in two different series quoted in a given OSI Risk Root (XYZ) for 100 contracts. Executions are ordered by time and include the aggregated Percentage Of Quote after each execution: Sell 80 XYZ1 - Trades with Quote 1 (Total POQ = 80%) Buy 50 XYZ1 - Trades with Quote 2 (Total POQ = 130%) Sell 60 XYZ2 - Trades with Quote 3 (Total POQ = 190%) Buy 10 XYZ2 - Trades with Quote 4 (Total POQ = 200%) Series Bid Size Offer Size Trade Size POQ Series XYZ1 Order 1 100 80 80% Order 2 100 50 50% Series XYZ2 Order 1 100 60 60% Order 2 100 10 10% 200% The Percentage of Quote is computed as: 80% + 50% + 60% + 10% = 200% | Series | Bid Size | Offer Size | Trade Size | POQ | Series XYZ1 |  |  |  |  | Order 1 | 100 |  | 80 | 80% | Order 2 |  | 100 | 50 | 50% | Series XYZ2 |  |  |  |  | Order 1 | 100 |  | 60 | 60% | Order 2 |  | 100 | 10 | 10% |  |  |  |  | 200% |
| Series | Bid Size | Offer Size | Trade Size | POQ |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Series XYZ1 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Order 1 | 100 |  | 80 | 80% |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Order 2 |  | 100 | 50 | 50% |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Series XYZ2 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Order 1 | 100 |  | 60 | 60% |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Order 2 |  | 100 | 10 | 10% |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|  |  |  |  | 200% |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Absolute Risk Trips (EFID Group Level only) | The absolute Risk Trip behaves similarly to the rate based Risk Trip with the exception that time is not considered. After X risk trips across effective EFIDs has been reached, cancellations will be issued and rejects of new orders/quotes will occur. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Absolute Notional (Risk Root or EFID Level) | The absolute notional behaves similarly to rate based notional limits with the exception that time is not considered. If X dollars in notional have been executed the limit is reached. Cancels are issued and new orders/quotes are rejected until the customer has a chance to assess and decides to reset. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Absolute Volume (Risk Root or EFID Level) | Similar to rate based volume with the exception that time is not considered. If X contracts have been executed, the limit is reached. Cancels are issued and new orders/quotes are rejected until the customer has a chance to assess and decides to reset. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Absolute Count (Risk Root or EFID Level) | The absolute count behaves similarly to rate based count limits with the exception that time is not considered. If X executions have been executed the limit is reached. Cancels are issued and new orders/quotes are rejected until the customer has a chance to assess and decides to reset. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Absolute Percentage of Quote (Risk Root or EFID Level) | The absolute percentage of quote is similar to the rate based percentage of quote with the exception that time is not considered. If Xpercentage has been executed, the limit is reached. Cancels are issued and new orders/quotes are rejected until the customer has a chance to assess and decides to reset. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |

### Risk Limit Controls​​ ​

Firms can optionally set risk limit controls that affect the behavior of risk limits comprising a Risk Profile. Risk limit controls can be configured using the Customer Web Portal Risk Management Application or through the Secure Web API.

Current risk limit controls available to customers are the following:

**Table 1. Risk Limit Controls**

| Risk Limit Control | Description |
|---|---|
| Contra-Capacity Fractions | Firms can specify the proportion of activity to attribute to limit counters by contra-capacity for affected limit types. |
| Exclude Auction Volume | Firms can chose to exclude auction volume from limit counters for affected limit types. |
| Atomic EFID/EFID Group Risk Limits | Firms can opt-in to atomic implementation of best-effort risk limits that result in more timely response to certain risk trips that result from trading activity localized to a single Matching Engine. |

Each of the Risk Limit Controls are described in more detail in the following sections.

#### Contra-Capacity Fractions ​ ​ ​

Firms can optionally specify fractions by contra-capacity, specified as values between and including 0.0 to 1.0. Firms that do not use this functionality are effectively setting contra-capacity fractions to a default value of 1.0.

Contra-capacity fractions specify that a fractional amount of trade volume or count is to be accumulated to the underlying counters based on contra-capacity.

For example, a firm may specify a value of 0.0 to capacity "C" to indicate that any amount of "C" capacity volume or counts will be accepted without tripping risk. Alternatively, a value of 0.5 assigned to capacity "C" indicates that volume or counts will be half as impactful to the risk limits as other capacities.

Contra-capacity fractions only apply to four risk limit types: abs_vol, abs_count, rate_vol and rate_count.

#### Exclude Auction Volume

Firms can optionally specify whether to exclude auction volume from the underlying limit counters for all risk limits of type abs_vol, abs_count, rate_vol and rate_count in a Risk Profile.

Firms that do not use this functionality are effectively configuring risk to include auction volume.

Use of this global risk limit determines whether or not volume associated with AIM, C-AIM, SAM, C-SAM, SUM and COA auctions are considered in the implementation of the affected risk limit types (i.e., abs_vol, abs_count, rate_vol and rate_count).

#### Atomic EFID/EFID Group Limits

Firms can opt-in to specify that EFID Level and EFID Group Level limits (i.e., best-effort limits) be also implemented as atomic limits on every Matching Engine considering only activity on the local matching engine.

The impact of opting in to this functionality is that risk trips resulting from activity on a single Matching Engine will be notified back to firms more quickly for the single Matching Engine. The single Matching Engine risk trip will then result in risk trips on all other Matching Engines as a result of the distributed processing of the best-effort limit.

When selected, "Atomic EFID/EFID Group Limits" causes all best-effort distributed EFID Level and EFID Group Level risk limits to be implemented both as best-effort and atomic limits. The atomic versions of the best-effort limit run in the context of a single Matching Engine. As a result, instead of considering trading in all options, they consider only activity on the local Matching Engine. In scenarios where an EFID or EFID Group Level limit is tripped as a result of trading activity on a single Matching Engine, customers that have opted in to the "Atomic EFID/EFID Group Limit" functionality will experience more timely order cancellation and lockout on the single Matching Engine, which will be followed by distributed processing of the risk trip to other Matching Engines.

The reason for providing firms with the option to use this functionality is that there is a race condition that firms must be prepared for when best-effort limits are also implemented atomically on each Matching Engine. When a risk trip occurs on a single Matching Engine a firm may submit a risk reset before the same trip propagates through the distributed processing, which could result in the risk reset appearing to have not worked properly when the issue was timing. Firms that wish to avoid this complexity and that do not need atomic implementation of best-effort limits may chose not to opt in to this functionality.

### Risk Limit Implementation Details

While risk management functionality is designed for and generally used for protection with regards to posted liquidity, the same risk configurations can impact the activity of removed and/or routed flow.

All Risk Root level risk limits are checked in an atomic way inside each matching engine. As soon as a limit is breached, all resting orders and quotes in all series relating to that Risk Root+EFID will be cancelled immediately.

EFID and EFID Group level risk limits are evaluated in a separate process outside of the Matching Engine. This outside process detects when risk should be tripped and sends a message to all matching engines when a trip occurs. Additional executions may occur while messages are in-transit.

Risk Controls do not affect an in-process series opening, including a SOQ series opening. If a risk trip occurs in the middle of matching contracts within the context of a single series opening, the single series opening match will continue until the series is fully opened. This is true for appointed Market Maker quotes and SLOO orders during the SOQ Opening process, but does not hold true for orders and non-appointed Market Maker quotes. Risk will not be tripped for orders and non-appointed Market Maker quotes until all SOQ constituent series are open. If risk is tripped during the SOQ opening, non-appointed market maker quotes and non-SLOO orders in other non-opened series will be cancelled upon completion of their opening auctions.

The Risk Violation Scenarios table describes some of the different scenarios that may be encountered and should help customers to understand what to expect in the context of risk violations.

**Table 1. Risk Violation Scenarios**

| Execution Type: Matched | Execution Type: Routed |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Rate Based & Absolute Count |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| If a customer specifies a limit of 10 trades, the 11th matched trade will not occur within the specified time interval. | If there are multiple outstanding orders that have been routed away ALL may execute. While Cboe will apply routed executions to your profile, your theoretical limit is equal to the number of matched executions plus open away orders. Example: Suppose your limit is 10 executions per second and you have 8 that have occurred plus 3 open orders that have been routed to an away exchange. If all three execute at the away exchanges, your risk limit will have been reached at 11 executions instead of 10. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Rate Based & Absolute Volume |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Incoming orders/quotes may execute through a resting order/quote’s risk limit if the remaining limit is less than the total quantity of an order. Example: Suppose your limit is 10 contracts while displaying a single quote for 15 contracts on book. An incoming order for 12 contracts executes with 12 of your 15 contracts and the remaining 3 contracts are cancelled back. | Similar to the limits for counts, the theoretical limit is equal to the current execution volume plus open away aggregate order/quote size. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Rate Based & Absolute Notional |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Incoming orders/quotes may execute through your resting order/quote’s risk limit if the remaining limit is less than the total notional value of the order. Example: Suppose your limit is $1,000 per minute and you have currently executed $980. You have a single quote on the book for 3 contracts at $7. If this quote is hit, Cboe will execute all 3 contracts for a total notional executed of $1,001. | Routed executions will always be open to the potential for exceeding your limit by orders that have been routed to an away exchange. Example: Suppose your limit is $1,000 and you have executed $950. Furthermore assume there is $100 in notional open orders that have been routed to an away exchange. You may reach $1,050 before your limit is triggered. |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Rate Based & Absolute Percentage of Quote |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Incoming orders/quotes may execute through your resting order/quote’s risk limit if the remaining limit percentage is less than 100%. Example: Suppose your Percentage Of Quote limit is 200% per second. Four quotes are resting in a given Risk Root (XYZ) with the following quote sizes and executions. Executions are ordered by time along with the aggregated Percentage Of Quote after each execution: Sell 80 XYZ1 - Trades with Quote 1 (POQ = 80%) Buy 50 XYZ1 - Trades with Quote 2 (POQ = 130%) Sell 60 XYZ2 - Trades with Quote 3 (POQ = 190%) Buy 100 XYZ2 - Trades with Quote 4 (POQ = 290%) Series Bid Size Offer Size Trade Size POQ Series XYZ1 Order 1 100 80 80% Order 2 100 50 50% Series XYZ2 Order 1 100 60 60% Order 2 100 100 100% 290% The Percentage of Quote is computed as: 80 + 50% + 60% + 100% = 290% All four trades in the given Risk Root (XYZ) will execute, triggering risk, followed by a cancellation of all open orders/quotes in the given Risk Root and rejecting new orders/quotes within the Risk Root. If there are any order modifications to quantity (up or down) or price, percentage of quote calculations having resulted in executions on the original order/quote will be retained and the modified order/quote will be treated as a new order/quote. Example : An Options Exchange customer specifies a Percentage of Quote limit of 200% with two (2) resting quotes in the given Risk Root (XYZ) for 100 contracts, followed by a modify to Quote 1 to refresh quote size following an execution. Executions are ordered by time and include the aggregated Percentage Of Quote after each execution: Sell 80 XYZ1 - Trades with Quote 1 (POQ = 80%) Buy 50 XYZ1 - Trades with Quote 2 (POQ = 130%) Modify Quote 1 - Increase size back to 100 (POQ = 130%) Sell 100 XYZ1 - Trades with Quote 1B (POQ = 230%) Series XYZ1 Bid Size Offer Size Trade Size POQ Order 1 100 80 80% Order 2 100 50 50% Order 1B 100 100 100% 230% The Percentage of Quote is computed as: 80% + 50% + 100% = 230% | Series | Bid Size | Offer Size | Trade Size | POQ | Series XYZ1 |  |  |  |  | Order 1 | 100 |  | 80 | 80% | Order 2 |  | 100 | 50 | 50% | Series XYZ2 |  |  |  |  | Order 1 | 100 |  | 60 | 60% | Order 2 |  | 100 | 100 | 100% |  |  |  |  | 290% | Series XYZ1 | Bid Size | Offer Size | Trade Size | POQ | Order 1 | 100 |  | 80 | 80% | Order 2 |  | 100 | 50 | 50% | Order 1B | 100 |  | 100 | 100% |  |  |  |  | 230% | Routed executions will always be open to the potential for exceeding your limit by orders that have been routed to an away exchange. Example: Suppose your limit is 200% and you have executed 190% of your percentage of quote. Furthermore assume there is an order for 50 contracts that has been routed to an away exchange. You may exceed your 200% limit if more than 5 out of 50 (10%) contracts are executed at the away exchange. |
| Series | Bid Size | Offer Size | Trade Size | POQ |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Series XYZ1 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Order 1 | 100 |  | 80 | 80% |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Order 2 |  | 100 | 50 | 50% |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Series XYZ2 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Order 1 | 100 |  | 60 | 60% |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Order 2 |  | 100 | 100 | 100% |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|  |  |  |  | 290% |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Series XYZ1 | Bid Size | Offer Size | Trade Size | POQ |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Order 1 | 100 |  | 80 | 80% |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Order 2 |  | 100 | 50 | 50% |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Order 1B | 100 |  | 100 | 100% |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|  |  |  |  | 230% |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |

### Supported Order Types

All order types are supported. Any order or quote of any kind submitted to a Cboe Options Exchange that has been executed either fully or partially will decrement remaining values in a particular risk rule. Trades that occur with the same EFID on both sides are not counted towards any risk limits.

### Risk Limits for Trading Sessions (C1 Only)

Risk limits may be set differently for special trading sessions including, Global Trading Hours (GTH), Curb Trading Hours, and Special Opening Quotation (SOQ). To set risk limits for GTH, Curb, or SOQ, limits must also be uploaded for the default session (all hours). These default session rules will be applied during GTH, Curb, or SOQ periods if explicit GTH, Curb, or SOQ rules are not defined.Rules set up specifically for the GTH, Curb, or SOQ sessions will be effective for that session only. A trip in any session will cause all orders/quotes to be cancelled that match the risk level defined in the rule (EFID Level, EFID Group Level or Risk Root Level).

For more information regarding timing of risk reloads, see Risk Profile Change Timing.

### Certification

Options Exchange customers must certify with the Cboe Trade Desk prior to using these Risk Management features.

### Cancel, Rejects and Resets

When a resting order/quote or inbound order/quote is executed and a Risk Profile limit is reached or when a self-imposed lockout is received, resting orders/quotes are cancelled and inbound orders/quotes are rejected. In both cases the FIX and BOE Text field (58) will carry either a value of:

- `s` = Risk management symbol level
- `+` = Risk management EFID Group level
- `f` = Risk management EFID level
- `f` = Risk management Custom Group ID level

If the Risk Profile limit was reached, the FIX and BOE SubreasonText field (22058) will carry either a value of:

- `f` = Risk management EFID level by rule
- `s` = Risk management symbol level by rule
- `+` = Risk management EFID Group level by rule

If the customer initiated a Mass Cancel or Purge Lockout, the FIX and BOE SubreasonText field (22058) will carry either a value of:

- `A` = Purge/mass cancel EFID level by user
- `B` = Purge/mass cancel symbol level by user
- `C` = Purge/mass cancel Custom Group ID level by user

When this is seen by a customer, it indicates that any order/quote still in flight, and any new orders/quotes issued, will be rejected.

Once a customer has analyzed the situation and decides to commence trading, they may clear the risk trigger or self-imposed lockout by taking one of two actions:

- Either send an order that has a special tag,
- or, if using BOE protocol, send the `Reset Risk` message.

The tag is located in the BOE RiskReset field (7692). This field must be filled with one of the following values:

**Table 1. RiskReset Functionality**

| RiskReset Value | Risk Root Reset | EFID-Level Reset | EFID Group Level Reset | CustomGroupID Reset | Risk Counters Reset |
|---|---|---|---|---|---|
| `S` | Y | N | N | N | Y |
| `F` | N | Y | N | N | Y |
| `SF` | Y | Y | N | N | Y |
| `C` | N | N | N | Y | N |
| `G`* | N | N | Y | N | Y |
| `GS`* | Y | N | Y | N | Y |
| `CS` | Y | N | N | Y | Y |
| `CSF` | Y | Y | N | Y | Y |
| `T` | Y | N | N | N | N |
| `E` | N | Y | N | N | N |

*EFID Group RiskReset = G

When using the single characters the ordering of the characters does not matter. For example, a value of `SF` is identical to a value of `FS`. For more information on the RiskReset field, see Cboe Titanium U.S. Options FIX Specification and Cboe Titanium U.S. Options BOEv3 Specification.

Note that a reset will reset all active rules within the profile for the given Risk Root (Symbol), EFID Level, and EFID Group Level. Individual rules cannot be reset on their own. The following example demonstrates this behavior.

Suppose that a customer has the following three rules in their profile for all contracts on MSFT:

1. 500 contracts per second Rate Based Volume limit
2. 20,000 contracts per minute Rate Based Volume limit
3. $100,000 Absolute Notional limit

Suppose that at a particular instant in time, the current state of the rules is as follows:

1. 400 contracts have been executed in the active second
2. 19,000 contracts have been executed in the active minute
3. $25,000 of notional value has been executed.

Next, an inbound order from another customer is received that triggers an execution for 200 contracts against the customer owning the described Risk Profile. The customer owning the Risk Profile receives cancels for all remaining resting orders/quotes in MSFT and their order handler will receive a cancel with a Text field reason of `s: RiskMgmtSymLevel`.

The customer owning the Risk Profile issues a reset. Once the reset is received, all rules for that symbol/EFID/CustomGroupID are reset. This means that the active state for all three rules is set back to ZERO, including the Absolute Notional rule. The absolute value executed of $25,000 is lost and $100,000 is again available for execution

The single character values `T`, `E`, `D`, and `H` may also be used to clear the exchange or self-imposed lockout. These character values will release the lockout without resetting any counters related to the active risk rules. This may be useful for time based risk rules where the lockout may be released without resetting any risk counters being tracked back to zero.

The following examples demonstrate this behavior. For all examples below, assume firm has set the following risk limits:

1. 5 trades per 10,000ms in AAPL series
2. 100 contracts per 10,000ms in AAPL series

Example 1 - Self Imposed Lockout Initiated and Reset Sent without Counter Reset

- From 10:00:00 to 10:00:05 firm executes 3 trades totaling 50 contracts in AAPL series.
- At 10:00:06 firm sends purge for AAPL with lockout
- At 10:00:07 firm sends risk reset = `T` for AAPL
- Firm is allowed to continue sending quotes/orders.
- At 10:00:08 firm executes 2 trades in AAPL series totaling 30 contracts.

Risk is tripped (rule 1) and all open orders/quotes are cancelled in AAPL series.

Example 2 - Self Imposed Lockout Initiated and Reset Sent with Counter Reset

- From 10:00:00 to 10:00:05 firm executes 3 trades totaling 50 contracts in AAPL series.
- At 10:00:06 firm sends purge for AAPL with lockout
- At 10:00:07 firm sends risk reset = `S` for AAPL
- Firm is allowed to continue sending quotes/orders.
- At 10:00:08 firm executes 2 trades in AAPL series totaling 30 contracts.

Risk is not tripped because counters were reset at 10:00:07.

Example 3 - Risk Tripped and Reset Sent without Counter Reset

- At 10:00:00 firm trips AAPL symbol risk limit
- At 10:00:01 firm sends risk reset = `T` for AAPL

Firm is not reset since counters were not set back to zero and all new orders/quotes continue to be rejected.

Example 3 emphasizes that if risk was tripped causing a lockout and a risk reset is sent without counter reset, the lockout will remain in effect.

If a conflicting value is provided the risk reset with counter reset will take precedence. For example, `ST` will release any lockout and reset any applicable root-level rule counters to zero.

#### Risk Reset Limits

Only one (1) unique risk reset message of a given type (EFID Group, EFID, Risk Root, CustomGroupID, and TargetMatchingUnit) is allowed per 100 milliseconds (ms). Additional resets will be ignored. For example, a customer may reset risk for CustomGroupID = 1 and may not reset risk again for CustomGroupID = 1 until 100ms has elapsed. This restriction is designed to safeguard the trading platform from excessive risk messaging.

### Ports and Profiles

Risk management profiles are associated with Executing Firm IDs (EFIDs) assigned by Cboe. If a customer desires a specific profile for a subset of ports, then it is up to that customer to use the proper value in FIX Tag 115 or BOE ClearingFirm field of their order.

That being said, the flexibility exists to allow for a customer to have two different profiles on a single port, multiple ports on a single profile, or one profile per port. Customers will have to design their profiles and work with the Cboe Trade Desk to activate the proper Executing Firm IDs on the desired ports.

### Self-imposed Order Lockout

Customers may initiate a self-imposed order/quote lockout in conjunction with a mass cancel or purge request for all resting and in-flight orders. Customers who issue mass cancel or purge requests using the MassCancelInst field (7700) may optionally configure a Lockout condition as part of the cancel operation.

A self-imposed order lockout may be issued on a BOE/FIX port at either the EFID (Firm) level or the Risk Root level. Purge Ports support both of these and add the ability to impose a lockout for a CustomGroupID (7699). The self-imposed lockout can be released using the existing RiskReset field in BOE (7692).

### Manual Firm-Level Risk Resets

Customers can optionally configure whether an EFID Group level or EFID level risk trigger can be reset automatically. When Manual Resets are disabled, a customer will not be able to reset EFID Group level or EFID level risk via their FIX or BOE order entry sessions. Attempts to reset EFID Group level or EFID level risk over a FIX or BOE order entry session when sending RiskReset field (7692) containing `F` or `G` will result in a reject with a Text field reason of "A: AutomaticRiskResetsDisabled".

Behavior will be disabled by default which will require a customer to manually reset all EFID Group level or EFID level risk trips by contacting the Cboe Trade Desk (913-815-7001). Changes to this configuration can be submitted through the Logical Port Request Form.

Risk Root-level risk and CustomGroupID resets will be unaffected by this configuration.

## Configuring Risk Profiles

Risk profiles refer to the set of risk rules and risk limit controls that have been specified by a customer.

Customers can use the Risk Management Tool or Secure Web API to specify risk rules and configure risk limit controls.

## Risk Management Tool

To access the Risk Management Tool, customers must first obtain a login to the Customer Web Portal from the Cboe Trade Desk. After logging into the Customer Web Portal, users with appropriate access will be able to select Risk Management in the Cboe Exchange Tools section of the left-side menu.Cboe Exchange Tools: Risk Management

_(Figure)_

The Risk Management Tool enables customers to manage risk rules comprising the firm risk profile, view the EFIDs defined for the firm, and to set Risk Limit Controls that apply across multiple risk rules.

_(Figure: Figure 1. Risk Management Tool)_

See Risk Settings, EFIDs, and Controls for more information on the functionality available to customers in these tabs.

### Risk Settings

Within the Risk Settings tab, customers can perform the following risk management functions:

- Download Risk File – Download a CSV file containing risk rules in-effect for all firm EFIDs or a single firm EFID entered by the Customer.
- Upload Risk File – Upload a CSV file containing risk rule definitions for one or more firm EFIDs. Customers typically use the Download Risk File function, edit the downloaded CSV file and upload the edited file to effect changes to risk rules.
- Clear Risk Rules – Removes all currently configured risk rules defined all firm EFIDs or a single firm EFID entered by the Customer.

Risk Rules files are CSV formatted files where each row of the file represents a risk rule. A risk rule is a fully specified risk limit as specified below:

executing_firm_id, limit_type, risk_root, limit_value, time_limit, efid_level_limit, risk_group_type

- `executing_firm_id` - This field specifies the EFID (or EFIDs) to which the risk setting applies. Note EFIDs are values assigned by Cboe that customer specify on every order submitted to the exchange in the onBehalfOf field of order entry protocol messages. The onBehalfOf EFID specifies the clearing relationship and risk management limits that apply to the order. Specifying more than one EFID per record is only compatible with a Limit Type of rate_trips or abs_trips, and all EFIDs must be included in a single limit using a pipe(|) delimited list.
- `limit_type` – The limit type is one of the following values:
  - rate_trips – rate-based risk trip count limit
  - rate_ntnl – rate-based notional limit
  - rate_vol – rate-based volume limit
  - rate_count – rate-based count limit
  - rate_pctqt – rate-based percentage of quote limit
  - abs_trips – absolute risk trip count limit
  - abs_ntnl – absolute notional limit
  - abs_vol – absolute volume limit
  - abs_count – absolute count limit
  - abs_pctqt – absolute percentage of quote limit
- `risk_root` – Option underlying value to which risk limit applies (e.g., MSFT). The field should be left blank for EFID or EFID Group Level Risk Limits. Customers may optionally define default limits that apply for all underlyings by using an asterisk (*) for the Risk Root. If a Risk Root has one or more non-default limits of any type specified in the customer risk profile, then default limits will not apply to that Risk Root, even if the defined non-default risk root limit type is different than the default Risk Root limit type. For example, if the following risk limits are defined: The default Risk Root rate_count limit will not apply to Risk Roots ABC or XYZ because they have a Risk Root level limit defined. For a rate_count risk limit to be applied to ABC or XYZ, explicit non-default Risk Root limits for each would need to be separately specified. Risk Root is not compatible with a limit type of rate_trips or abs_trips - Risk Root should be left blank if either limit type is specified.
  - BATS, rate_count, *, 10, 1000, F
  - BATS, rate_vol, ABC, 100, 1000, F
  - BATS, rate_pctqt, XYZ, 500, 500, F
- `limit_value` – This value must be an integer value. Floating point values are not accepted. When the limit type is a notional type, this represents whole dollars. When the limit type is a volume type, this represents cumulative contracts traded in a Risk Root. When the limit is a count type, this represents an execution count.
- `time_limit` – This field is ignored when the limit type is an absolute type. For rate types, this represents the number of milliseconds in the measurement window. Values of less than 100 will be treated as 100 milliseconds. In other words, the minimum time frame is 1/10th of a second.
- `efid_level_limit` – This field is optional. If present and the value is "T" then the limit is an EFID Level limit. The Risk Root column should be blank in this case. If this column is present and has a value of "T", and a Risk Root is specified, the limit will be rejected. Conversely, if a Risk Root is left blank and this field is not present or has a value other than T, the EFID level limit will be rejected. Please note that the rate_pctqt and abs_pctqt types are not valid at the Firm level. Please note that that this field will be deprecated at a future date to be announced by the exchange.
- `risk_group_type` – The trading session to which the limit will be applied. This value applies to C1 only. Value is ignored on other options exchange:
  - default – Limit applies to all trading sessions
  - gth – limit applies to GTH trading session only
  - soq – limit applies to Special Opening Quotation opening only
  - curb – limit applies to Curb trading session only.

Multiple risk rules can be specified per Risk Root. For example, a customer may decide that they are comfortable with a notional rate (rate_ntnl) value of $100 per second. However, they are not comfortable with this rate as a sustainable long term rate. The five minute value that a customer is comfortable with may be $5,000 in any five minute window. This rate is substantially lower than $100 per second. This combination of risk rules would allow for a maximum burst execution rate limit while maintaining a longer term limit at a much lower rate. Finally, a customer may decide that, in addition to these two limits, they want to trip risk after 10,000 total executions in order to evaluate conditions before resuming trading. In this case, the customer would configure a third limit of type abs_count with limit value of 10,000.

There is a limit of eight rules per Risk Root and EFID combination. Only one EFID Level rule is allowed per limit type.

### EFIDs

Customers use the EFIDs tab to view the EFIDs currently configured for the firm.

### Controls

Customers use the Controls tab of the Risk Management Tool to set Risk Limit Controls that apply across all limits of affected limit types. See Risk Limit Controls for more information about Risk Limit Control types.

## Secure Web API

Refer to the Risk Management Service section of the Cboe Titanium U.S. Secure Web API for details on the methods used to manage risk rules (referred to as risk rules in the Secure Web API) and to configure risk limit controls.

## Risk Profile Change Timing

For BZX, C2, and EDGX Options, risk profiles must be configured by 9:00 a.m. ET to be effective for the current trading day. Any configuration changes made after that time will take effect the next trading day.

For C1 only, the system will reload and apply new risk configurations at approximately 2:35 a.m., 9:05 a.m. and 4:05 p.m. ET every day. These reloads will reset all risk counters and lockouts for risk root default (*) rules. EFID level risk rules and non-default risk root rules will not be impacted by these reloads, unless the risk rule has been changed since the last reload.

(effective TBD) Reload times of 7:05 a.m. and 3:45 p.m. will be added and the 4:05 p.m. ET reload will be eliminated. The reload and reset behavior will change such that the reload will only reset counters for rules that have been changed by the user. ​

The table below presents the effective time of risk profile configurations uploaded at various time windows during the day.

**Table 1. C1 Risk Upload Deadlines (ET)**

| Upload Time | Effective Time |  |  |  |
|---|---|---|---|---|
| Default | SOQ | Curb | GTH |  |
| 7:45 p.m. - 2:30 a.m. | 2:35 a.m.* | SOQ Opening | Curb Start | 2:35 a.m.* |
| 2:30 a.m. - 9:00 a.m. | 9:05 a.m.* | SOQ Opening | Curb Start | 9:05 a.m.* |
| 9:00 a.m. - 4:00 p.m. | 4:05 p.m. | Next SOQ Opening | Curb Start | GTH Start (next trading date)* |
| 4:00 p.m. - 7:45 p.m. | GTH Start (next trading date) | Next SOQ Opening | Curb Start | GTH Start (next trading date) |

**Table 2. C1 Risk Upload Deadlines (ET) (effective TBD)**

| Upload Time | Effective Time |  |  |  |
|---|---|---|---|---|
| Default | SOQ | Curb | GTH |  |
| 7:45 p.m. - 2:30 a.m. | 2:35 a.m.* | SOQ Opening | Curb Start | 2:35 a.m.* |
| 2:30 a.m. - 7:00 a.m. | 7:05 a.m.* | SOQ Opening | Curb Start | 7:05 a.m.* |
| 7:00 a.m. - 9:00 a.m. | 9:05 a.m.* | SOQ Opening | Curb Start | GTH Start (next trading date)* |
| 9:00 a.m. - 3:40 p.m. | 3:45 p.m. | Next SOQ Opening | Curb Start | GTH Start (next trading date) |
| 3:40 p.m. - 7:45 p.m. | GTH Start | Next SOQ Opening | Curb Start (next trading date) | GTH Start |

(*) Risk rules specified with risk group type default or gth uploaded between 8:15 p.m. and 9:00 a.m. can optionally be specified to apply immediately.

Note that Curb Start may be either 4:00 p.m. ET or 4:15 p.m. ET depending on the product. Multi-list options products begin trading curb at 4:00 p.m. and proprietary options products begin trading curb at 4:15 p.m. ET.

Note that no dates are contained in risk limit files. Risk rules cannot be scheduled for future application beyond the next trading session. Customers can only replace the active profile with a new profile for the next trading session. Once a profile is activated, it stays active permanently until profile changes are made.

## Contact Details

If you have any questions or would like to begin using Risk Management, please contact your account manager or the Cboe Trade Desk.

## Revision History

| Document Version | Date | Description |
|---|---|---|
| 1.0.0 | 10/08/10 | Initial Version 1.0.0. |
| 1.1.0 | 06/28/11 | Added support for Firm level risk checks. Added Limit Netting. |
| 1.1.1 | 08/30/11 | Updated limit type definitions under File Format section for Limit Netting. Updated number of OSI and Firm rules allowed. |
| 1.1.2 | 11/16/11 | Removed support for Limit Netting. Added support for call/put and front/trailing month options to the Risk Management Profile File Format. |
| 1.1.3 | 01/18/12 | Cleaned up the ordering of File Format. |
| 1.1.4 | 03/05/12 | Clarification added to osi_root definition in Section 2.2 File Format. |
| 1.1.5 | 05/08/12 | Corrected cut-off time for Profile uploads to note uploads after 7AM ET will not be applied until the next trading day. Removed references indicating profiles could not be uploaded between 9AM - 4PM ET. Upload support during this timeframe will be made available ( effective 5/11/12) . |
| 1.1.6 | 05/14/12 | Profile uploads will be applicable to current day if received by 9AM ET effective 5/18/12. |
| 1.1.7 | 06/06/12 | Specification updated to reflect that limits will be applied on a best efforts basis vs. a precise basis (effective 6/22/12) . Various formatting updates. |
| 1.1.8 | 10/21/13 | Added support for Percentage of Quote and Self-imposed Order LockOut functionality. Updated to reflect that symbol-level rules are atomic per unit rather than best efforts. |
| 1.1.9 | 12/15/15 | Removed OSI Root spilt over 4 matching units along with call/put and front/trailing level limits. Updated Percentage of Quote functionality. Added support for Manual Firm Level Risk Resets (Effective 01/28/16 in EDGX and 02/04/16 in BZX) |
| 1.2.0 | 02/19/16 | Bats branding/logo changes. |
| 1.2.1 | 06/07/16 | Added functionality for default OSI Root rules effective 06/17/16. |
| 1.2.2 | 08/17/16 | Bats branding/formatting updates. |
| 1.3.0 | 01/27/17 | Added single character RiskReset values and ability to reset by CustomGroupID. |
| 1.3.1 | 07/21/17 | Updated Self-Imposed Lockout section to present the `MassCancelInst` method of specifying mass cancel operations with lockout. |
| 1.4.0 | 09/01/17 | Added support for C2’s transition onto Bats Technology platform. Added Risk Root definition. |
| 1.4.1 | 10/17/17 | Cboe branding/logo changes. |
| 1.4.2 | 01/17/18 | Added default risk rule example. |
| 1.4.3 | 03/21/18 | Updated OSI Root to Underlying symbology for BZX Options (effective 6/25/18) and EDGX (effective 6/11/18) Options. |
| 1.4.4 | 06/06/18 | Updated number of Firm Level rules allowed per EFID. Clarified that IOC order executions will count towards Percentage of Quote calculations. |
| 1.4.5 | 08/21/18 | Updated Risk Root section to indicate that all markets use underlying as the risk root. Updated images to reflect C2 migration to Bats technology. |
| 1.4.6 | 10/8/18 | New method for resetting risk and releasing self-imposed lockout on BOE using ResetRisk message that corresponds with C1 Feature Pack 2 (effective in Certification on 11/9/18, EDGX Production on 1/10/19, and BZX/C2 Production on 1/18/19) |
| 1.4.7 | 10/19/18 | Added support for C1 Feature Pack 1. Available in Certification effective 11/2/18 and in Production effective 11/29/18. |
| 1.5.0 | 11/16/18 | Clarification of Feature Pack 1 items pertaining to EFID Level and EFID Group Level Risk Types. |
| 1.5.1 | 01/15/19 | Clarified risk reset limits. |
| 1.6.0 | 05/02/19 | Corrected Risk Management Profile file format example of fields. Added risk_group_type to allow for risk to be set separately for different trading sessions. Effective on C2 and EDGX with C1 Feature Pack 7 Clarifications added to demonstrate that quotes and orders are treated the same with respect to risk calculations and trips. |
| 1.6.1 | 05/14/19 | Clarified efid_level_limit and added table to Using the Risk Management Profile Tool section. Added Rule Application in Trading Session table. |
| 1.6.2 | 08/14/19 | Format and pagination updates. Removal of effective date notes that have already been implemented. |
| 1.6.3 | 09/17/19 | Described how risk root level limits will work for SPX and SPXW on Cboe Options (C1). Moved Risk Type Levels section to be in front of the Risk Limit Types section. |
| 1.6.4 | 11/12/19 | Added note indicating GTH will be sunset 11/22/19 for C2 and EDGX. Added clarity around SOQ risk rules. |
| 1.6.5 | 04/28/20 | Added note indicating ten (10) unique risk reset messages will be allowed per second effective 5/27/20. |
| 1.6.6 | 05/07/20 | Updated note indicating one (1) unique risk reset message will be allowed per 100ms effective 5/27/20. |
| 1.6.7 | 05/22/20 | Updated Cancel, Rejects and Resets with new values effective 8/3/20 for EDGX and 8/4/20 for BZX, C1, and C2. |
| 1.6.8 | 10/21/20 | Corrected SubReasonText field value for Purge/mass cancel Custom Group ID level by user to 'C'. |
| 1.6.9 | 03/25/21 | Removed residual language about legacy mass cancel. Added `risk_group_type` 'curb' (effective 04/25/22 TBD 02/07/22 TBD 09/27/21 Q3 2021 ). Added note that risk rule profiles for the Curb session will be enabled effective 04/25/22 TBD 02/07/22 TBD 09/27/21 Q3 2021 . Added notes indicating new risk profile upload cutoff for GTH (effective 11/21/21 Q4 2021 ). |
| 1.6.10 | 05/13/21 | Updated Curb session effective date to 04/25/22 TBD 02/07/22 TBD 09/27/21. |
| 1.6.11 | 06/15/21 | Updated extended GTH session effective date to 11/21/21. |
| 1.6.12 | 07/23/21 | Updated the Customer Web Portal link, screenshot in Section 2.4, and Rule Application in Trading Session table. |
| 1.6.13 | 08/24/21 | Updated Curb session effective date to 04/25/22 TBD 02/07/22 TBD. |
| 1.6.14 | 11/04/21 | Updated links to technical specifications. Updated effective date for Curb session to 04/25/22 TBD 02/07/22 . |
| 1.6.15 | 12/22/21 | Removed old GTH session effective dates. Updated description in Limit Execution Details section to provide additional detail about which limit types are atomically applied in the matching engine. |
| 1.6.16 | 02/01/22 | Updated Curb session effective date to 04/25/22 TBD. |
| 1.6.17 | 04/04/22 | Additional clarification added to sections 1.2 and 1.3 to ensure clarity around the fact that Risk Root rules are always associated with a single EFID. Updated Curb session effective date to 04/25/22. |
| 1.6.18 | 03/08/23 | The system will reload and reset all risk limit lockouts at approximately 2:35 a.m. (C1 only), 9:05 a.m., and 4:05 p.m. ET (C1 Only). |
| 1.6.19 | 01/12/24 | Formatting updates. |
| 1.6.20 | 01/15/25 | In Cancel, Rejects and Resets : removed `D` and `H` RiskReset values, and updated Risk Counters Reset to N for RiskReset = `C` . Updated with Cboe Titanium branding. |
| 1.6.21 | 08/18/25 | Updated Risk Based Notional (Risk Root or EFID Level) description to indicate that notional is computed as the sum of the products of premium multiplied by number of contracts with no netting of buy or sell legs in complex instruments applied. |
| 1.6.22 | 12/31/25 | Updated Risk Management Profile. |
| 1.6.23 | 02/10/26 | Added TargetMatchingUnit to the set of values that make a `Reset Risk` message unique (effective 02/16/26). |
| 1.7.0 | 03/13/26 | Added new Atomic vs. Best-Efforts Limits, Risk Limit Controls , Contra-Capacity Fractions , Exclude Auction Volume , and Atomic EFID/EFID Group Limits sections to detail the optional Contra-Capacity Fractions, Exclude Auction Volume, and Atomic EFID/EFID Group Risk Limit controls (effective 04/20/26). Updated updated Limit Execution Details section title to Risk Limit Implementation Details and updated Risk Type Levels section title to Risk Limit Level. Removed Risk Management Profile and added Configuring Risk Profiles. Updated text throughout for clarity. |
| 1.7.1 | 04/15/26 | Updated Risk Limits for Trading Sessions (C1 Only) and Risk Profile Change Timing to reflect planned expansion of C1 trading hours for select equity options, including the addition of a morning Global Trading Hours (GTH) session and afternoon Curb session, subject to regulatory review (effective 07/13/26 08/17/26 TBD). |
| 1.7.2 | 06/12/26 | Updated planned expansion of C1 trading hours for select equity options to 08/17/26. |
| 1.7.3 | 07/06/26 | Updated Risk Root (Symbol) Level to include that the customer must ensure that the executing firm id (EFID) and the risk root (option underlying) are aligned with respect to associated clearinghouse. |
| 1.7.4 | 08/10/26 | Updated planned expansion of C1 trading hours for select equity options to TBD. |