ice span array file format · ice clear europe. users of the sp6 file format within back office...

SPAN for ICE

SPAN Array File Formats

Version 3.2-Final

15 May 2012

Version History

2.3 Introduction of Position Allocation Enhancement.

2.4 Introduction of Volatility Credit Enhancement.

2.5 Improved description of Volatility Credit calculation and provision of worked examples.

2.6 Introduction of Customer Margin Ratios to support DFA / CFTC Rules.

3.0 Separate FX version of Specification.

3.1 Consolidated Specification covering Energy and FX and incorporating specifications for Position

Allocation, Volatility Credit and Customer Margin Ratios. Customer Margin Ratios are applicable to

both Energy and FX.

3.2 FX Arrays will be published under the “F”/”ICFX” exchange identifier to maintain logical separation

of data between Energy and FX arrays should anyone wish to concurrently margin customer positions

containing both FX and Energy positions. Update descriptions accordingly.

ICE Clear Europe – SPAN Array File Formats – 3.2-Final 15 May 2012

Contents

1 INTRODUCTION ........................................................................................................................................... 3

2 GENERAL ........................................................................................................................................................ 6

3 PROCESSING THE ENHANCED RECORD TYPES IN SPAN FOR ICE ............................................... 9

4 RECORD FORMATS - CSV ........................................................................................................................ 21

5 RECORD FORMATS – SP5........................................................................................................................ 32

6 RECORD FORMATS – SP6........................................................................................................................ 40


1 Introduction

1.1 Background

This document contains details of the format of the SPAN®1

Array Files published by ICE Clear Europe (the

Clearing House).

The Clearing House calculates margins using the SPAN methodology. SPAN was developed by the CME and the

Clearing House presently utilises London SPAN Version 4 (London SPAN).

This document is a consolidated specification covering all published formats of the Clearing House SPAN Arrays

and covers those published for both Energy and FX products.

1.2 Final SPAN Array Files

The Clearing House publishes Final SPAN Array files at the end of each business day. The Final SPAN Array File

is utilised by the Clearing House to margin Member positions and may be used by Clearing Members to calculate

margin on their own Customer accounts and to verify the margin calculation undertaken on their own accounts.

The Final SPAN Array files reflect and are based upon the complete and authorised end of day settlement prices for

all contracts.

1.3 Early SPAN Array Files (Energy Products Only)

The Clearing House publishes Early SPAN Array files that may be used, under guidance from the Clearing House

as a contingency measure in the event that significant end of day processing issues prevents the publication of Final

SPAN Array files.

Early SPAN Early Array files are generated on an incremental basis through the evening settlements process and

each iteration of the Early file that is generated reflects the latest set of contract prices settled and the arrays

associated with those contracts. At any stage prior to finalisation of all settlements, the Early SPAN Array file will

reflect an incomplete set of data. The Early SPAN Array file also reflects contract prices prior to the point at which

the Clearing House has concluded its price verification process.

Early SPAN Array files should not be utilised within regular operations as these may be incomplete and/or reflect

price data not yet approved.

In the event that the Clearing House believes that Members might benefit from use of the Early SPAN Array file,

then, the Clearing House will inform Members of the status of data within the current version of the early file and

thus Members will be in a position to determine whether they wish to utilise this file rather than suffer further

delays to their end of day processing, The Clearing House has also implemented a facility within its own systems

that allows recycling of previous day’s price data for any contracts for which prices are missing and thus use this

data to “complete” the Early SPAN file.

More information regarding publication and use of the early SPAN file can be found on the following circular:

https://www.theice.com/publicdocs/clear_europe/circulars/C110035.pdf

1.4 London SPAN 4 Enhancements

The Clearing House has identified several areas where, in order to optimise and improve calculation of Margin, it

will enhance the London SPAN 4 specification.

1.4.1 Position Allocation (Applicable to Energy Only)

The new version of ICE SPAN Arrays incorporates a Position Allocation methodology. This feature will be

utilised in the cases of certain products whereby the position is subjected to a transformation into one or more

alternate products prior to the application of the existing London SPAN 4 margining logic, i.e. prior to the

Scanning Risk calculation step. This change should be regarded as a position pre-processing step and does not

require any change to the existing core logic within London SPAN 4.

The implementation within the SPAN Array file, applicable record type and methodology are described later in this

document (See 0).

Member systems may choose to ignore the Position Allocation records that define the above and thus bypass the

position allocations step. However, whilst this will still yield a margin calculation result, that result will be less that

1 SPAN is a registered trademark of Chicago Mercantile Exchange Inc., used herein under license. Chicago Mercantile Exchange Inc.

assumes no responsibility in connection with the use of SPAN by any person or entity.

https://www.theice.com/publicdocs/clear_europe/circulars/C110035.pdf


that calculated when the allocations are applied. This would then result in Members under-margining those clients

that hold positions in any products to which position allocation is applied.

If the Member does not have any clients with positions in products to which position allocation applies, then,

clearly, ignoring the Position Allocation records will have no impact on margin calculation.

The changes described will be implemented in June/July 2011

1.4.2 Incorporation of Volatility Credit within Inter-Contract Credit Calculations under method 10 (Applicable to Energy Only)

Inter Contract Credit Method 10 currently calculates inter-contract credits based on Futures Price Risk. This credit

reflects the delta based correlation between the two (or more) contracts to which the credit is applied. This

mechanism does not include any credit in respect of volatility correlation in the event that the scanning risk on

which this credit is based also comprises correlated volatility risk.

ICE Clear Europe has incorporated a change within the determination of inter-contract credits calculated using

Method 10 that will yield a credit in respect of option vega, a Volatility Credit, in addition to the Futures Risk

Component.

This change necessitates the calculation/determination of option vega within each inter-contract tier. The vega is

“consumed” in a fashion similar to inter-contract tier delta in order to generate a Volatility Credit which is added to

the existing Inter-Contract Credit for that Inter-Contract Spread.

1.4.3 Customer Margin Ratios (Applicable to FX and Energy)

As part of the introduction of new regulations in the US (Dodd Frank Act) and the related rules issued by the

CFTC, ICE Clear Europe, as a DCO (Designated Clearing Organization) is required to specify a minimum amount

by which a Clearing Member increases the margin in respect of certain types of customer, over and above the

amount that would be determined on that customer position by the DCO.

The relevant text of this rule can be found in the CFTC Rules, 39.13(g)(8)(ii).

In order to facilitate the automation of the process of determining that amount of this add-on and processing this

within Member systems, it has been determined that additional data should be incorporated within the SPAN data

file.

Please refer to sections 3.5 and Error! Reference source not found. for a full description of the additional record

ype and the allied data content.

Please refer to section 5.16 for a description of the SP5 fixed record format applicable to Energy products and to

section 6.16 for a description of the SP6 fixed record format applicable to FX products.

1.4.4 Inter-Contract Spread Method 11 (Applicable to FX Only)

In order to calculate inter-contract credits between FX contract positions, the Clearing House has introduced an

additional methodology for calculation on inter-contract credits.

The Clearing House currently adopts use of Method 10 for all Energy products, however, this method does not

support FX.

Method 11 is a simple derivation of Method 10 in that it involves a simple change to a single step within the

calculation of the Weighted Futures Price Risk (WFPR) used in determination of Inter-Contract Credit.

Within Method 10, WFPR is determined as an integer rounded amount whereas, in Method 11, WFPR is

determined as a non-rounded value. It is necessary to utilise a non-rounded value given, that when applied to FX,

the amount of Futures Risk / Delta that yields WFPR will typically be a value less than 1; hence a value of 0 or 1

once rounded.

1.5 SPAN Array Formats

In order to address slightly differing needs in respect of different products, the Clearing House currently publishes

SPAN array files in different formats:

for Energy Products in SP5 and CSV format; and

for FX, in SP6 and CSV format.

SP5 is a fixed record length format and is compatible with various third party software applications including CME

PC-SPAN and is typically used by back-office platforms.


SP6 is also a fixed record length format. The SP6 format supports larger sized fixed fields than SP5, for certain

values, where these are required to support larger precisions etc. SP6 has been introduced specifically to support

users requiring a fixed format array representation for margining of FX positions.

The Clearing House SPAN for ICE margining tool supports both CSV and SP5 format SPAN Arrays published by

ICE Clear Europe. Users of the SP6 file format within back office systems are advised to make use of the CSV

format when using SPAN for ICE. The Clearing House is deprecating use of fixed format files with SPAN for

ICE.

1.5.1 SPAN Margin Group, Contract Group, Exchange Code

SPAN Arrays contain contextual data relating to the “market” to which they apply and that, historically, might be

used to determine certain aspects of SPAN behaviour when positions relating to multiple markets are margined

collectively.

Within any one set of arrays (i.e. SPAN Array file), only one set of values (relating to Energy or to FX) will be

used.

Initial Margin Group is used to “control” the application of NLV credits (arising from long positions in premium

paid up-front options) to the offset of Initial Margin. Where Products have a common Initial Margin Group, an

NLV credit determined in respect of one product can be used to offset IM (and NLV debit) in respect of any other

product within the same group. The Initial Margin Group is one of:

IPE – for ICE Energy

ICFX – for ICE FX

Contract Group is used to create “logical” collections of SPAN Inter-contract Credits. Inter-contract credits have

a priority number that is unique within a Contract Group. As SPAN can apply inter-contract credits between

products (SPAN Combined contracts) that reside within different Exchanges and Initial Margin Groups and for

which the arrays themselves are “delivered” in different SPAN array files, the Contract Group acts as a primary key

allowing separation of inter-contract spreads that are described in one file from those in another. This behaviour is

not used. However, to ensure that no conflicts within the published ICE arrays might arise, the Contract Group is

one of:

Blank – for ICE Energy

ICFX – for ICE FX

Exchange Code is used, by ICE, to identify the market segment to which the arrays relate. A SPAN array file will

only contain arrays that relate to a single segment and will be one of:

I – for ICE Energy

F – for ICE FX


2 General

2.1 File Naming and Download Locations (Energy)

The file naming convention for these files varies according to the location from which they are downloaded. The

following table summarises the naming convention based upon publishing location:

ICE Web Site ICE File Transfer CME Ftp Site

https://www.theice.com/SpanFiles.shtml?iceClearEurope=

MFT

Via sftp:

[email protected]

Password: euspan

Note that MFT does not support http/https access, only sftp.

AFTS

Note AFTS is being decommissioned during June 2012 and access to arrays will be provisioned via MFT (See Above)

Via https: https://euafts.theice.com

User: euspan

Password: euspan

Via sftp: [email protected]

Password: euspan

ftp://ftp.cmegroup.com/pub/span/data/ice/

Fin

al

SP

5 IPEMMDDF.SP5

ZIP archive named IPEMMDDF.SP5.ZIP.

Naming as per Web Site Ice.YYYYMMDD.pa5 contained in a

ZIP archive named ice.YYYYMMDD.pa5.zip. E.g.

ice.20091005.pa5.zip.

CS

V IPEMMDDF.CSV

ZIP archive named IPEMMDDF.CSV.ZIP

Naming as per Web Site Not Available

Ea

rly

SP

5 IPEMMDDE.SP5

ZIP archive named IPEMMDDE.SP5.ZIP.


CS

V IPEMMDDE.CSV

ZIP archive named IPEMMDDE.CSV.ZIP


Where:

YYYY is the Year (e.g. 2009) of the Business Date, MM is the Month of the Business Date, DD is the Day of the

Business

2.2 File Naming and Download Locations (FX)

FX SPAN Arrays will be published on both the ICE Public Web Site and on the ICE file transfer service.

FX SPAN Arrays may be accessed “manually” using http from the ICE Web site or using sftp from the ICE File

Transfer Service (MFT). FX SPAN Arrays may be downloaded “automatically” using sftp from the ICE File

Transfer Service.




mailto:[email protected]

https://euafts.theice.com/





ICE Web Site ICE File Transfer

Page Not yet defined

Via sftp: [email protected]

Password: euspan

Where the user has been assigned a system access account for use with the ICE File Transfer Service, then, this may be used as an alternative.

CS

V ICFXyyyymmddF.CSV

ZIP archive named

ICFXyyyymmddF.CSV.ZIP

Naming as per Web Site

SP

6 ICFXyyyymmddF.SP6

ZIP archive named

ICFXyyyymmddF.SP6.ZIP

Naming as per Web Site

Where:

yyyy is the Year (e.g. 2009) of the Business Date, mm is the Month of the Business Date, dd is the Day of

the Business

All SPAN Array files are published in compressed, ZIP, format.

2.3 File Structure

The file comprises records of different types, described in the following sections.

Each record contains a record type which always appears as the first (Integer) value in the comma separated values

on any line of the file.

Certain records may contain variable numbers of elements and where this is the case, this is described in the record

layout.

SPAN arrays are arranged as a hierarchy of data records

The general structure of the file is described below:

Record Types 10 -16 define Common Data. Where SPAN is used in a multi-market (multi-exchange)

environment, these records define data that is common across this environment (for example inter contract

spreads that traverse multiple markets).

Record Type 20 Defines an Exchange (Market) and acts as a “grouping” for all the records that follow either

to the end of file or until the next Record Type 20. All records (Types 30, 40, 50, 60) that follow record 20 are

defined within the context of the Exchange record.

Record Type 30 acts as a grouping in respect of a Combined Commodity. The record types 31-36 that

follow define specific tiers and spreads relating to the Combined Commodity. Following this, then, the Risk

Arrays themselves (Record 60, Series Details) are defined within a hierarchy for each Contract (Record 40),

Contract Expiry (Record 50).

The general structure of a SPAN array file is as follows:

10 SPAN File Header Record

11 Contract Type Mapping Records

12 Currency Details

13 Currency Conversion Details

14: Intercontract Spread Details

15: Scenario Descriptions

16: Margin Group Descriptions



20 Exchange Details

21 Position Split Allocation Details

30 Combined Contract Details

31 Month Tier Details

32 Leg Spread Details

33 Prompt Date Charge Details

34 Intercontract Tier Details

35 Strategy Spread Details

36 Customer Margin Ratios

40 Contract Details

50 Contract Expiry Details

60 Series Details

60 Series Details


60 Series Details

60 Series Details

40 Contract Details


60 Series Details

60 Series Details


60 Series Details

60 Series Details

30 Combined Contract

repeated sequence of record types 40, 50, 60

30 Combined Contract

repeated sequence of record types 40, 50, 60

Logically there may be iteration of the record group 20, 30, 40, 50, 60. However, a single ICE array file will

contain details relating to ONE “exchange” only.

2.4 Field Format

All values within a file are represented in text (i.e. ASCII) form; the file contains no “binary data”.

For each field within the record definitions, the following information is given:

For Fixed format records, the field length, starting and ending character position.

Field Type.

Optional indicator (a "Y" means the field is optional). For records that contain variable numbers of elements,

the optional indicator is Y.

Field name and description.

The field types are as follows:

String Alphanumeric String - any printing ASCII. Values are quoted (i.e. contained in “ “ characters.

The quotation marks should NOT be treated as part of the value.


Strings will not contain leading or trailing spaces. For values such as Combined Commodity (e.g. “BRN”, “G”) care must be used to ensure that internal systems that may treat these values as fixed strings (e.g. “BRN”, “G ” handle such values appropriately.

Integer Integer number with an optional sign (-) prefix. Value should be processed as an Integer.

Numeric values are not presented in quotation marks.

Real Floating point number, optional sign (-) prefix. Value should be processed as a real.

Numeric values are not presented in quotation marks.

Date Date in format YYYYMMDD.

Where date represents a month, e.g. the expiry month of a future or option, then the DD component will be 00.

Treated as a numeric value and not presented in quotation marks.

NOTE: Where no date is required, a NULL date is represented by an EMPTY String, i.e. “”.

Time Time in format HHMMSS. Treated as a numeric value and not presented in quotation marks.

NOTE: Where no time is required, a NULL date is represented by an EMPTY String, i.e. “”.

3 Processing the Enhanced Record Types in SPAN for ICE

This section describes the methodology for processing of the additional record types that appear within the SPAN

for ICE Array files beyond the base specification relating to London SPAN 4. The methodology for processing of

London SPAN 4Arrays is described in the London SPAN Technical Information Pack available on the Internet.

3.1 Inter-contract Spread Method 11 (Applicable to FX Only)

The calculation of Weighted Futures Price Risk under Method 10 is described as:

a) Select an inter-contract tier within the group that forms inter-contract spreads for this portfolio.

b) Divide this inter-contract tier's Futures Price Risk by the absolute value of its total net delta and round to

whole currency units. The result is the Weighted Futures Price Risk for this inter-contract tier.

c) Repeat steps a) and b) for each inter-contract tier that forms inter-contract spreads for this portfolio.

By contrast, the calculation of Weighted Futures Price Risk under Method 11 is described as:

a) Select an inter-contract tier within the group that forms inter-contract spreads for this portfolio.

b) Divide this inter-contract tier's Futures Price Risk by the absolute value of its total net delta and retain

WFPR as non-rounded, real value. The result is the Weighted Futures Price Risk for this inter-contract

tier.

c) Repeat steps a) and b) for each inter-contract tier that forms inter-contract spreads for this portfolio.

With Method 11, the resulting, non-rounded WFPR is used in subsequent calculations in the same manner as the

value calculated in Method 10.

3.2 Position Split Allocation - Processing Record 21 (Applicable to Energy Only)

3.2.1 Background

London SPAN 4 supports only two ways to combine positions in different products that share similar risk profiles.

a) Equivalent positions

In cases of identical risk and pricing behaviour SPAN combines two (or more) physical commodity codes

into one logical commodity code. This concept is used today to offset the physical commodity codes H and

PHH and group them into one logical commodity code HNG.

b) Inter-commodity offsets


Inter-commodity offsets are used to combine correlated products. It is widely used by the Clearing House

to combine logical commodity codes with similar, but not identical risk and pricing behaviours. A wide

range of tier structures are used to enable an efficient use of Inter-commodity offsets and address the fact

that positions might have a high correlation at similar maturity points, but low correlations when two

logical commodity codes are combined with non-matching maturities.

To overcome the limitations of these simple approaches, the Clearing House is introducing the concept of Position

Split Allocation.

Position Split Allocation is typically used for positions in combinations and/or options on combinations where the

underlying instruments of the combinations are in different physical commodities. With this feature, the position in

the combination or the option on the combination is split out (allocated) into positions on the underlying

instruments of the combination. A position split allocation then considers only the delta from the position in the

combination or the option on the combination. This method allows a position in one product to be expressed as an

equivalent set of positions in other, underlying, products. This then allows the components that make up the

combination to each be margined with other positions within what are highly correlated underlying products rather

than seek to express these correlations using inter-commodity spreads.

Position Split Allocation processing is applied to a portfolio prior to presenting the resulting positions to the

standard SPAN processing algorithm. As such, this should be considered a position pre-processing step rather than

a fundamental change to the London SPAN algorithm. This approach to implementation of this functionality has

therefore been designed to minimize the implementation effort and avoid core structural change within any user

implementation of the London SPAN algorithm.

London SPAN will continue to work under the current semantic and logic with any existing implementation of the

London SPAN 4 algorithm not ready to use the new record type still functioning by either ignoring the new record

type or by using the standard arrays. An algorithm that uses the Standard SPAN Arrays or that ignores Record 21

will still yield computation of valid margin results; these results will, in all cases, simply be higher than those

yielded by the application of the Position Split Processing.

3.2.2 Method

Application of Position Split Allocation records is undertaken before the first processing step within SPAN, that of

calculation of Scanning Risk.

Prior to submitting positions to the SPAN processing algorithm, all positions are subjected to pre-processing

specified by the Position Split Allocation records (Record 21).

The Method is applied to Source Positions as follows:

For each Source Position

Look up set of of Record 21s that have the same Contract Code, Contract Type, Expiry Date and Strike Price to the Source Position

If we found corresponding Record 21s for the Source position,

then

For each Record 21 we found

Create an output position with:

Contract Code = Mapped Contract Code

Contract Type = Mapped Contract Type

Expiry Date = Mapped Expiry Date

Strike Price = Mapped Strike Price

Volume = Source Position Volume x Delta

Note that the original source position has been discarded and replaced by one or more positions in the mapped contracts and in the quantities determined by the mapped deltas. The original Source Position is not copied to the Output.

Process Next Record 21

Else, we found no corresponding Record 21s for the Source Position, so


Copy the Source Position to the Output position

Note that where no position split allocation records are defined in respect of a contract, the original positions simply pass through the process.

Go to the next Source Position

NOTE ABOUT ROUNDING: Whilst, conventionally, the position quantity would typically be an integer quantity,

for the purposes of position split allocation, the result of the Volume x Delta calculation should be preserved as a

floating/real/decimal amount and not subjected to rounding.

Having applied this position transformation logic to the source positions and having created the output positions,

these output positions are presented to the London SPAN 4 algorithm in its traditional form.

3.3 Example

Source Position

Contract Code

Contract Type

Expiry Date Strike Price Position

CSO C 20110100 400 50

T F 20110200 25

T F 20110100 -25

Position Split Allocation Records (Record 21)

Record Type

Contract Code

Contract Type

Expiry Date Strike Price

Mapped Contract Code

Mapped Contract Type

Mapped Expiry Date

Mapped Strike Price

Delta

21 CSO C 20110100 400 CSO C 20110100 400 1

21 CSO C 20110100 400 T F 20110100 0 +0.6

21 CSO C 20110100 400 T F 20110200 0 -0.6

Output Position

Contract Code

Contract Type

Expiry Date Strike Price Position

CSO C 20110100 400 50

T F 20110100 +30

T F 20110200 -30

T F 20110200 +25

T F 20110100 -25

The positions shaded are those that originate from the application of the Position Split Allocation records.

To illustrate the effect of the application of those records on the original position, we can obviously sum/aggregate

the resultant position, which is now:


Physical Commodity Code

Contract Type

Expiry Strike Position

CSO C 20110100 400 50

T F 20110200 -5

T F 20110100 5

3.4 Volatility Credit (Inter-Contract Credit Method 10) – Processing Record 14 (Applicable to Energy Only)

Inter Contract Credit calculations performed under Method 10 are being enhanced to yield a credit in respect of the

Volatility Risk component in addition to the Futures Risk Component.

The principle of the Volatility Credit is based on generating credits based on offsetting the Vega inherent in one

Combined Contract with “opposite” Vega within another Combined Contract.

In order that the Vega offsets (Volatility Credits) can be applied at the same time as the existing inter-contract

spreads (delta based spreads driven by Futures Price Risk and deltas), the Vega at the Combined Contract level

must be apportioned at the inter-contract tier level.

Having determined these Inter-Contract Tier Vega amounts, these form the basis for calculation of the Volatility

Credit.

3.4.1 Overview of Process

The steps involved in calculation of the Volatility Credit are as follows:

a. Calculate the Combined Contract Vega (See 3.4.3)

b. Pro-Rate the Combined Contract Vega to Inter-Contract Tiers (See 3.4.3)

c. Within Inter-Contract Spread Calculations, incorporate calculation of Volatility Credits (See 3.4.4)

3.4.2 Technical Description

In order to contrast the addition of Volatility Credit to the existing method, a description of the current method and

new method are provided below.

3.4.2.1 Current Method 10 Implementation

For each Record 14 (an Inter-contract Spread)

Calculate Inter-Contract Credit

For each leg in this Inter-contract Spread:

Calculate WFPR Delta

Calculate Scanning Risk within Inter-Contract Tier

Calculate Futures Price Risk

Calculate Volatility Risk

Calculate Time Risk

Calculate Weighted Futures Price Risk (WFPR) = ROUND(Futures Price Risk / WFPR Delta)

For this set of legs:

Determine the number of Delta Spreads

For each leg in this Inter-contract Spread

Calculate Inter-Contract Credit = WFPR x Delta Ratio x Credit Rate x Delta Spreads, where, Credit Rate is defined in Credit Rate field within Record 14.

Reduce Absolute Delta for this leg by Delta Spreads x Delta Ratio

3.4.2.2 Method 10 Implementation including Volatility Credit


For each Record 14 (an Inter-contract Spread)

Calculate Inter-Contract Credit

For each leg in this Inter-contract Spread:

Calculate WFPR Delta

Calculate Scanning Risk within Inter-Contract Tier

Calculate Futures Price Risk

Calculate Volatility Risk

Calculate Time Risk

Calculate Weighted Futures Price Risk (WFPR) = ROUND(Futures Price Risk / WFPR Delta)

If this is first time this Combined Contract/Inter-Contract Tier has participated in an Inter-contract spread, Calculate Inter-Contract Tier Vegas (see 3.4.3)

For this set of legs:

Determine the number of Delta Spreads

If the Offset Rate > 0

Determine the number of Vega Spreads (See 3.4.4)

For each leg in this Inter-contract Spread

Calculate Futures Price Risk Credit = WFPR x Delta Ratio x Credit Rate x Delta Spreads, where, Credit Rate is defined in Credit Rate field within Record 14. Futures Price Risk Credit is rounded to 0dp.

Reduce Absolute Delta for this leg by Delta Spreads x Delta Ratio

If the Offset Rate > 0

Calculate Volatility Credit = Vega Spreads x Offset Rate, where Offset Rate is defined in Offset rate field within Record 14. Volatility Credit is rounded to 0dp.

Reduce Absolute Vega for this leg by Vega Spreads

Calculate Inter-contract Credit = Futures Price Risk Credit + Volatility Credit

3.4.3 Calculation of Inter-Contract Tier Vega

Calculation of Inter-Contract Tier Vega first requires calculation of the Combined Contract Vega. Once we have

done so, we then pro-rate the Combined Contract Vega to the Inter-Contract Tiers.

3.4.3.1 Calculate Combined Contract Vega

Computation of Combined Contract Vega is based on the identification of the worst case loss scenario for that

Combined Contract; i.e. the SAME scenario as determines the Scanning Risk:

Identify the scenario yielding the worst case loss (i.e. Scanning Loss) for the Combined Contract and call

this S1 and the associated loss, L1 (L1 is the Scanning Risk)

Identify the paired scenario of S1 and call this S2 and the loss, L2

If the scenario S1, is ODD numbered then Combined Contract Vega = (L1 - L2) / 2, otherwise Combined

Contract Vega = (L2 - L1) /2.

For example:

o Combined Contract, BRN has a worst case loss (Scanning Risk) of 1000 as determined by scenario

10, which has paired scenario 9).

o Paired Scenario 9 has a scanning loss of -200; the odd numbered scenario.

o The Combined Contract Vega, is then, (-200 – 1000) / 2, i.e. -600.

o NB positive values of scanning loss indicate loss.

Computation of Combined Contract Vega can be determined at the same time as calculating scanning risk

for the Combined Contract.


3.4.3.2 Pro-rata Combined Contract Vega to Inter-Contract Tiers – Calculate Inter-Contract Tier Vega.

Having determined the Combined Contract Vega we need to apportion this to the Inter-Contract Tiers in order that

we can use this as the basis for calculating Volatility Credits.

The Combined Contract Vega is distributed on a pro-rata basis and is determined by the Vega within the Inter-

Contract Tier.

The Vega inherent in an Inter-Contract Tier is not always of the same direction (ie sign) as that of the Combined

Contract and is therefore is only prorated to those Inter-Contract tiers that have Vega of the same direction as that

of the Combined Contract Vega.

To determine the Inter-Contract Tier Vegas, we follow these steps:

Total Original Inter-Contract Tier Vega = 0;

For Each Inter-contract Tier for this Combined Contract:

o Calculate Original Inter-Contract Tier Vega by identifying the total scanning losses within this

inter-contract tier corresponding to scenarios S1 and S2 from 3.4.3.1;

o If the scenario S1, is ODD numbered then Original Inter-Contract Tier Vega = (L1 - L2) / 2,

otherwise Original Inter-Contract Tier Vega = (L2 - L1) /2;

o If the Original Inter-Contract Tier Vega is the same direction (i.e. Sign) as the Combined Contract

Vega, then add this to the running total Total Original Inter-Contract Tier Vega;

o NOTE

S1 and S2 here are not necessarily the same scenario pair used, at Inter-Contract Tier level

to determine Futures Price Risk etc.;

The sum of Original Inter-Contract Tier Vega will be equal to the Combined Contract

Vega;

The Total Original Inter-Contract Tier Vega may not equal the Combined Contract Vega

as it only includes vegas of the same direction (sign) as the Combined Contract Vega.

Now, apportion the Combined Contract Vega to the Inter-contract Tiers using the Original Inter-Contract Tier

Vegas and Total Original Inter-Contract Tier Vega we calculated above.

For Each Inter-contract Tier for this Combined Contract:

o If Original Inter-Contract Tier Vega is same direction (sign) as Combined Contract Vega,

Then,

Inter-Contract Tier Vega = Combined Contract Vega x (Original Inter-Contract Tier Vega /

Total Original Inter-Contract Tier Vega)

Otherwise,

Inter-Contract Tier Vega = 0

For example:

o Combined Contract, BRN has a Combined Contract Vega of -600 which we determined based on

scenarios 9 and 10. (See 3.4.3.1)

o Let us assume that BRN has 3 Inter-contract Tiers for which we determine Inter-Contract Tier

Vega based on the scanning losses, within each tier relating to scenarios 9 and 10:

ICT

Tier

Scenario 9

Loss

Scenario 10

Loss

Original

ICT

Vega

1 -3000 -1000 -1000

2 4000 1000 900

3 -2000 -1000 -500

Total -600


o As the Combined Contract Vega is a negative amount, we will only apportion to tiers 1 and 3; Tier

2 is a positive value so will be 0. The sum of the Original Inter-Contract Tier Vegas (that are same

sign as Combined Contract Vega), is then -1000 + -500, i.e. -1500.

o This results in Inter-Contract Tier Vegas as follows:

ICT

Tier

Scenario 9

Loss

Scenario 10

Loss

Original

ICT

Vega

Formula ICT Vega ICT Vega

1 -3000 -1000 -1000 (-1000/-1500) x -600 -400

2 4000 1000 900 0 0

3 -2000 -1000 -500 (-500/-1500) x -600 -200

Inter-Contract Tier Vega can be determined at the same time as calculating scanning risk for the Combined

Contract.

3.4.4 Calculation of Vega Spreads and Volatility Credit

Calculation of the Vega Spreads and Volatility Credit can be undertaken at the same time as calculation of the

existing delta based credit.

Conceptually, determination of Vega Spreads, based on the Inter-Contract Tier Vegas uses the same approach as

determining delta spreads. Unlike the determination of delta spreads, calculation of the Vega Spread does not

involve a Ratio; Vega is an amount of money.

The Vega Spread is computed based on the same spread details as the Delta Spread (ignoring the ratio), i.e. the

Combined Contract and Side pairs/triples/quads expressed in Inter-Contract Spread records (ie Record 14). The

rate applicable to the Vega Spread (to determine Volatility Credit) utilises the Offset Rate (where Delta Spreads

utilise the Credit rate).

Vega Spreads are only determined if there is an Offset Rate specified. Vega Spreads are not formed and

consequently, yield zero Volatility Credit, where the Offset Rate is zero. This avoids “consuming” inter-contract

tier vega which that yields no credit; the vega may be used in a later spread to yield a credit.

It is important to note that an inter-contract spread may yield Futures Credit, Vega Credit or both. It is possible that

Inter-Contract Tier Vega can be offset (and credits generated) after all delta has been consumed and vice-versa.

It is important to remember that the amount of Inter-Contract Tier Vega on each Inter contract Tier be reduced by

the number of Spreads formed.

Example:

Take the following Inter-Contract Spreads (as defined by record 14):

Commodity 1 ICT Tier No Commodity 2 ICT Tier No Offset rate

BRN 1 BSP 1 0.93

BRN 1 BSP 2 0.89

BRN 1 BSP 3 0.87

BRN 2 BSP 2 0.92

BRN 2 BSP 3 0.86

BRN 3 BSP 3 0.88

Take the following BRN Inter-Contract Tier Vegas and BSP Inter-Contract Vegas

Comb.

Contract

ICT

Tier

ICT Vega

BRN 1 -400


BRN 2 0

BRN 3 -200

Now we calculate the Vega Spreads and Volatility Credits

Commodity 1

ICT Tier No

ICT Vega before Spread

ICT Vega After Spread

Commodity 2 ICT Tier No

ICT Vega

Before Spread

ICT Vega After Spread

Vega Spreads

Offset rate

Volatility Credit PER SIDE

BRN 1 -400 -200 BSP 1 +200 0 200 0.93 186

BRN 1 -200 0 BSP 2 +300 +100 200 0.89 178

BRN 1 0 0 BSP 3 +100 +100 0 0.87 0

BRN 2 0 0 BSP 2 +100 +100 0 0.92 0

BRN 2 0 0 BSP 3 +100 +100 0 0.86 0

BRN 3 -200 -100 BSP 3 +100 0 100 0.88 88

3.4.5 Implementation Considerations

It is important, to consider the following points when approaching the implementation of this change:

Vega could be calculated either:

At the same time as the inter-contract tier delta is determined; typically at the same time as

computing scanning losses;

At the same time as computing Inter-contract credits and where this is the case, ensuring that the

vega is calculated ONLY on the first occasion an inter-contract tier is referenced.

The sign of the Vega within an inter contract tier may be different to that of the delta within the tier.

Vega attributed to an inter-contract tier is reduced each time a vega credit is formed. Therefore, the vega

within an inter-contract tier should only be computed once and thereafter this vega is reduced each time a vega

spread is computed to yield a Volatility Credit.

Vega is only “consumed” within the Inter-Contract spread process where the Offset Rate is non-zero, ie where

a credit would be generated by any spread.

It is possible that two inter-contract tiers yield a Volatility Credit (ie they exhibit a Vega Spread) but do not

generate a delta spread derived Futures Credit.. For example, the deltas on two inter-contract tiers for which a

simple 2 legged, A v B spread applies are the same sign, hence no delta spreads are formed whilst the Vegas on

those two legs are oppositely signed (i.e. one +ve and one –ve) and thus yield a Volatility Credit.

Vega should only be “consumed” where a Volatility Credit is created. I.e. If the Offset Rate is defined as zero (0)

or ignored, then, the amount of Inter-contract Credit will be the same as that calculated if there was no Volatility

Credit. This means that, for applications where there is no Volatility Credit applied (i.e. the Offset rate is set to 0 as

it would be prior to the implementation of this change), this approach is entirely backwardly compatible.

3.4.6 Worked Example using SPAN for ICE

The following example has been created using SPAN for ICE as the calculator and in order to create sample

reports. (SPAN for ICE can be downloaded from https://www.theice.com/clear_europe_span.jhtml). You must use

version 1.0.3.3 or later.

This example is based on the test SPAN Array file IPE0313T.CSV/SP5 which is available for download from the

AFTS service and is located in the /span/test directory.

The positions used are:

Commodity Contract Type Expiry Strike Net Position

B C 20120500 12450 10

B C 20120600 12400 -10

B C 20121000 12400 10

Comb.

Contract

ICT

Tier

ICT Vega

BSP 1 +200

BSP 2 +300

BSP 3 +100

https://www.theice.com/clear_europe_span.jhtml


I C 20120300 12550 -50

These positions can also be downloaded from the same directory as the arrays; the position file is named

POSITION_MG1.CSV. This file is in SPAN for ICE format.

3.4.6.1 Scanning Loss and Combined Contract Vega

For BRN, the Scanning Risk is determined by scenario 14, so the Combined Contract Vega is:

-1 x (Scanning Loss for Scenario 13 – Scanning Loss for Scenario 14) / 2, i.e. (20700 - 28500)/2 = 3900.

For BSP, the Scanning Risk is determined by scenario 11, so the Combined Contract Vega is:

-1 x (Scanning Loss for Scenario11 – Scanning Loss for Scenario 12) / 2, i.e. (140500 - 136500)/2 = -2000.

NOTE: Why the -1 x in the above calculation: SPAN for ICE generally reports “losses” as positive numbers, ie a

scanning loss is shown as a positive number, whereas a “gain” would be signed as a –ve amount. In SPAN for

ICE reporting and purely for “optical” reasons, a positive vega indicates a gain and therefore is negated. This

makes no difference to the computation of vega credits etc provided that carrying of signed amounts is done

consistently.

3.4.6.2 Allocation of Combined Contract Vega to Inter-Contract Tiers

The first stage is to determine the Original Vegas for each Inter-contract Tier.


In this example, each position is in a separate tier, where multiple positions fall in the same tier, the total value

losses for all positions within the tier must be used and this may span multiple expiries.

In this case, the highlighted values are the value loss from which the Original Vega is determined. Note that these

are those value losses associated with tiers 13/14, ie the same as those used to derive the Combined Contract Vega.

This yields Original Vegas as follows:

Inter-Contract Tier

Computation Original Vega

1 -1 x (21500 - 29800)/2 4150

2 -1 x (-22300 - -32400)/2 -5050

3 -1 x (21500 - 31100)/2 4800

The Total Original Vega is the sum of the Original Vegas that are of the same direction (sign) as the Combined

Contract Vega. As the Combined Contract Vega is positive, then, this is (4150 + 4800), ie 8950.

The Combined Contract Vega is then apportioned to tiers 1 and 3

Inter-Contract Tier

Computation of Original Vega

Original Vega Computation of Tier Vega

1 -1 x (21500 - 29800)/2 4150 3900 x 4150/8950 1808

2 -1 x (-22300 - -32400)/2 -5050 Different Sign so, 0 0

3 -1 x (21500 - 31100)/2 4800 3900 x 4800/8950 2092

The process of apportioning the Combined Contract Vega for BRN to the Inter-contract tiers is reported by SPAN

for ICE as follows:


The same process is undertaken in respect of each combined contract. In the case of this portfolio, for BSP, the tier

level vegas are as follows. Note that in this case, there is only one position and one tier involved. The following

report snapshots show this reported by SPAN for ICE.

3.4.6.3 Calculation of Inter-Contract Credit

Having determined the Inter-Contract Tier Vegas, SPAN now applies inter-contract credits.

The following inter-contract credits, reported here, by SPAN for ICE, are generated:

In Spread 388, between BRN Tier 1 and BSP Tier 1, there is a Vega Spread of 1808 (+1808 from BRN versus -

1808 from BSP). Applying a rate of 48%, this yields a Vega (Volatility) Credit of $868 on each leg. This uses all

the Vega in BRN Tier 1 and leaves -192 vega in BSP tier 1. The Volatility Credit of 868 is added to the Futures

credit ($902 for the BRN leg and $2010 for the BSP leg) to yield total credits of $1770 and $2878 for the BRN and

BSP legs respectively.

In Spread 820m beteen BRN Tier 3 and BSP Tier 1, the remaining -192 BSP Tier 1 vega is then spread to yield a

Volatility Credit of $81 on each leg.


These credits are aggregated and summarised on the SPAN for ICE Summary shown below.

3.5 Customer Margin Ratios (Applicable to Energy and FX)

As part of the introduction of new regulations in the US (Dodd Frank Act) and the related rules issued by the

CFTC, ICE Clear Europe, as a DCO (Designated Clearing Organization) is required to specify a minimum amount

by which a Clearing Member increases the margin in respect of certain types of customer, over and above the

amount that would be determined on that customer position by the DCO.

The relevant text of this rule can be found in the CFTC Rules, 39.13(g)(8)(ii).

In order to facilitate the automation of the process of determining that amount of this add-on and processing this

within Member systems, it has been determined that additional data should be incorporated within the SPAN data

file.

This information is incorporated within a new record type, Record 36.

Separate ratios are defined for different types of Customer as follows:

Hedger – rate applicable to Hedgers (always expected to be 1.0)

Speculator – rate applicable to Speculators (>1.0 as per CFTC rules)

Member – rate applicable to Members (always 1.0); Members include Clearing Members and Exchange

Members

Other – unused; a placeholder for future expansion (always set to 1.0)

The ratio is specified as a multiplier (ie. a value of 1.1 means 10% uplift or 110% of DCO margin)

As ICE Clear Europe clears business through different regulatory jurisdictions, the ratios rates only currently apply

to that business cleared by US FCMs and therefore through the DCO designation of ICE Clear Europe. The RCH

designation applicable to clearing activity that relates to business cleared in respect of non-FCMs is not effected.


In order that this can be accommodated, two different record 36’s will be used. One will be identified as “DCO”

and one as “RCH”. Members applying the add-ons should utilise whichever set of add-on rates are applicable to

their own regulatory regime.

Lastly, though it is anticipated that the same add-on rates will be applied to all products, to aide future flexibility

and exercise a degree of compatibility with existing CME SPAN 3 implementation of Maintenance to Initial

margin ratios, the Record 36’s will be published on a per SPAN Combined Contract basis; i.e. there will be a pair

of Record 36’s for each Record 30.

4 Record Formats - CSV

4.1 Record Type 10: SPAN File Header Record

This record provides basic file properties relating to the SPAN Array file.

Type Opt Description

Integer Record Type - Always 10

String File Type

Integer Format Version (Applicable to fixed format only)

Date Business Date

String File Identifier

Date File Creation Date

Time File Creation Time

Integer Number of Scenarios

Format version indicates the format of the file

Business Date indicates the business date to which the file relates.

File identifier will be "F".

The number of scenarios is always 16.

4.2 Record Type 11: Contract Type Mapping Record

This data provides the mapping between a Contract type and Generic Contract Type.



String Contract Type

String Generic Contract Type

String Contract Type Description

4.3 Record Type 12: Currency Details

This record provides basic parameter information relating to currencies that are referred to within the file.

The Currency exponent for all currencies in use within ICE is 0.


Integer Record Type – Always 12

String Currency Code

String Currency Description

Integer Currency Exponent


4.4 Record Type 13: Currency Conversion Details

These records provide Currency FX information that is used by SPAN when a Combined Commodity comprises

contracts with different base currencies in order that SPAN can determine the margin in the base currency of the

combined commodity.

This is not currently relevant to ICE.



String Contract Currency

String Margin Currency

Real Contract / Margin Currency multiplier

(FX Rate)

Real Percentage FX Shift Up

Real Percentage FX Shift Down

4.5 Record Type 14: Intercontract Spread Details

These records define the Intercontract spreads.



String Contract Group

Integer Spread Priority

Integer Spread Method Code –10 or 11. Method 10 is applicable to Energy and 11 to FX.

Real Spread Credit Rate (%)

Real Offset Rate (For Spread Methods other than 10, this is an Integer value, whereas, for Method 10 this can be a real number – ie for Energy). Note that for FX, where method 11 is applicable, this will always be 0 as Volatility Credits are not applicable to FX.

Integer Number of Legs

String Exchange Code 1

String Combined Contract 1

Integer Tier Number 1

String Spread Side 1

Integer Delta/Spread Ratio 1

String Exchange Code 2

String Combined Contract 2


String Spread Side 2

Integer Delta/Spread Ratio 2

String Y Exchange Code 3

String Y Combined Contract 3

Integer Y Tier Number 3


String Y Spread Side 3

Integer Y Delta/Spread Ratio 3

String Y Exchange Code 4

String Y Combined Contract 4


String Y Spread Side 4

Integer Y Delta/Spread Ratio 4

Field Type Changes Old Type

Offset Rate Integer

A separate record is provided for each allowable spread. For a given contract spread group, the allowable spread

records are sorted in order by spread priority.

For each such spread, there are a minimum of two, and a maximum of four legs to the spread. Each group of five

fields, Exchange Code, Combined Contract Code, Tier Number, Delta/Spread Ratio and Spread Side, relates to a

single leg.

For each leg, the Tier Number indicates the Intercontract Tier Number for the specified Combined Contract. These

tiers are defined in record type 34.

For each leg, the Delta/Spread Ratio indicates the amount of delta for that leg consumed by each spread. For

example, a typical two-legged spread might be a 1:1 spread, or a 2:1 spread. A three-legged spread might be 1:1:1,

or 2:1:3, etc.

For each leg, the Spread Side indicates on which side of the spread that leg must be. The possible values for the

spread side are "A" or "B". This value indicates only that certain legs of the spread must be on opposite sides from

each other, and not that a particular leg must be net long or short.

The Exchange Code value for each leg of the spread will indicate the exchange to which this leg of the spread

pertains and utilises the same value range as for Record 16.

4.6 Record Type 15: Scenario Descriptions

These records provide a textual description for the scenarios.



Integer Scenario Number

String Scenario Description

Integer Paired Scenario Number

4.7 Record Type 16: Margin Group Descriptions

These records provide a description for the Margin Groups.



String Initial Margin Group

String Initial Margin Group Description

4.8 Record Type 20: Exchange Details

This record provides details relating to the Exchange.




String Exchange Code

String Exchange Short Name

String File Identifier

4.9 Record Type 21: Position Split Allocation Details

The Record 21 describes a component of a position split to be applied to source positions. Multiple Split

Allocation Details may be specified in relation to a contract and in the Position Split Allocation processing, a single

input position is transformed into multiple output positions.

The product key for source positions is defined as Contract Code, Contract Type, Expiry Date and Strike Price.

All positions on the source position file that have this product key are transformed into positions in the specified

Mapped Product with one Mapped position being created for each of the record 21s that relate to the source

product.

A full explanation of how these records are utilised is provided in Section 0.

Type Opt Name Example Value

Description

Integer Record Type 21 Always 21

String Contract Code CSO Physical commodity code of the product for which a position split allocation should be used

String Contract Type C The contract type can have the following values: F (Futures), M (Monthlies), D (Dailies), C (Call), P (Put)

String Expiry Date 20100800 The expiry date of the contract in the format YYYYMMDD. For non-daily contracts the days are displayed in the format "00".

Integer Strike Price 500 Only specified if Contract Type is C or P. The strike is displayed in the array/position file format; i.e. as an integer number of ticks: e.g. for PHH a strike of 500 must be divided by the Strike Denominator (100) to get the monetary price equivalent value of 5. This value can be negative.

String Mapped Contract Code

WBS Physical commodity code of the product for which the for which a position split allocation should be created

String Mapped Contract Type

F The contract type can have the following values: F (Futures), M (Monthlies), D (Dailies), C (Call), P (Put)

String Mapped Expiry Date

20100800 The expiry date of the contract in the format YYYYMMDD. For non-daily contracts the days are displayed in the format "00".

Integer Mapped Strike Price

0 Only specified if Mapped Contract Type is C or P. The strike is displayed in the array/position file format; i.e. as an integer number of ticks: e.g. for PHH a strike of 500 must be divided by the Strike Denominator (100) to get the monetary price equivalent value of 5. This value can be negative.

Real Delta -0.543428

Usual value for Futures, Monthlies, and Dailies will be one. For options this value will range between -1 and 1. It might have up to 7 decimal places.


4.10 Record Type 30: Combined Contract Details

These records define the parameters relating to a Combined Contract.

The Record 30 is a root of the Combined Contract hierarchy and subsequent record 40, 50, 60 records all relate to

the preceding record 30; until the next record 30 is encountered.



String Combined Contract Code

String Combined Contract Name

String Contract Group

String Initial Margin Group

String Margin Currency Code

Real Extreme Price Shift

Real Loss Covered (%)

Integer Short Option Minimum Charge Rate

Integer Strategy Spread Method Code

Integer Interprompt Spread Method Code

Integer Prompt Date Method Code

Date End of Risk Period

4.11 Record Type 31: Month Tier Details

Record 31, of which there may be multiple, defines the inter-month tiers that apply to this Combined Commodity

and are used in Interprompt spread calculations.

Each record can define up to 8 tiers. If more than 8 tiers are required, then, multiple Record 31s may be used.

NOTE: The Start and End of Expiry Group can be represented as either a DATE (an expiry date in YYYYMM00

format or a Month Number.



Integer Number of Tiers


Date Starting Expiry Group 1

Date Ending Expiry Group 1


Date Y Starting Expiry Group 2

Date Y Ending Expiry Group 2




















4.12 Record Type 32: Leg Spread Details

This defines the interprompt spreads with reference to the Month Tiers defined within the Record type 30s.

Each record may define up to 4 spreads; where more than 4 spreads are required, multiple record type 32s may be

used.



Integer Interprompt Spread Priority

Integer (Energy) Spread Charge Rate. For Energy Contracts this is an integer amount whereas for FX contracts this is a real amount. Real (FX)



Integer Delta Spread Ratio 1

String Market Side 1





Integer Y Delta Spread Ratio 3

String Y Market Side 3




4.13 Record Type 33: Prompt Date Charge Details

This defines the prompt date charges. Each record may define up to 4 charges; if more charges are required, then

multiple records may be used.




Integer Number of Expiry Groups

Date Expiry Group 1

Integer Spread Charge 1

Integer Outright Charge 1

String Delta Sign 1

Date Y Expiry Group 2

Integer Y Spread Charge 2

Integer Y Outright Charge 2

String Y Delta Sign 2









4.14 Record Type 34: Intercontract Tier Details

This defines the intercontract tiers.

Each record may define up to 8 tiers, where more are required, there may be multiple records.



Integer Number of Intercontract Tiers

Integer Intercontract Tier Number 1

Integer Starting Month Tier Number

Integer Ending Month Tier Number 1

Integer Y Intercontract Tier Number 2

Integer Y Starting Month Tier Number 2

Integer Y Ending Month Tier Number 2




















4.15 Record Type 35: Strategy Spread Details

This defines strategy spreads.

Each record may define up to 8 strategy spreads and where more than 8 are required, additional records will be

provided.

Each leg comprises three fields: the expiry group for the leg, the delta spread ratio and the market side of the leg

("A" or "B").

Each spread must have at least two legs. Data relating to legs three through eight is optional.

Strategy spread records are ordered by spread priority.



Integer Strategy Spread Priority

Integer (Energy) Spread Charge Rate. For Energy Contracts this is an integer amount whereas for FX contracts this is a real amount. Real (FX)


Date Expiry Group 1



Date Expiry Group 2






















4.16 Record Type 36: Customer Margin Ratios

This defines the ratios to be applied, depending upon the domicile of Member and Customer to Customer margin

for the purposes of meeting regulatory requirements.

In US this is typically termed Maintenance to Initial Ratio.

Currently, these ratios are only applicable to contracts cleared by FCMs in respect of US Customers through ICE

Clear Europe in its capacity as a DCO.

Multiple record 36’s may be specified, one per Clearing House Regulatory designation. Where no record is

specified for a given regulatory designation, then all ratios are 1.0.



String Regulatory Regime (DCO or RCH)

Real Margin Ratio – Member

Real Margin Ratio – Hedger

Real Margin Ratio - Speculator

Real Margin Ratio – Other

All ratios represent a multiplication factor ranging from 1.000 to 9.999.

4.17 Record Type 40: Contract Details

This defines detailed parameters associated with a contract.

All those record 50 and record 60 records that follow in the file relate to the contract given in this record, until

superseded by another contract record.

The delta divisor is used to scale a contract's delta, eg. in Interprompt spreading where combined contracts have

varying contract sizes.

The decimal locator and strike denominator fields are used to convert the strike price on record 60, which is in

display format, into a decimal value.

The settlements style field applicable to options contracts has the following values:

1 - Premium paid-up-front

2 - Futures style



String Contract Code

String Generic Contract Type

String Contract Description

String Contract Currency

Integer Tick Denominator

Integer Minimum Price Fluctuation (in ticks)


Real Tick Value

Real Delta Divisor

Integer Decimal Locator

Integer Strike Denominator

Integer Scanning Range (in ticks)

Integer Settlement Style Method

4.18 Record Type 50: Contract Expiry Details

This record provides detail regarding a specific contract expiry within the contract identified by the preceding

record type 40.

All succeeding records in the file relate to the expiry date given in this record, until superseded by another contract

expiry record.

For ordinary futures and options, there will be one expiry group. (In this case, the expiry group 1 field is analogous

to the futures contract month field of the risk array record in the previous versions of the risk parameter file

format.)

The volatility shift up and volatility shift down fields are percentages and are held as decimal numbers, e.g. 15% is

held as 0.15.



Date Expiry Date

Real Discount Factor

Real Volatility Shift Up (%)

Real Volatility Shift Down (%)

Integer Number of Expiry Groups

Date Expiry Group 1

































4.19 Record Type 60: Series Details (Risk Array Record)

This is the risk array itself applying to the specific series identified by the preceding Combined Commodity,

Contract and Contract Month.

Settlement / Closing price is expressed in a whole number of ticks for contracts quoted in points and ticks. For

example, a price of 1 5/32 would appear as 37.

The composite delta is held to four decimal places.

The risk array values are given in a whole number of ticks.

Each value represents the loss (gain) per single long position. Here "long" refers to long futures, long puts and long

calls.



Integer Strike Price

String Contract Type

Integer Lot Size

Integer Settlement Price

Real Composite Delta

Integer Loss Value 1

















5 Record Formats – SP5

This format is the extended Fixed Format Record risk array format utilised by ICE.

For descriptions of the fields an allied notes see the CSV description.


Length From To Type Opt Description

2 1 2 Integer Record Type - Always 10

1 3 3 String File Type

2 4 5 Integer Format Version

8 6 13 Date Business Date

2 14 15 String File Identifier

8 16 23 Date Creation Date

6 24 29 Time Creation Time

3 30 32 Integer Number of Scenarios




2 3 4 String Contract Type

1 5 5 String Generic Contract Type

20 6 25 String Contract Type Description




3 3 5 String Currency Code

20 6 25 String Currency Description

2 26 27 Integer Currency Exponent




3 3 5 String Contract Currency


3 6 8 String Margin Currency

10 9 18 Real Contract / Margin Currency multiplier

(FX Rate)

6 19 24 Real Percentage FX Shift Up

6 25 30 Real Percentage FX Shift Down




3 3 5 String Contract Group

6 6 11 Integer Spread Priority

2 12 13 Integer Spread Method Code – Always 10. As SP5 applies only to Energy, the spread method will always be 10.

6 14 19 Real Spread Credit Rate (%)

7 20 26 Real Offset Rate (For Spread Methods other than 10, this is an Integer value, whereas, for Method 10, which is applicable to Energy, this is a real number)

7 20 26 Integer Offset Rate

2 27 28 Integer Number of Legs

3 29 31 String Exchange Code 1

3 32 34 String Combined Contract 1

2 35 36 Integer Tier Number 1

1 37 37 String Spread Side 1

2 38 39 Integer Delta/Spread Ratio 1

3 40 42 String Exchange Code 2

3 43 45 String Combined Contract 2


1 48 48 String Spread Side 2

2 49 50 Integer Delta/Spread Ratio 2

3 51 53 String Y Exchange Code 3

3 54 56 String Y Combined Contract 3

2 57 58 Integer Y Tier Number 3

1 59 59 String Y Spread Side 3

2 60 61 Integer Y Delta/Spread Ratio 3

3 62 64 String Y Exchange Code 4

3 65 67 String Y Combined Contract 4


1 70 70 String Y Spread Side 4

2 71 72 Integer Y Delta/Spread Ratio 4



Offset Rate Integer




3 3 5 Integer Scenario Number

15 6 20 String Scenario Description

3 21 23 Integer Paired Scenario Number




3 3 5 String Initial Margin Group

25 6 30 String Initial Margin Group Description




3 3 5 String Exchange Code

8 6 13 String Exchange Short Name

2 14 15 String File Identifier

5.9 Record Type 21: Position Split Allocation Details

Length Type Opt Description

2 Integer Record Type – Always 21

3 String Contract Code

1 String Contract Type

8 Date Expiry Date

8 Integer Strike Price

3 String Mapped Contract Code

1 String Mapped Contract Type

8 Date Mapped Expiry Date

8 Integer Mapped Strike Price

9 Real Delta




3 3 5 String Combined Contract Code


20 6 25 String Combined Contract Name

3 26 28 String Contract Group

3 29 31 String Initial Margin Group

3 32 34 String Margin Currency Code

4 35 38 Real Extreme Price Shift

6 39 44 Real Loss Covered (%)

10 45 54 Integer Short Option Minimum Charge Rate

2 55 56 Integer Strategy Spread Method Code

2 57 58 Integer Interprompt Spread Method Code

2 59 60 Integer Prompt Date Method Code

8 61 68 Date End of Risk Period




2 3 4 Integer Number of Tiers


8 7 14 Date Starting Expiry Group 1

8 15 22 Date Ending Expiry Group 1


8 25 32 Date Y Starting Expiry Group 2

8 33 40 Date Y Ending Expiry Group 2























3 3 5 Integer Interprompt Spread Priority

10 6 15 Integer Spread Charge Rate. As SP5 format applies only to Energy, rate will always be an integer.



2 20 21 Integer Delta Spread Ratio 1

1 22 22 String Market Side 1





2 30 31 Integer Y Delta Spread Ratio 3

1 32 32 String Y Market Side 3







2 3 4 Integer Number of Expiry Groups

8 5 12 Date Expiry Group 1

10 13 22 Integer Spread Charge 1

10 23 32 Integer Outright Charge 1

1 33 33 String Delta Sign 1

8 34 41 Date Y Expiry Group 2

10 42 51 Integer Y Spread Charge 2

10 52 61 Integer Y Outright Charge 2

1 62 62 String Y Delta Sign 2













2 3 4 Integer Number of Intercontract Tiers

2 5 6 Integer Intercontract Tier Number 1

2 7 8 Integer Starting Month Tier Number

2 9 10 Integer Ending Month Tier Number 1

2 11 12 Integer Y Intercontract Tier Number 2

2 13 14 Integer Y Starting Month Tier Number 2

2 15 16 Integer Y Ending Month Tier Number 2






















6 3 8 Integer Strategy Spread Priority

10 9 18 Integer Spread Charge Rate. As SP5 format applies only to

Energy, rate will always be an integer+






























3 3 5 String Regulatory Regime (DCO or RCH)

5 6 10 Real Margin Ratio – Member

5 11 15 Real Margin Ratio – Hedger

5 16 20 Real Margin Ratio - Speculator

5 21 25 Real Margin Ratio – Other




3 3 5 String Contract Code

1 6 6 String Generic Contract Type

20 7 26 String Contract Description

3 27 29 String Contract Currency

6 30 35 Integer Tick Denominator

6 36 41 Integer Minimum Price Fluctuation (in ticks)

14 42 55 Real Tick Value

8 56 63 Real Delta Divisor

6 64 69 Integer Decimal Locator

6 70 75 Integer Strike Denominator

7 76 82 Integer Scanning Range (in ticks)

1 83 83 Integer Settlement Style Method





8 3 10 Date Expiry Date

8 11 18 Real Discount Factor

6 19 24 Real Volatility Shift Up (%)

6 25 30 Real Volatility Shift Down (%)

3 31 33 Integer Number of Expiry Groups




































8 3 10 Integer Strike Price

2 11 12 String Contract Type


5 13 17 Integer Lot Size

8 18 25 Integer Settlement Price

9 26 34 Real Composite Delta

7 35 41 Integer Loss Value 1
















6 Record Formats – SP6

This format is an extension of the SP5 fixed format record already utilised by ICE for Energy products and

incorporates a set of changes necessary to support application of SPAN to FX products.

The enhancements to the SP5 format incorporated within the SP6 format are as follows:

Several fields are being expanded to accommodate increased values and/or greater precisions. These

changes are highlighted within the affected record formats. The following records are affected:

Record 14 – Inter-contract Spread Details:

Delta/Spread Ratio 1 to 4 from 2 digits to 5 digits;

Record 32 – Leg Spread Details

Delta Spread Ratio 1 to 4 from 2 digits to 5 digits;

Record 35 – Strategy Spread Details

Delta Spread Ratio 1 to 8 from 2 digits to 5 digits;

Record 36 – Addition of Customer Margin Ratios record. This record type is being introduced

into all formats (CSV, SP5 and SP6)

Record 40 – Contract Details

Tick Denominator from 6 digits to 8 digits

Scanning Range from 7 digits to 12 digits

Record 60 – Series Details (SPAN Array)

Settlement Price from 8 digits to 12 digits

Some fields may now accommodate real numbers (i.e. decimals) where in SP5 they were always integer

values:

Record 14 – Offset rate

Record 32 - Leg Spread Details, Spread Charge Rate

Record 35 - Strategy Spread Details, Spread Charge rate

Warning


In prior versions of fixed file format (SP4 and SP5) many vendor solutions have assumed that certain real

values will be presented with a fixed number of decimal places. Notably, that Tick Value, within Record 40

will be presented with a fixed, 5 decimal places. This is not the case within the SP6 format.

Individual changes are highlighted within the record definitions themselves.

For descriptions of the fields an allied notes see the CSV description.



2 Integer Record Type - Always 10

1 String File Type

2 Integer Format Version

8 Date Business Date

2 String File Identifier

8 Date Creation Date

6 Time Creation Time

3 Integer Number of Scenarios





1 String Generic Contract Type

20 String Contract Type Description




3 String Currency Code

20 String Currency Description

2 Integer Currency Exponent




3 String Contract Currency

3 String Margin Currency

10 Real Contract / Margin Currency multiplier

(FX Rate)

6 Real Percentage FX Shift Up

6 Real Percentage FX Shift Down





3 String Contract Group

6 Integer Spread Priority

2 Integer Spread Method Code – 10 or 11. Method 10 for Energy and Method 11 for FX.

6 Real Spread Credit Rate (%)

7 Real Offset Rate (For Spread Methods other than 10, this is an Integer value, whereas, for Method 10 this can be a real number – ie for Energy). Note that for FX, where method 11 is applicable, this will always be 0 as Volatility Credits are not applicable to FX.

2 Integer Number of Legs

3 String Exchange Code 1

3 String Combined Contract 1

2 Integer Tier Number 1

1 String Spread Side 1

5 Integer Delta/Spread Ratio 1

3 String Exchange Code 2

3 String Combined Contract 2


1 String Spread Side 2

5 Integer Delta/Spread Ratio 2

3 String Y Exchange Code 3

3 String Y Combined Contract 3

2 Integer Y Tier Number 3

1 String Y Spread Side 3

5 Integer Y Delta/Spread Ratio 3

3 String Y Exchange Code 4

3 String Y Combined Contract 4


1 String Y Spread Side 4

5 Integer Y Delta/Spread Ratio 4

Field Length Changes Old Width

Delta/Spread Ratio 1-4 2


Offset Rate Integer





3 Integer Scenario Number

15 String Scenario Description

3 Integer Paired Scenario Number




3 String Initial Margin Group

25 String Initial Margin Group Description




3 String Exchange Code

8 String Exchange Short Name

2 String File Identifier

6.9 Record Type 21: Position Split Allocation Details (Enhanced Arrays Only)


2 Integer Record Type – Always 21



8 Date Expiry Date


3 String Mapped Contract Code

1 String Mapped Contract Type

8 Date Mapped Expiry Date

8 Integer Mapped Strike Price

9 Real Delta




3 String Combined Contract Code

20 String Combined Contract Name

3 String Contract Group


3 String Initial Margin Group

3 String Margin Currency Code

4 Real Extreme Price Shift

6 Real Loss Covered (%)

10 Integer Short Option Minimum Charge Rate

2 Integer Strategy Spread Method Code

2 Integer Interprompt Spread Method Code

2 Integer Prompt Date Method Code

8 Date End of Risk Period




2 Integer Number of Tiers


8 Date Starting Expiry Group 1

8 Date Ending Expiry Group 1


8 Date Y Starting Expiry Group 2

8 Date Y Ending Expiry Group 2























3 Integer Interprompt Spread Priority

10

Integer

(Energy)

Spread Charge Rate. For FX, this is a real value; If SP6 format were adopted for Energy, this will be an integer value Real

(FX)



5 Integer Delta Spread Ratio 1

1 String Market Side 1





5 Integer Y Delta Spread Ratio 3

1 String Y Market Side 3




Field Length Changes to SP5

Old Width

Delta Spread Ratio 1-4 2

Field Type Changes to SP5

Old Type

Spread Charge rate Integer




2 Integer Number of Expiry Groups

8 Date Expiry Group 1

10 Integer Spread Charge 1

10 Integer Outright Charge 1

1 String Delta Sign 1

8 Date Y Expiry Group 2

10 Integer Y Spread Charge 2

10 Integer Y Outright Charge 2

1 String Y Delta Sign 2













2 Integer Number of Intercontract Tiers

2 Integer Intercontract Tier Number 1

2 Integer Starting Month Tier Number

2 Integer Ending Month Tier Number 1

2 Integer Y Intercontract Tier Number 2

2 Integer Y Starting Month Tier Number 2

2 Integer Y Ending Month Tier Number 2






















6 Integer Strategy Spread Priority

10

Integer

(Energy)

Spread Charge Rate. For FX, this is a real value; If SP6 format were adopted for Energy, this will be an integer value Real

(FX)



























Field Length Changes to SP5

Old Width

Delta Spread Ratio 1-8 2

Field Type Changes to SP5

Old Type

Spread Charge rate Integer




3 3 5 String Regulatory Regime (DCO or RCH)

5 6 10 Real Margin Ratio – Member

5 11 15 Real Margin Ratio – Hedger

5 16 20 Real Margin Ratio - Speculator

5 21 25 Real Margin Ratio – Other






1 String Generic Contract Type

20 String Contract Description

3 String Contract Currency

8 Integer Tick Denominator

6 Integer Minimum Price Fluctuation (in ticks)

14 Real Tick Value

8 Real Delta Divisor

6 Integer Decimal Locator

6 Integer Strike Denominator

12 Integer Scanning Range (in ticks)

1 Integer Settlement Style Method


Tick Denominator

Scanning Range

6

7




8 Date Expiry Date

8 Real Discount Factor

6 Real Volatility Shift Up (%)

6 Real Volatility Shift Down (%)

3 Integer Number of Expiry Groups







































5 Integer Lot Size

12 Integer Settlement Price

9 Real Composite Delta

7 Integer Loss Value 1

















Settlement price 8

ice span array file format · ice clear europe. users of the sp6 file format within back office...

Documents