# Cboe Titanium Cboe Compression Service User Manual

Version 1.0.14 · February 11, 2025

## Introduction

The Cboe Titanium Cboe Compression Service (CCS) is a multilateral compression service used by Cboe TPHs to manage capital requirements associated with portfolios of SPX and SPXW index option positions1. The CCS computes and automatically clears (after TPH approval) a portfolio of trades that provides maximum compression benefit to all participating TPHs.

TPHs participate in the service through the Cboe Customer Web Portal where they access the Cboe Compression Service application. They upload files that specify positions for compression, regulatory capital benefit associated with closing contracts of each submitted position, and cost and risk constraints on the portfolio of compression trades they are willing to accept.

The CCS determines a portfolio of position closing trades among participating TPHs that maximizes regulatory capital delivered to each TPH while satisfying all constraints specified by all TPHs. Each participating TPH is provided with a detailed compression portfolio specification that enables them to efficiently analyze the portfolio benefit and constraint satisfaction, after which they approve the multilateral portfolio using functionality provided by the CCS application. On unanimous approval of the portfolio by all participating TPHs, the trades comprising the portfolio are automatically cleared at the OCC, printed to OPRA, and disseminated on data feeds and FIX Drop connections to firms and their clearing providers in real-time.

This document begins with the Cboe Compression Service service description. It provides a high-level introduction to the full scope of TPH interaction with the service to effect position compression. Also included in the service description are service registration and certification details, intraday workflow timing, service availability dates, and Consolidated Audit Trail (CAT) reporting. The remainder of this document specifies the constrained position input file used to submit positions for compression and cost and risk constraints, and output files generated by the multilateral compression service.

1 FLEX option positions not supported.

## CCS Service Description

The figure below presents the high-level CCS workflow from the TPH perspective, followed by a description of the numbered steps. Service availability scheduling and intraday timing of each workflow step is presented later in this document.

_(Figure: Figure 1. Cboe Compression Service Workflow)_

1. TPHs upload position specification files to the CCS through the CCS portal, which is accessed through the secure firm login used to access all other exchange services and administration functions. TPH submissions contain a specification of each position being submitted for multilateral compression and/or match data dissemination. Checkboxes are presented for multilateral compression and/or match data for TPHs to choose which or both services. For TPHs that opt-in to multilateral compression, cost and risk constraints are optionally specified by TPHs to constrain the cost of compression relative to TPH-specified theoretical values and the acceptable risk profile of compression portfolios. The input file format to specify position and constraint specifications is presented later in this document.
2. At the end of the input submission window, TPHs are notified via email that the submission window has closed, and the system has started computing a candidate multilateral compression portfolio for those TPHs that opt-in to multilateral compression. The CCS portal interface changes from input submission to an informational message indicating that multilateral compression computation is in-progress and to standby for results. TPHs that opt-in to match data service only (i.e., no multilateral compression) wait for the multilateral compression to complete, after which they participate in the bilateral match data service.
3. When the system has completed calculating a candidate multilateral compression portfolio, TPHs that opt-in for multilateral compression will see the CCS portal change from 'stand by' to 'candidate portfolio ready for download, analysis and approval'. Additionally, email notifications are sent to participating TPHs announcing that results are available for download. This event starts the 'approval window', which is a time period during which TPHs are expected to download and analyze portfolio files.
4. TPHs use links presented in the CCS portal to download detail and trade level output files specifying their subset of the candidate multilateral compression portfolios. The detail file presents a decorated version of the originally submitted input file that adds traded quantities of each position, system prescribed compression prices used for each option trade, and details of all cost and risk constraint calculations. TPHs use the detail file to efficiently confirm that all specified constraints are satisfied. The trade file is a simple trade blotter presenting details of the trades that will be cleared upon unanimous approval by all participating TPHs.
5. Having analyzed the candidate compression portfolio trades, risk profile, and cost constraints, TPHs use the CCS portal to approve or reject the candidate multilateral compression portfolio. Approving or rejecting a portfolio requires the entry of an approval token, which is embedded in the detail output file. This step confirms that the TPH has opened and reviewed the detail output file corresponding to the compression portfolio being approved. If a TPH fails to approve or reject the portfolio by the end of the approval window, the system will consider the TPH to have rejected the candidate portfolio. Any TPH that receives zero compression trades in their compression portfolio will be automatically deemed to have accepted the portfolio. In the event that one or more TPHs reject or fail to approve or reject during the approval window (i.e., times out), TPHs are notified via email that the compression portfolio has not been unanimously approved and no trades will be consummated as a result.
6. When all participating TPHs have approved the candidate compression portfolio, the system begins to process the trades comprising portfolio through the Cboe Exchange trading system. While the trading system is processing compression portfolio trades, the CCS portal interface will indicate that the system is computing post-compression match data for those TPHs that opt-in to the match data service (see step 10 below).
7. TPHs are notified of CCS compression trades with `Execution Report` messages over FIX Drop ports in real-time. CCS trades are identified using the TradeLiquidityIndicator(9730) and Compression(22006) fields. The value `C` in the 2nd character of the TradeLiquidityIndicator(9730) field uniquely identifies compression trades resulting from the CCS system. Note that the FIX Drop port attribute Send 2nd Liquidity Character must be configured to `Yes` (default value is `No`) in order to receive the 2nd character. This confirmation is necessary to differentiate CCS trades from compression trades executed as a result `New Order Cross` messages with CrossType set to 4 (PCC) submitted over an order entry port.
8. CCS compression trades are disseminated on exchange Multicast PITCH and TOP feeds as Trade Messages with Trade Condition set to `u`.
9. CCS compression trades are available in standard daily Trade Data files and monthly Trade Detail files accessible through the firm portal.
10. CCS compression trades are reported to OPRA using a type code of `u` which represents 'Multilateral Compression Trade of Proprietary Products'.
11. CCS compression trades are submitted to the OCC for clearing same day (day of trade) using information provided by TPHs when registering to use multilateral compression functionality of the CCS.
12. CCS generates Consolidated Audit Trail (CAT) data files for participating Industry Members ( `IM` = TPH) using profile information provided by TPH as specified in Service Registration and Consolidated Audit Trail (CAT) Reporting. TPHs can opt-in to self-reporting the IM data, in which case, they download the generated IM data files via the Cboe Web Portal and submit directly to the CAT.
13. Consummated compression trades will be reported via the standard trade reporting files with all other trades by the Clearing TPHs housing the positions on the business day following the associated compression cycle.

### Security and Data Privacy

In the CCS workflow presented in Cboe Compression Service Workflow, TPHs submit position information for compression. Information regarding TPH positions is treated as private and sensitive information, the same as all other data managed by the Exchange on behalf of the TPH including instructions received over order entry port connections and TPH execution information from live trading. TPHs upload positions and download compression portfolio and match data service through the same secure firm portal through which all other secure information exchanges are conducted.

Multilateral compression uses advanced computational algorithms to compute a portfolio that delivers maximum value, while satisfying constraints, to participating TPHs in a completely anonymous manner. No identifiable TPH information is used in the process of computing traded quantities for each participating TPH during compression portfolio construction. TPHs receive information regarding their trades only, without information on contra TPHs on the other side of their trades. Throughout the entire process, TPHs do not have access to other TPH positions, nor are they presented with information regarding the other side of any trade within the portfolio. Only after trades have cleared do TPHs receive standard trade reporting information from the OCC on the business day following the compression cycle, which includes contra TPH information.

### Service Availability

Multilateral compression service will be available on exchange specified normal trading dates and will be announced in advance via direct communication with certified TPHs.

### Coincident Multilateral Compression and Match Data Service Dates

The figure below presents the intraday timeline of the CCS workflow on days which both multilateral compression and match data service is configured to run. The indicated times are approximate and in practice the timeline can and will vary based on certain events and conditions as indicated in the description below.

_(Figure: Figure 1. Multilateral Compression and Match File Intraday Timeline)_

TPHs can upload position files starting at 13:00 ET. On dates when multilateral compression is configured to run, TPHs are presented with a multilateral compression check box to confirm desire to participate in multilateral compression. At 16:45 ET TPHs are notified that input files are no longer being accepted, and in the event that there are two or more TPHs submitting, the notification will indicate that the compression window has begun. If fewer than two TPHs have submitted for compression, TPHs are immediately notified that compression will not occur on the current date.

Between 16:45 and 17:05 ET, the system executes compression analytics to determine a multilateral portfolio of trades to present to TPHs. At 17:05 ET2 the system prepares detail and trade output files to present to TPHs and notifies via email when output files are available for download. TPHs have until 17:28 ET to return to the CCS portal application and approve or reject the portfolio. If all participating TPHs approve prior to 17:28 ET, the system determines there is no need to wait and immediately notifies TPHs that the portfolio is approved and trade processing has begun.

2 In the event that compression analytics complete prior to 17:05 ET, output files will be prepared and presented to TPHs prior to 17:05 ET. TPHs have until 17:28 to approve or reject their respective portfolios regardless of the time output files are presented to TPHs.

### Service Registration

TPHs wishing to use the CCS should first contact Membership Services. Membership services will instruct registering TPHs on required registration profile information.

Registered TPH profile information is used for clearing trades resulting from an unanimously approved compression portfolio, and for reporting to the Consolidiated Audit Trail (CAT). In addition to the notification email address and authorized firm logins, TPHs registering to use multilateral compression must provide the following information:

**Table 1. Required Multilateral Compression Registration Information**

| Profile Field | Description |
|---|---|
| EFID | A single Cboe Executing Firm ID, which uniquely identifies the firms OCC ID that will be used to clear all CCS trades. Firms are not provided with the ability to clear multiple EFIDs; only a single EFID is allowed. |
| Clearing Capacity | Allowed Cboe Capacity codes are M (Market Maker), N (Away Market Maker), F (Firm), and L (Non-TPH Affiliate). |
| Market Maker Clearing Account | Required only if Clearing Capacity is set to M or N. Maps to OCC Sub Account ID. If provided, value must correspond to valid Market Maker Clearing Account at the OCC. |
| Account | Maps to OCC Customer ID |
| OCC Clearing Optional Data | Optional clearing data. Empty text allowed. |
| Firm Designated ID | Firm assigned trading account identifier used in Firm Designated ID field value in CAT MONO events. |
| Self-Report IM Events | Boolean value specified by firm to indicate whether firm wishes to submit IM event files (i.e., self-report) or wishes Cboe Silexx, LLC (Cboe Silexx)3 to submit MONO and MOOR event files to CAT on behalf of (OBO) the firm. `TRUE` = firm submits IM event files, `FALSE` = exchange submits IM event files on behalf of the firm |

3 See Update - Consolidated Audit Trail (CAT) – "on Behalf of Reporting" Expanded in Preparation for CAT Phase 2D Reference ID: C20211111201 (November 12, 2021) regarding requirements to authorize Cboe to both provide CAT data files to TPHs and, for interested TPHs, to submit data files to the CAT on behalf of such TPHs.

### Certification Process

Certification to use CCS multilateral compression in the production environment is accomplished by interacting with the CCS in the Cboe Exchange certification environment under the direction of the Cboe Trade Desk. TPHs must demonstrate the ability to properly construct formed position and constraint input files as specified later in this document. Prior to successful certification, TPHs will be unable to interact with the CCS in the production Cboe Exchange firm portal. Once a TPH has successfully certified, they will be able to select multilateral compression while uploading compression submission files, otherwise the option will be disabled and they will not be able to participate.

The certification processes must be completed by at least one authorized firm login. Certification does not require that all registered firm logins complete the certification process. It is assumed that knowledge is distributed at the certifying firm and that all authorized firm logins are able to use and operate the service as a result of successful certification. It is assumed that firm-side systems used to generate formatted input to the CCS are generally automated, and once demonstrated compatible with the CCS service they will remain so. TPHs are advised to test major firm-side input file generation changes in the Cboe Exchange certification environment.

TPHs will not be allowed to begin certification until they have provided clearing information as part of the registration process (see above section on Service Registration). TPHs submitting files for multilateral compression will be expected to specify valid theoretical option prices for each position, max cost and max cost per unit benefit constraints, and one or more custom constraints demonstrating the ability to specify per-expiration and cross-expiration (e.g., full portfolio or bucketed expirations) risk exposure constraints with reasonably specified minimum and maximum values.

As part of certification for multilateral compression, TPHs will join a multilateral compression process running in the certification environment to demonstrate the ability to upload properly structured input files, the ability to download detail and trade level output files (specified later in this document) and to successfully approve the portfolio through CCS portal functionality. Successful approval of the portfolio requires a form of two-factor authentication where TPHs enter an approval token embedded in the detail output file as described later in this document.

### Consolidated Audit Trail (CAT) Reporting

For the purpose of this document, TPHs are assumed to have registered and onboarded with CAT as a CAT Reporter.

The use of the CCS for multilateral compression generally results in Consolidated Audit Trail (CAT) reportable option events for participating TPHs (CCS CAT Industry Member (IM)).

Cboe generates CAT event data for CCS IM option events. IM event data are conditionally submitted to the CAT based on TPH profile information provided when registering to use the CCS (see Service Registration). TPHs that wish to self-submit IM data to the CAT will download data files from the Cboe Web Portal. All IM CAT data files, are accessible on the Cboe Web Portal as a form of 'drop copy' for CAT submission data files, irrespective of whether or not a TPH has opted to self-submit IM data.

TPHs submit constrained position files representing positions they are willing to compress. The entries in the constrained position files are not orders. When a TPH approves its portion of a multilateral compression portfolio, a New Option Order (MONO) event is generated for each option that trades in the approved portfolio (i.e., non-zero traded_qty in the portfolio detail output file). The positions that do not trade in the approved compression portfolio (i.e., zero traded_qty in the portfolio detail output file) do not result in MONO events at the time that the TPH approves a portfolio. Associated with each MONO event, the exchange generates a consistent Option Order Routed (MOOR) IM event. The MONO and MOOR events be reported to CAT whether or not unanimous approval results in executed trades.

When all participating TPHs have approved their respective portfolios, the CCS performs processing to clear and report the multilateral set of trades comprising the compression portfolio. If one or more TPHs does not approve their portfolio, no trades are executed. An Option Trade (OT) PP event is created for each trade executed in a unanimously approved multilateral compression. In the event of an unsuccessful compression in which one or more participating TPHs fails to approve their respective portfolio, MONO, MOOR, and OOA events are still reported but no OT trades will be reported.

The table below summarizes the IM and Plan Participant (PP) option order events that result from a TPH approving a multilateral compression portfolio, and the PP option trade events that result when all participating TPHs unanimously approve the multilateral compression portfolio.

**Table 1. CCS Multilateral Compression CAT Event Summary**

| Trigger | Source | Event | Description |
|---|---|---|---|
| TPH Approves Portfolio | IM | MONO | New Option Order Event is created for each series in the portfolio with non-zero traded_qty (see Compression Portfolio Detail File). Orders are created with GTT time in force with time set to compression date 17:30 ET. As a result, MOOC events are not required when unanimous approval not achieved. The event timestamp for all MONO events is the time of portfolio approval. The Firm Designate ID value is set to the value specified by the firm in the CCS service registration data (see Service Registration). |
| IM | MOOR | Option Order Route Event is created for each MONO. |  |
| PP | OOA | Simple Option Order Accepted Event created for each MONO. |  |
| Unanimous TPH Portfolio Approval | PP | OT | When all participating TPHs have approved their respective portfolios, an Option Event is created to represent each two-sided trade between participating TPHs that is executed and cleared at the OCC. The event timestamp for all OT events is the time at which unanimous approval was realized (i.e., the time of the last TPH to approve their respective portfolio). |

## CCS Input File Specification

TPHs use the single comma separated value (CSV) file format specified in this section to participate in multilateral compression. TPHs specify existing positions to be considered for compression, and cost and risk constraints of compression portfolios they are willing to accept from the compression process. The certification process for multilateral compression validates TPH ability to construct properly structured input files with cost and risk constraints.

The CSV file format specification that follows comprises both numeric and non-numeric data. Embedded whitespace is not permitted at any location within an input record. Certain fields contain required `null` values represented by consecutive commas. Numeric precision of numeric fields is significant and is presented in detail below.

Note on precision - TPHs wishing to exactly replicate reported constraint values computed by the system and represented in the detail output file presented in Compression Portfolio Detail File must provide floating point numeric values to the precision as underlined below. If values are provided to higher precision, they will be rounded by the system and as a result, due to floating point number representation differences between platforms, TPHs might not be able to exactly replicate aggregated constraint values (though discrepancies will be very small).

### Input File Validation

When TPHs upload files through the CCS application in the firm portal, strict validation checks are applied to validate compliance with all requirements of the input file specification below. For example, expiration dates are required to be provided in YYYY-MM-DD format. A single expiration date among thousands specified in an incorrect format, or representing an invalid date, will cause the upload to fail. TPHs are presented with detailed error messages describing all validation errors contained in an upload (not just the first validation error) facilitating a straightforward process to update the file and re-upload.

Common causes of input file validation errors include the following:

- Invalid expiry date format (e.g., MM/DD/YYYY specified rather than the required YYYY-MM-DD). This is the most common formatting error as input CSV files opened and saved in Excel will convert dates formatted YYYY-MM-DD to MM/DD/YYYY automatically.
- Wrong number of tokens in the header row (i.e., fewer than 11)
- Incorrectly formatted second or third row (typically one too many or one too few consecutive commas)
- Invalid class value - only SPX and SPXW are supported
- Expired options - expiration dates on current or prior date not allowed
- Invalid or nonlisted strike price - only currently listed strikes are allowed
- Null value (consecutive commas) provided where non-null values are required, or vice versa
- Leading, trailing or embedded whitespace
- Invalid floating point value format, such as using parentheses instead of minus sign ( `-`) to represent negative numbers
- Commas embedded in integer values
- Double-quotes output by some systems to escape values containing commas are not supported
- All zero values provided for close_benefit when opting in for multilateral compression
- No custom risk constraints defined for a multilateral compression submission
- Using Excel can lead to surprising date and numeric format changes when saving .xlsx files to CSV

### Required File Preamble

The first three rows of the input file must be formatted as shown below, where the column indexes 1-12 indicate one-referenced token position, and row indexes 1-3 indicate one-referenced row position. The indicated column and row indexes are not part of the file and are shown for positional reference only.

_(Figure: Figure 1. Required CSV Input File Preamble Structure)_

All values in rows 2 and 3 are null (i.e., consecutive commas) except for positions 10 and 11 in row 3, which are non-negative floating point values. The cost and cost_benefit column values in row 3 will typically be values other than zero (though values of zero are valid and accepted for reasons described in subsequent sections of this document).

_(Figure: Figure 2. Example CSV Input File Preamble class,expiry,strike,put_call,qty,theo,close_benefit,reserved,reserved,cost,cost_benefit ,,,,,,,,,, ,,,,,,,,,0.0,0.0)_

Note the actual strings used in the header line are not validated, and only the count matters. It is recommended but not required that the standard values presented above be used for clarity. That said, whitespace and embedded commas are not allowed in header string tokens. In certain examples below, `rsvd` is used rather than `reserved` in example header lines to save space. Such headers are accepted since the header tokens are not required to match the above specified values.

### Required Position Specification Format

Rows 4 and higher of the input file are used to specify option positions submitted for compression. Every position record must contain the 11 comma separated tokens with no embedded whitespace specified in the table below.

**Table 1. Required Position Specification Format**

| Field | Description |
|---|---|
| class | Case sensitive SPX or SPXW. Single-leg non-FLEX options only are supported. |
| expiry | Expiration date in YYYY-MM-DD format. Must be a valid currently listed non-expired SPX or SPXW expiration date. Expired or option positions expiring on the day of submission are not allowed. |
| strike | Option price as a floating point numeric value. Must correspond to the strike price of currently listed option in the specified class and expiry. |
| put_call | Case sensitive P or C. |
| qty | Signed integer contract position where positive integer is a long position and negative integer is a short position. Zero values are accepted but are discouraged as they are currently ignored by the CCS. |
| theo | Non-negative floating point value representing the TPH assessment of the theoretical value of one long contract of the associated option (i.e., contract multiplier of 100 applied). This value is not used for the match data file service. Users of match data file service only will typically provide zeros. Two decimal points of precision are accepted and higher precision inputs are rounded. |
| close_benefit | Non-negative floating point value representing the TPH assessment of the capital requirements benefit resulting from reduction of the position by one contract (long or short). Two decimal points of precision are accepted and higher precision inputs are rounded. Files containing all zero values for close_benefit when the TPH opts-in to multilateral compression will fail validation at upload time, whereas all zero values is accepted for TPHs opting in to match data service only. This value is not used for the match data file service, and users of match data file service only will typically provide zeroes. |
| reserved | Must be null (i.e., consecutive commas) |
| reserved | Must be null (i.e., consecutive commas) |
| cost | Must be null (i.e., consecutive commas) |
| cost_benefit | Must be null (i.e., newline immediately after preceding comma) |

### Compression Regulatory Capital Benefit Specification

Multilateral compression produces a portfolio of trades that attempts to deliver maximum value to all participating TPHs while satisfying all cost and risk constraints specified by all TPHs. The analytics that are used to determine the "best" compression portfolio require that TPHs assign a "benefit" to closing one contract of positions in each option presented in the input file. The compression analytics use the benefit value to preference closing positions with higher benefit when selecting among alternatives that satisfy all constraints. The regulatory capital benefit for each position is specified by TPHs in the close_benefit field associated with each position row in the input file (rows 4 and above).

The close_benefit value is a TPH-specified measure of the regulatory capital benefit to the TPH for closing one contract (i.e., accounting for the 100 contract multiplier of SPX/SPXW) of the position in the associated option. TPHs are free to express the regulatory capital benefit in units meaningful to the TPH, which may be CEM, RWA, SA-CCR or other proprietary measure that expresses relative value realized from closing positions in options in the positions submitted for compression. The value provided in the input file must be a non-negative floating point value with two decimal point precision. Values provided with additional precision are rounded to two decimal points. Zero values are allowed for close_benefit for a subset of options positions. When TPHs opt-in to multilateral compression, a submission with all zero values for close_benefit will be rejected at upload time. Note this is not the case when users opt-in for match data service only as close_benefit is ignored in the match data generation process; i.e., all zero values for close_benefit is allowed for uses of match data service only.

The total regulatory capital benefit provided to a TPH as a result of a compression portfolio is the sum of the absolute traded contract quantity (which may be zero) multiplied by the TPH-specified close_benefit for all options comprising the portfolio. Regardless of whether a traded quantity is negative (a sell trade to close or partially close a long position) or positive (a buy trade to close or partially close a short position) the accrued benefit is positive.

For example, an option position with a size (qty) of 100 and close_benefit of 5,000 that trades -20 (i.e., closes 20 of the 100 contract long position). The contribution to the total benefit for the option will be 20 * 5,000 = 100,000. Similarly, for an option position with a size (qty) of -50 and a close_benefit of 4,000 that trades +20 (i.e., closes 20 of the 50 contract short position) the contribution to the total benefit for that option will be 20 * 4,000 = 80,000.

### Specifying Constraint Minimum and Maximum Values

TPHs specify minimum and maximum values for cost constraints and for TPH defined custom constraints using rows 2 and 3 of the file format. Row 2 is used for specifying constraint minimum values, and row 3 is used for specifying constraint maximum values.

Maximum Cost and Cost Per Unit of Benefit Constraints and Custom Risk Profile Constraints describe the use of input file format features for specifying cost and risk constraints, both of which make use of row 2 and 3 values to place lower and upper bounds for constraint values respectively.

### Maximum Cost and Cost Per Unit of Benefit Constraints

Defined below are the cost of compression, cost per unit of benefit, and the input specification features TPHs use to specify maximum values for cost and cost per unit of benefit they are willing to incur in a multilateral compression.

TPHs participate in multilateral compression to realize maximum regulatory capital benefit while satisfying constraints, which includes cost constraints. The cost of compression is the total mark to market cost of a portfolio of trades allocated to a TPH. TPHs can place an upper limit on the total cost they are willing to pay in a multilateral compression.

The CCS system uses final indicative prices that are disseminated to OPRA as the prices at which CCS compression trades will clear. Compression trade prices are derived from live markets trading at 16:00 ET. The degree to which these prices deviate from TPH internal views of the theoretical value (theo) of the options comprising the compression portfolio determines the overall compression cost to the TPH. For example, if a TPH is buying to close a short position and the compression price is higher than the TPH view of the option theoretical value, the trade will incur a mark to market debit. Conversely, if the compression price is lower than the TPH specified theoretical value of the option, the TPH would incur a net mark to market credit as a result of the trade.

TPHs specify the theoretical value of one contract of an option in the theo field of the position specification rows (see field 6 in Table 1) specified to two decimal point precision. Values specified to higher precision are rounded to two decimal points. The cost of a single trade is computed as the signed traded quantity in contracts multiplied by the compression price minus the TPH specified theo value of the option. Since both the TPH-specified theo and the exchange sourced compression prices are expressed per contract, the trade cost is the contracts-traded weighted difference of the compression price and TPH specified theo. The total cost of the multilateral compression portfolio to a participating TPH is the sum of the cost of all trades in the compression portfolio in which the TPH participates.

TPHs specify the maximum cost (net debit) they are willing to incur in a multilateral compression. The CCS does not provide the ability to specify a minimum cost (net credit) they are willing to receive. It is assumed that TPHs are willing to book any level of mark to market gain while receiving capital regulatory benefit that satisfies risk constraints. To specify the maximum cost (debit) TPHs provide a non-negative value in cost field (10) of the maximum value row (3), where a value of zero indicates they are not willing to accept any net debit and a positive value is the maximum net debit they would be willing to incur in a multilateral compression. The CCS accepts the maximum cost value with two decimal point precision (i.e., cost in dollar terms). Values specified with higher precision are rounded to two decimal points.

In addition to specifying a limit to the net cost that a TPH is willing to incur in a compression portfolio, TPHs further specify a limit on the cost per unit of regulatory capital benefit received. In the event that the maximum cost is not reached, the maximum cost per unit of benefit ensures that TPHs receive a minimum amount of benefit for each dollar 'spent' in a compression. TPHs specify the maximum cost per unit of benefit by providing a non-negative value in the cost_benefit field (11) of the maximum value row (3), where a value of zero indicates they are not willing to accept any net debit regardless of the amount of benefit delivered. The CCS accepts the maximum cost per unit of benefit value with six decimal point precision. Values specified to higher precision are rounded to six decimal points.

Consider a TPH that is willing to incur up to $10,000 net debit in a compression. Further, the TPH wishes to constrain the maximum cost per unit of benefit such that $1 of cost delivers $1,000 of capital regulatory benefit. The maximum cost per unit of benefit in this example is 0.001000 (i.e., 1 / 1,000). The first three lines of the TPH input file encoding these maximum cost and maximum cost per unit of benefit constraints is shown below:

_(Figure: Figure 1. Multilateral Compression Input File Preamble Example class,expiry,strike,put_call,qty,theo,close_benefit,reserved,reserved,cost,cost_benefit ,,,,,,,,,, ,,,,,,,,,10000.00,0.001000)_

### Custom Risk Profile Constraints

In addition to placing limits on mark to market cost of compression, TPHs require the ability to constrain the risk profile of compression portfolios to suit TPH-specific risk tolerance and methodology for expressing risk limits. Rather than imposing a predefined regimen that limits the manner in which TPHs can specify risk constraints to a set of predefined methods, algorithms and analytics, Cboe has designed a unit and algorithm agnostic mechanism that allows TPHs to specify risk constraints in any manner they choose and at any level of granularity, effectively without limits.

TPHs can specify an unlimited number4 5 of custom constraints by adding columns to the required 11 column specification presented above. Each new column represents a new custom constraint. The header row (1) element in a new column is the constraint label, or name, that will be used to uniquely identify the custom constraint in output files presented below. Custom constraint labels must be unique among the set of custom constraints, and like all other fields in the input file specification, cannot contain embedded commas, and the use of double-quotes to escape label strings with embedded commas is not supported. The row 2 and row 3 values in a new column contain the TPH specified minimum and maximum value for the custom constraint respectively, specified to two decimal point precision. Values specified with higher precision are rounded to two decimal points. Custom constraint minimum values must be <= 0.0 and maximum values must be >= 0.0. The reason for this requirement is to ensure that zero traded contracts assigned to an over-constrained submission will satisfy all custom risk constraints without exception. The position row (rows 4 and above) values in a custom constraint column contain a signed floating point value representing the contribution to the constraint of one long contract traded in the option associated with the position row, specified to six decimal point precision. Values specified to higher precision are rounded to six decimal points. Every position row must contain a value for every custom constraint with zeros indicating the associated option does not contribute to the constraint. The result is that every row in the input file contains the same number of comma separated values, which is one of many validation checks applied to input files uploaded to the CCS.

The example below introduces the custom constraint design using a hypothetical input file comprising two distinct expirations (SPXW expiring 2021-12-31 and SPX expiring 2022-03-18). The theo and custom constraint values in the example use the Black76 model with underlying of 4,000, time to maturity of 0.50 and 0.75 for the two expirations, implied volatility of 20% and an interest rate of zero. The close_benefit values are computed using a common RWA-based formula. The position quantity is arbitrarily set to long 50 contracts for all options in the example. Maximum cost and cost per unit benefit constraint values of $10,000 and 0.001 from the above example are specified.

In this example, the TPH wishes to constrain the delta of the compression portfolio trades in each expiration to within +/-500 and across the entire portfolio (i.e., all expirations) to +/-750. In order to constrain the net delta on the first expiration (2021-12-31) to within +/-500, the TPH defines a custom constraint labeled `c_1` with minimum and maximum values specified as -500 and 500 respectively, and the values associated with each option of the 2021-12-31 expiration are assigned the Black76 delta multiplied by the contract multiplier of 100. Zeros are specified for the constraint value associated with any expiration other than 2021-12-31. Likewise, in order to constrain the net delta on the second expiration (2022-03-18) to within +/- 500, the TPH defines a second custom constraint labeled `c_2` with minimum and maximum values specified as -500 and 500 respectively, and the values associated with each option of the 2022-03-18 expiration are assigned the Black76 delta multiplied by the contract multiplier of 100. Zeros are specified for the constraint value associated with any expiration other than 2022-03-18. Finally, in order to constrain the overall portfolio net delta to within +/-750, the TPH defines a third custom constraint labeled `c_3` with minimum and maximum values of -750 and 750 respectively, and the values associated with all options set to their respective Black76 delta multiplied by the contract multiplier of 100.

_(Figure: Figure 1. Example CCS Input with Custom Risk Constraints)_

The figure above is a table-based presentation of a CCS input file. The actual formatted CSV file content of the example is shown in CSV Formatted Example Trade Output File.

_(Figure: Figure 2. CSV Formatted Example CCS Input with Custom Risk Constraints class,expiry,strike,put_call,qty,theo,close_benefit,rsvd,rsvd,cost,cost_benefit,c_1,c_2,c_3 ,,,,,,,,,,,-500.00,-500.00,-750.00 ,,,,,,,,,10000.00,0.001000,500.00,500.00,750.00 SPXW,2021-12-31,3900,C,50,21253.36,6645.60,,,,,61.912292,0.000000,61.912292 SPXW,2021-12-31,3900,P,50,11253.36,6645.60,,,,,-38.087708,0.000000,-38.087708 SPXW,2021-12-31,4000,C,50,15951.04,6816.00,,,,,51.993881,0.000000,51.993881 SPXW,2021-12-31,4000,P,50,15951.04,6816.00,,,,,-48.006119,0.000000,-48.006119 SPXW,2021-12-31,4100,C,50,11639.87,6986.40,,,,,42.194267,0.000000,42.194267 SPXW,2021-12-31,4100,P,50,21639.87,6986.40,,,,,-57.805733,0.000000,-57.805733 SPX,2022-03-18,3900,C,50,27622.19,6645.60,,,,,0.000000,59.860371,59.860371 SPX,2022-03-18,3900,P,50,17622.19,6645.60,,,,,0.000000,-40.139629,-40.139629 SPX,2022-03-18,4000,C,50,22548.79,6816.00,,,,,0.000000,52.818599,52.818599 SPX,2022-03-18,4000,P,50,22548.79,6816.00,,,,,0.000000,-47.181401,-47.181401 SPX,2022-03-18,4100,C,50,18177.18,6986.40,,,,,0.000000,45.862735,45.862735 SPX,2022-03-18,4100,P,50,28177.18,6986.40,,,,,0.000000,-54.137265,-54.137265)_

This is a complete, albeit trivial, example of a TPH upload to the CCS for multilateral compression that specifies cost constraints and risk exposure constraints comprising per-expiration and portfolio-level delta bounds. In practice, input files may contain 30 or more distinct expirations, each with 500 or more distinct listed option positions. TPHs will generally add custom constraints to manage other Greek exposures (e.g., gamma, vega, etc.) proprietary measures. Constraints can be defined by expiration, by strike region within expirations, across groups of nearby expiration, etc. In practice, it is not uncommon for TPHs to specify well over 100 custom constraints, and much more for some TPHs requiring fine-grained control of acceptable compression portfolio exposure profiles.

It should be noted that in the specification of custom constraints, no assumptions have been made other than a constraint has TPH-specified value associated with one long contract executed in the option, with zeros indicating the constraint does not apply to a particular option. As a result, TPHs can constrain portfolios using any metrics, whether option model based or any other measure. For example, using a nonsensical example, if a TPH wanted to limit the number traded contracts to 100,000, they could add a custom constraint with values of -1.0 for long positions and 1.0 for short positions with a minimum value of 0 and a maximum value of 100,000. The traded quantity weighted sum of the constraint values would then be equal to the total number of contracts traded, which would be limited to 100,000 by the CCS multilateral compression algorithm for the TPH specifying the constraint. As a result of the CCS unit-agnostic approach to custom constraint specification, TPHs can implement any constraint regimen that fits their internal risk processes and quantitative methods rather than being required to operate within a prescriptive exchange specified framework.

4 TPHs that opt-in to multilateral compression are required to specify at least one custom constraint. Submissions for multilateral compression with no custom constraints are indicative of an operator or system error and are thus prevented from participating. Risk constraints to specify boundaries for acceptable portfolio risk and imbalance are a critical aspect of ensuring that all participants receive only portfolios they are willing to accept, and as a result, unconstrained input submissions are disallowed at upload time.

5 CCS imposes a maximum of 1,500 custom risk constraints to ensure system integrity. Cboe reserves the right to change the limit on the maximum number of custom constraints in the future in the interest of delivering maximum compression benefit to all participating TPHs in the relatively short compression window. Any change to the maximum number of custom constraints will be announced in a Trade Desk notice.

## CCS Output File Specifications

This section specifies the content and format of output files provided to TPHs in the Cboe Compression Service Workflow.

TPHs are presented with trade and detail output files at the end of the compression window. The output files contain detail sufficient for TPHs to quickly analyze the trades comprising a compression portfolio, and to confirm that all specified constraints are satisfied by the set of trades.

The following sections present the format and content of each type of multilateral compression output file. The output file examples presented below are output from a hypothetical compression using the CCS input file presented in Example CCS Input with Custom Risk Constraints.

### Compression Portfolio Trade File

The compression portfolio trade file is a CSV formatted file summarizing the non-zero traded quantities of each option comprising a compression portfolio in simple trade blotter form. The trade file contains one line per option that trades in the compression portfolio and options with zero traded quantity are not represented. The Compression Trade File Field Definition Table presents the field definition of the compression trade output file.

**Table 1. Compression Trade File Field Definition**

| Field | Description |
|---|---|
| class | SPX or SPXW. |
| expiry | Expiration date in YYYY-MM-DD format. |
| strike | Option strike price. |
| put_call | P or C. |
| trade_qty | Signed integer traded quantity in contracts where positive is buy and negative is sell. |
| trade_price | Unsigned floating point trade price. |

Below is an example CSV formatted output from a hypothetical compression using the TPH input from CSV Formatted Example CCS Input with Custom Risk Constraints. The trade file output in Example compression detail output file is the trade-level output corresponding to the detail level output presented in the next section.

_(Figure: Figure 1. CSV Formatted Example Trade Output File class,expiry,strike,put_call,trade_qty,trade_price SPXW,2021-12-31,3900.000,C,-20,214.06 SPXW,2021-12-31,3900.000,P,-25,114.06 SPXW,2021-12-31,4000.000,C,-50,161.10 SPXW,2021-12-31,4000.000,P,-50,161.10 SPX,2022-03-18,4000.000,C,-50,223.46 SPX,2022-03-18,4000.000,P,-50,223.46 SPX,2022-03-18,4100.000,C,-10,179.75 SPX,2022-03-18,4100.000,P,-10,279.75)_

Note on trade_qty vs. actual trade fills - The trade file contains one row per option that trades in the compression portfolio. The value of trade_qty is the total contracts that the TPH will trade in the associated option long or short. The traded quantity may be filled with a single crossing trade fill with a single contra TPH or may be allocated to multiple fills with multiple contra TPHs. Regardless, the total traded quantity across one or more fills will sum to the value represented in the trade file, and the price of all trades for the one or more fills will be the value of trade_price contained in the trade file. In other words, the number of rows in the trade file may not match the trade fill count cleared as a result of the compression portfolio.

### Compression Portfolio Detail File

The compression portfolio detail file is a CSV formatted file that TPHs use to access all quantitative details behind the compression portfolio. All constraint value calculations are presented in a manner that allows TPHs to quickly confirm that constraints are satisfied, which constraints may be up against specified limits, and trade and portfolio cost details. This file is an indispensable tool for TPHs to understand their specific contribution to a multilateral compression portfolio, and how their constraint specification is controlling the regulatory capital benefit they receive from a compression. Careful analysis of this file enables TPHs to quickly determine if they can approve the portfolio based on the portfolio details and their specified constraints.

The detail output file contains nearly the same content as the TPH input file with additional columns and calculations added to enable the TPH to observe and easily reproduce all constraint calculations. The detail output file contains exactly the same number of rows as the input file, presented in the same order as the positions in the original input file, with addition of one new row. A new row - the aggregate value row - inserted immediately after the header row (i.e., row 2). The inserted aggregate value row contains the calculated value of cost, cost_benefit and all custom constraints. Four new columns (fields) - traded_qty, residual_qty, compression_price and total_benefit - are added to the detail file to provide complete transparency on constraint calculations. The fields with "(ADDED)" at the beginning of the description in the table below correspond to the new columns.

**Table 1. Compression Detail File Field Definition**

| Field | Description |
|---|---|
| class | SPX or SPXW. |
| expiry | Expiration date in YYYY-MM-DD format. |
| strike | Option price as a floating point numeric value. |
| put_call | P or C. |
| qty | Signed integer contract position where positive is a long position and negative is a short position. |
| traded_qty | (ADDED) Signed integer traded quantity in contracts. Zero indicates no trade in the option. |
| residual_qty | (ADDED) Remaining contracts of original position after compression (i.e., qty - traded_qty). |
| theo | TPH specified non-negative floating point value one long contract of the associated option. |
| compression_price | (ADDED) CCS system sourced compression trade prices derived from options markets at 16:00 ET. |
| close_benefit | Non-negative floating point value representing the TPH assessment of the capital requirements benefit resulting from reduction of the position by a single contract (long or short). |
| reserved | Reserved for future use, will be null |
| reserved | Reserved for future use, will be null |
| total_benefit | (ADDED) Position row values contain the absolute traded quantity weighted close_benefit for each option. The aggregate value row contains the sum of the position row values, which is the total benefit delivered to the TPH as a result of the compression portfolio. |
| cost | Column contains the TPH-specified max cost constraint in the maximum value row (3). Option position rows contain the traded quantity weighted compression_price minus theo, which is the mark to market cost of the trade on each option. The aggregate value row contains the sum of the position row values, which is the total mark to market cost of the portfolio accrued by the TPH. Comparison of the total cost value to the TPH-specified max cost value confirms max cost constraint is met. |
| cost_benefit | Column contains the TPH-specified max cost per unit of benefit value in the maximum value row. The aggregate value row contains the total portfolio cost divided by the total benefit, which is the cost per unit of benefit of the portfolio. Comparison of this value to the TPH-specified max value confirms that the max cost per unit of value constraint is met. |
| [custom constraints] | A column will appear in the detail output file for each custom constraint defined by the TPH in the input file. The minimum and maximum values for each custom constraint are written to the minimum (2) and maximum value (3) rows respectively. The option position row values contain the traded quantity weighted value of the TPH-specified constraint value for the option in the input file. The aggregate value row contains the sum of the position row values, which is the value of the TPH-specified constraint resulting from the compression portfolio. Comparison of this value to the TPH-specified minimum and maximum values confirms the custom constraint is satisfied by the portfolio. |

Example compression detail output file below corresponds to a hypothetical compression portfolio resulting from a TPH submitting the input from Example CCS Input with Custom Risk Constraints and CSV Formatted Example CCS Input with Custom Risk Constraints and comprising trades in the example trade level output file in CSV Formatted Example Trade Output File. Note the reserved columns that would be present in an actual file have been removed to save space.

Important - To approve or reject a portfolio, the TPH must enter an "approval token" found in the first token in the second row (aggregate value row) of the detail output file. The reason for this step is to ensure that the TPH approver has accessed, opened and processed the content of the detail file before approving the compression portfolio.

Aside from the shaded aggregate value row and the shaded columns, the structure of the file is exactly the same as the structure of the input file. The added row immediately after the header row contains computed constraint values that can be visually compared to TPH specified constraint minimum and maximum values in the next two rows to confirm constraints are satisfied. The italicized values are computed values that replace the associated values specified in the input file. Specifically, the values in the cost column associated with each option position, which were null in the input file, are replaced with the cost of the option trade computed as the traded quantity in contracts (traded_qty) multiplied by the difference between the compression price (compression_price) and the TPH specified theo value. The sum of each trade cost, which is the total portfolio cost to the TPH, is contained in the aggregate value row (2) of the cost column. The option position values associated with each custom constraint have been replaced with signed traded quantity (traded_qty) multiplied by the TPH specified constraint value, which represented the constraint contribution associated with one long contract executed in the associate option. The sum of the traded quantity weighted constraint values is contained in the aggregate value row for each custom constraint.

_(Figure: Figure 1. Example compression detail output file)_

This detail file shows the result of the trades presented in CSV Formatted Example Trade Output File is a portfolio cost of $1,502.35, which satisfies the max cost constraint of $10,000. The cost per unit of benefit is 0.000834, which satisfies the max cost per unit benefit value of 0.001. The custom constraint c_1 value of -485.44, c_2 value of -199.11, and c_3 value of -684.56 all satisfy the TPH specified minimum/maximum values of +/-500, +/-500 and +/-750 respectively.

#### Portfolio Approval Token

When the TPH returns to the CCS portal to approve the portfolio, they are prompted to enter the approval token. The TPH uses the value of the first field in the aggregate value row (i.e., row 2) of the portfolio detail output file as the approval token. In Example compression detail output file, the TPH would enter the value 1079.

Example compression detail output file is a table-based representation of a detail output file. Below is the actual CSV formatted content that corresponds to Example CCS Input with Custom Risk Constraints.

CSV formatted compression detail output file:

class,expiry,strike,put_call,qty,traded_qty,residual_qty,theo,compression_price,close_benefit, reserved,reserved,total_benefit,cost,cost_benefit,c_1,c_2,c_3

1079,,,,,,,,,,,,1801980.00,1502.35,0.000834,-485.44,-199.11,-684.56

,,,,,,,,,,,,,,,-500.00,-500.00,-750.00

,,,,,,,,,,,,,10000.00,0.001000,500.00,500.00,750.00

SPXW,2021-12-31,3900,C,50,-20,30,21253.36,21405.81,6645.60,,,132912.00,-3049.11,, -1238.245847,0.000000,-1238.245847

SPXW,2021-12-31,3900,P,50,-25,25,11253.36,11405.81,6645.60,,,166140.00,-3811.39,,952.192691, 0.000000,952.192691

SPXW,2021-12-31,4000,C,50,-50,0,15951.04,16110.42,6816.00,,,340800.00,-7968.78,,-2599.694029, 0.000000,-2599.694029

SPXW,2021-12-31,4000,P,50,-50,0,15951.04,16110.42,6816.00,,,340800.00,-7968.78,,2400.305971, 0.000000,2400.305971

SPXW,2021-12-31,4100,C,50,0,50,11639.87,11796.43,6986.40,,,0.00,0.00,,0.000000,0.000000,0.000000

SPXW,2021-12-31,4100,P,50,0,50,21639.87,21796.43,6986.40,,,0.00,0.00,,0.000000,0.000000,0.000000

SPX,2022-03-18,3900,C,50,0,50,27622.19,27425.34,6645.60,,,0.00,0.00,,0.000000,0.000000,0.000000

SPX,2022-03-18,3900,P,50,0,50,17622.19,17425.34,6645.60,,,0.00,0.00,,0.000000,0.000000,0.000000

SPX,2022-03-18,4000,C,50,-50,0,22548.79,22346.19,6816.00,,,340800.00,10130.28,,0.000000, -2640.929944,-2640.929944

SPX,2022-03-18,4000,P,50,-50,0,22548.79,22346.19,6816.00,,,340800.00,10130.28,,0.000000, 2359.070056,2359.070056

SPX,2022-03-18,4100,C,50,-10,40,18177.18,17975.19,6986.40,,,69864.00,2019.92,,0.000000, -458.627345,-458.627345

SPX,2022-03-18,4100,P,50,-10,40,28177.18,27975.19,6986.40,,,69864.00,2019.92,,0.000000, 541.372655,541.372655

## Revision History

| Version | Date | Description |
|---|---|---|
| 1.0.0 | 05/05/21 | Initial major revision corresponding to the introduction of Multilateral Compression functionality in the Cboe Compression Service. |
| 1.0.1 | 05/21/21 | Clarified guidance on floating point numeric input precision required for TPHs to be able to exactly replicate constraint values in compression detail output files. Added separate step to Figure 1 workflow to separate FIX Drop from Multicast PITCH and TOP compression trade dissemination. |
| 1.0.2 | 06/07/21 | Clarified that FLEX options not supported. Clarified that expired or contracts expiring the day of compression are not allowed for both Multilateral Compression and Match Data Service input files. Specified at least one custom risk constraint required in Multilateral Compression input. All zero close_benefit values not allowed in Multilateral Compression input. Custom risk constraint minimum values must be <= 0.0 and maximum values must be >= 0.0. Clarified that the Multilateral Compression trade output file presents total traded quantity for each option, whereas actual trades may comprise multiple fills per option. |
| 1.0.3 | 06/18/21 | Updated intraday timeline for hybrid multilateral and match data service, and match data service only days to reflect additional 10 minutes to upload files (cutoff now 16:50 ET). For multilateral dates, after 15 minutes of computation time, TPHs have 23 minutes between 17:05 and 17:28 to approve the compression portfolio. |
| 1.0.4 | 07/02/21 | Clarified that specification of max_cost_benefit value is required and not optional. |
| 1.0.5 | 07/28/21 | Added Clearing Capacity with allowed values M, N and F to the Service Registration section. Clarified that Market Maker Clearing Account required only if Clearing Capacity is M or N. Updated workflow to add Trade Data and Trade Details files to the methods by which TPHs can access CCS trade information from the exchange. |
| 1.0.6 | 08/12/21 | Removed document effective date as multilateral compression is now in production. |
| 1.0.7 | 10/12/21 | Indicated that compression schedule changes will be announced to certified TPHs via direct communication. Narrative regarding use of unconstrained mirror compression as part of the certification process was removed and will be updated in a future release. |
| 1.0.8 | 10/28/21 | Added L (Non-TPH Affiliate) to the list of allowed Clearing Capacity values. |
| 1.0.9 | 11/18/21 | Updated user manual to include system details of Phase 2D CAT reporting. Updated service registration data to include Firm Designated ID account identifier to use in CAT reporting of MONO events, and preference for exchange or self-submitting of IM data. |
| 1.0.10 | 12/27/21 | Changed input submission window from 16:50 ET to 16:45 ET. Clarified that compression analytics may complete prior to the scheduled 17:05 ET in which case output files are prepared and presented to TPHs prior to 17:05 ET. |
| 1.0.11 | 03/02/22 | Updated the example input file data in Figure 8 to correspond to the formatted input file example presented in Figure 9. |
| 1.0.12 | 03/13/23 | Removed references to match data service details, leaving only reference to multilateral compression to improve clarity. Increased maximum custom risk constraints from 1,000 to 1,500. |
| 1.0.13 | 10/27/23 | Added additional items to the "common causes of input file validation errors" list in section 3.1. |
| 1.0.14 | 02/11/25 | Updated with Cboe Titanium branding. |