Chicago Mercantile Exchange -- the SPANŽ Pages -- updated January 8, 1999  - under construction

SPAN Technical Specifications

SPAN version 4

Introduction

This document is intended to provide a detailed description of the procedure for calculating SPAN requirements -- in other words, the functional specification for the SPAN calculation algorithm.

This updated version of the SPAN algorithm is generically referred to herein as SPAN version 4, or just SPAN 4.  It describes functionality implemented in the upcoming Windows-based PC-SPAN version 4.

Since the CME introduced SPAN in 1988, the many exchanges and clearing organizations worldwide which have adopted SPAN have added many new features and enhancements.  SPAN 4 itself introduces many powerful new features.

The fundamentals of the SPAN calculation, however, and the principles behind them, have not changed.   The underlying simplicity of SPAN has been preserved.  The many new capabilities introduced with SPAN 4 should be thought of not as changes to the underlying methodology, but as providing a vastly greater degree of flexibility and control in the usage of SPAN.

The SPAN algorithm has always been viewed as being applicable to an unlimited range of product types, but the original focus in its implementation has been on standardized futures, options on futures and options on physicals.  Portfolios today, however, can contain the widest range of derivative and non-derivative instruments.  SPAN 4 supports the ultimate in product flexibility using the advanced, object-oriented model for defining products developed for the CME's Clearing 21 system.

In several important respects, the SPAN 4 methodology has been simplified and generalized.  For example, there is no longer any need for "commodity redefinition" in order to group products together across exchanges within a clearing organization, and the hard-coded spreading logic of several exchanges' unique spreading and delivery risk calculations, has been parameterized within the generic spreading process.

The SPAN calculation, summarized:

The base SPAN requirement for a combined commodity in the portfolio is calculated as:

The scan risk is the risk for a combined commodity in a portfolio assuming perfect correlations in price and volatility movements of the underlying instruments over time.

The intracommodity spread risk allows the recognition of risk associated with spreading within the combined commodity -- so-called calendar spreads -- for combined commodities where there is imperfect correlation of price and volatility movements over time, and allows precise targeting of these requirements to particular intracommodity strategies.

The delivery, or spot risk, recognizes the unique risk characteristics of physically deliverable products, and of derivatives based on such physically deliverable products, as they approach the delivery period or go through the delivery process.

The intercommodity spread credit provides appropriate credits recognizing risk offsets between positions in the different combined commodities represented in the portfolio.

The short option minimum recognizes the unique characteristics of short option positions, and allows the recognition of a minimum risk value for deep out-of-the-money short options.

Flexibility in the levels at which SPAN requirements are calculated

SPAN 4 provides new flexibility in the calculation of different levels of performance bond requirements for the same portfolio, by account type, by initial or maintenance designation, and by accepted asset classes.

Calculation by performance bond class

SPAN 4 allows the calculation of different levels of performance bond requirements for a particular portfolio, according to which classes of collateral assets are allowed to meet which requirements.

Each such level of performance bond requirements is called a performance bond class.   Any number of performance bond classes can be defined.   The first class is specially designated as the core class and the second class as the reserve class.

This capability is used at the CME for calculating clearing-level requirements for certain products.  For these products, both the core requirement and the higher reserve requirement are calculated.  The core requirement must be met by the highest-quality assets.  Lesser-quality assets may be used to meet the the reserve additional requirement -- ie, the difference between the reserve requirement and the core requirement.

Calculation by account type

SPAN 4 allows the independent definition of SPAN parameters, and the independent calculation of SPAN requirements, by account type and, for account types where the distinction is made, by initial or maintenance level.  (For such account types, the initial requirement applies only when the portfolio is entirely new, or when the valuation of collateral on deposit falls below the maintenance requirement.)

For example, in SPAN 4, you can specify a separate set of price and volatility scan ranges and the other SPAN rates for hedge, spec, and member account types.  Then you can calculate separate sets of risk arrays, and with these risk arrays, calculate separate SPAN requirements for these account types.

SPAN has always allowed calculation of different requirements by account type, but by simple multiplicative scaling from the base requirement level specified above, using the maintenance adjustment factors and the initial to maintenance requirements specified for a combined commodity -- not via independent calculations using independent inputs.   This new capability allows more precise targeting of margin requirements to desired risk coverage for the different account types.

For the calculation for any particular combined commodity, SPAN 4 allows some requirements to be calculated independently, and others to be calculated using multiplicative scaling.  Requirements calculated using by multiplicative scaling of other requirements, are referred to as derived requirements.

Rate definitions, rate ID's, and the SPAN risk parameter file

SPAN 4 uses the concept of a rate definition to define a particular requirement level, specifically:

Each rate definition is assigned a rate ID number to allow its designation by the specification of a single value.

The standard unpacked and packed formats for the SPAN file, and the expanded unpacked format, support the specification in a single SPAN file of risk arrays and other charge rates only for a single rate definition.

For example:  the CME plans shortly to begin publishing a separate, "member-rates" SPAN file, in addition to the regular file, which can be thought of as the "hedge customer rates" file.

The new XML-based SPAN 4 file format allows risk arrays and other SPAN charge rates to be provided for any number of rate definitions in a single file.  Thus, the CME's new XML-based SPAN file will contain risk array data for both hedge rates and member rates.

Exchange complexes

SPAN 4 continues to use the concept of an exchange complex.  Each standard-format unpacked or packed SPAN risk parameter file and each expanded-format file contains data for a single exchange complex at a point in time, which may be for:

The new XML-based SPAN 4 file format allows data for any number of exchange complex, at any number of points in time, to be contained in a single SPAN file.

Exchange product families

Specific products at each exchange are grouped into product families.   Generally, a product family is identified within an exchange by a product code -- an alphanumeric value, for example, SP at the CME for products related to the S&P 500 stock index -- and a product type -- for example, futures, options on futures, etc.   Each product family is also assigned a product family ID number which is unique within the exchange.

Product families may be defined in as specific a manner as desired.  For example, at the CME, other parameters used to make product families unique include the settlement method (cash-settled or physically deliverable), the valuation method (futures-style or equity-style), the settlement currency, and, for options, the exercise style (American or European).  Contract size may also be used to as a factor which defines separate product families, although SPAN also supports the inclusion of contracts of different sizes in the same product family.

Combined commodities

SPAN 4 continues to use the concept of a combined commodity, which is a grouping of related product families for the SPAN calculation within a portfolio.   SPAN calculates a requirement for each combined commodity in a portfolio, in the performance bond currency defined for that combined commodity.

The combined commodity can be thought of as the atomic-level of the SPAN calculation.  Typically, all products on the same ultimate underlying physical are grouped together into a combined commodity -- for example, at the CME, all products related to the S&P 500 stock index.

In a significant enhancement, in SPAN 4 combined commodities are defined at the exchange-complex level, not the exchange-level, as formerly.  This eliminates any need for the complexities of "commodity redefinition", as utilized by some exchanges and clearing organizations.

Contract structure

In SPAN, tradeable instruments, whether derivative or non-derivative, are generically referred to as contracts or as products.  As described above, contracts are grouped together in product families, and product type is always something that makes a product family unique.  Every contract is assigned a contract ID number which is unique within the product family.

SPAN 4 allows the creation of any number of product types.  Product types may be for physicals or derivatives and, if the latter, for combination or non-combination products.

Every non-combination derivative product has a single underlying product.   Every combination derivative product has two or more underlying products.   For example, the underlying of an option on a future, is the future itself.   The underlyings of a futures calendar spread, are the futures which are the individual legs of a spread.

The set of underlying contracts for a derivative product, is known as its contract structure.  Each element in the contract structure not only identifies an underlying contract, but also specifies whether buying the contract means buying or selling that particular underlying, and how many.  For example, the contract structure for a futures butterfly spread would specify that buying one spread means buying one of the first future, selling two of the second future, and buying one of the third future.

Product types defined in SPAN 4 at this time include equity security and debt security subtypes of the physical type.  Swaps, repos and reverse repos are recognized as subtypes of the combination type.

Contract periods and option series

The concept of contract period is used in SPAN to denote products with different maturities or expirations.  Contract period can be thought of as a generalization of the old contract month concept.

Contract periods are eight-byte alphanumeric values with the following structure:

For contracts with standard monthly expirations, the last two bytes of the contract period code are specified either as blanks or as 00.   For example, the December 1999 contract may be known as the 199912 or 19991200 contract.

The abbreviations W1 through W5 are used as the last two bytes of the contract period code for contracts with standard weekly expirations.  For example, the contract period code 199912W3 refers to the standard expiration in week three of December, 1999.

For contracts with expirations defined to a specific day of the month, the last two bytes of the contract period code specify that date.  For example, 19981222 denotes products expiring on December 22, 1998.

For contracts where it is desired to distinguish between multiple expirations or maturities within a single day, the contract cycle code may optionally be specified.  For example, the contract cycle code could be used to distinguish between contracts settling on open versus contracts settling on close.

An option series in SPAN 4 consists of all options with the same expiration and the same underlying.  Standard options within a series, then, differ from each other only in their strike price and their option right -- ie, whether they are puts or calls.  For more exotic options, such as barrier options, they may also be distinguished by one or more barrier prices.

Tiers and Tiered Processing

A tier in SPAN is a contiguous range of contract periods within a combined commodity.  For example, SPAN has long supported the parameter-driven specification of specific intracommodity spread tiers.  Specific legs of particular intracommodity spreads, then specify particular intracommodiy spread tiers.

To provide the utmost flexibility, tiered processing is supported in SPAN 4 for:

Specific tiers of a particular type for a combined commodity are always identified by a tier number beginning with one, and are further qualified by a beginning period code and an ending period code.

For intra- and inter-commodity spreading, sometimes there are cases where more than one tier is defined, but it is desired in a particular leg of a spread to reference the entire combined commodity, across all tiers.  To support this, SPAN recognizes for each combined commodity an intracommodity spread tier zero and an intercommodity spread tier zero, which are defined as the range of period codes for the entire combined commodity, crossing individual tiers.

To be continued...


[ CME HOME PAGE | SPAN HOME PAGE | E-MAIL THE CME ABOUT SPAN ]