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 number^{4 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.

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.

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.

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

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