ICE - Clear CA, EU, US & SG Combined Gross Customer Margin (GCM… · 2. The GCM Process 2.1 Mechanism of Submission Members will submit the GCM files to ICE’s MFT server via sftp

ICE - Clear CA, EU, US & SG Combined

Gross Customer Margin (GCM) File via FIXML

Member Specification

Version: 2.0

05 Feb 2015

This material may not be reproduced or redistributed in whole or in part without the express,

prior written consent of IntercontinentalExchange, Inc.

Copyright IntercontinentalExchange, Inc. 2015. All Rights Reserved.

July 2014 2 Version 1.9

Revision History

Date Version Description 19 Mar 2012 0.2 Draft version of the document for discussion with Members

30 Mar 2012 0.3 Added further details regarding processing of the GCM file and examples. First baseline for publication to Members.

18 Apr 2012 0.4 Updated the Specification to include tag in the “Header-Trailer” section. The Customer Account and Full Legal name/Customer Name fields will be limited to 64 characters.

08 May 2012 0.5 Updated the GCM submissions folder to “/clearing/gcm-submission” instead of “/clearing/PCS-submission”.

22 May 2012 0.6 Updated the Specifications to include temporary values for Adjustment Type, Customer Account Type and Parent Omnibus Account. This is for enabling Member/Vendor testing until FIX Committee has finalized the new values and updated FIX Specifications. Further details added to clarify handling of multiple instructions for the same Customer, Parent Omnibus Account and Contract.

06 Jun 2012 0.7 Updated the Specifications with following changes – � Customer Account field cannot contain commas or strings “BALANCE

ACCOUNT” or “NONDISCLOSED” � Parent Omnibus Account cannot contain commas.

19 Jun 2012 0.8 Updated the Specifications with following changes – � Final (FIX assigned) values for Adjustment Type, Customer Account

Type and Parent Omnibus Account. � Further details for submission of disclosed/non-disclosed positions

underlying an omnibus account. Members will submit the positions of the omnibus account and the details of disclosed customer positions underlying the omnibus account. The Clearing House will derive the non-disclosed positions based on these submissions. (This is a change from previous implementation where members were expected to provide details of disclosed and non-disclosed customer positions accounts)

26 Jun 2012 0.9 Updated Specifications with following changes – � Duplicate omnibus account ID’s are not allowed within a position

account and contract. Entire GCM file will be rejected in this scenario.

� For disclosed customer position reporting, both the long and short quantity cannot be non-zero. I.e. Members are required to submit net position for disclosed customer positions.

26 Jul 2012 1.0 Updated specifications to include a new ICUS specific Quantity Type /Qty@Typ = “DLV”. This will enable members in the US in reporting positions in delivery.


01 Aug 2012 1.1 Added IFED product/member exchange to support conversion of cleared energy swaps to futures

10 Sep 2012 1.2 Updated the specification with following changes – • Instrument and Party Exchange fields are now optional. • Added missing “SetSesID” tag in the examples. • Updated details in relation to GCM submission folder on MFT. • Non-disclosed/partially disclosed positions will be allowed for ICEU.

17 Dec 2012 1.3 • Added detailed examples for customer balancing Account calculation. (Section 3.5)

• Added “IFCA” product/party exchange for CA Only • Added “ICCA” clearinghouse for CA Only • Added Canada Examples • Added “NDEX” Exchange Code for ICE-ENDEX products.

13 Feb 2013 1.4 • Added SettlCcy – preferred margin currency

• Added RptTyp – report type for margin results

05 July 2013 1.5 Following changes were implemented with Platform 7 release.

• Added details in relation to deriving PCS from GCM functionality.

• Added support for reporting of House Positions in ICUS. This is for deriving PCS from GCM submission for House positions and only affects ICUS firms.

• Added support for reporting of “Gross” Customer Positions 20 Dec 2013 1.6 • Added “IFLL”, “IFLO”, “IFLX”, “IFEN”, and “IFUT” for EU Only to the

following tags:

o @Instrmt/Exch (Product Exchange)

o @Undly/Exch (Product Exchange)

o @Pty R=22 (Party Exchange)

• Removed “IOTC” for EU Only to the following tags:

o @Instrmt/Exch (Product Exchange)

o @Undly/Exch (Product Exchange)

o @Pty R=22 (Exchange)

• Added “M” (Market Maker) as a new enumeration for @Party Role 38, @ID (Position Account) for EU Only

28 Jan 2014 1.7 • Updated the specifications to flag that “@SettlCcy” and “@RptTyp” elements will only be supported with the implementation of ICE’s MAPS margining model.

• Position Account “M” (Market Maker) will no longer be supported once NYSE Liffe products migrate to ICE. Removed this enumeration from the list.

27 Mar 2014 1.8 Updated the specification with following –


Instrument Exchange (/Instrmt@Exch) will be mandatory for a duplicate commodity ID. This is relevant from UCP Phase III Migration as NYSE Liffe products are migrated to ICE systems which creates conflicting commodity ID’s. Where Commodity ID is unique across ICE Exchange Codes, Instrument Exchange will not be validated.

22 July 2014 1.9 • Added ICE Clear Singapore code “ICSG” to the following tag:

@Pty R=21 (Clearing house)

• Added ICE Futures Singapore code “IFSG” to the following tags:

@Instrmt/Exch (Product Exchange)

@Undly/Exch (Product Exchange)

@Pty R=22 (Exchange)

05 Feb 2015 2.0 Minor updates to clarify the use of elements @SettlCcy and @RptTyp. These elements are not available in production today and will be implemented with MAPS implementation.

Note: Changes from one version to the next are noted in RED.


Table of Contents 1. Introduction ........................................................................................................................... 6 2. The GCM Process ................................................................................................................... 6 2.1 Mechanism of Submission ................................................................................................. 6 2.2 Processing ........................................................................................................................ 8 2.3 Message Details .............................................................................................................. 10 2.3.1 Header-Trailer .......................................................................................................... 10 2.3.2 Main Block ............................................................................................................... 10 2.3.3 Instrument Block (Instrmt) ........................................................................................ 11 2.3.4 Party Blocks (Pty) ..................................................................................................... 14 2.3.5 Quantity Blocks (Qty) ................................................................................................ 18

3. Appendix ............................................................................................................................. 20 3.1 FIXML GCM File Examples – ICE Clear EU ............................................................................ 20

3.1.1 ICEU - Scenario 1 ..................................................................................................... 21 3.1.2 ICEU - Scenario 2 ..................................................................................................... 23 3.1.3 ICEU - Scenario 3 ..................................................................................................... 25 3.1.4 ICEU - Scenario 4 ..................................................................................................... 26

3.2 FIXML GCM File Examples – ICE Clear US ............................................................................ 28 3.2.1 ICUS - Scenario 1 ..................................................................................................... 28 3.2.2 ICUS - Scenario 2 ..................................................................................................... 29 3.2.3 ICUS - Scenario 3 ..................................................................................................... 31 3.2.4 ICUS - Scenario 4 ..................................................................................................... 32 3.2.5 ICUS - Scenario 5 ..................................................................................................... 33

3.3 FIXML GCM File Examples – ICE Clear Canada ..................................................................... 34 3.4 Comparison of Position Accounts Usage between ICE and CME ............................................. 35 3.5 Calculation and Margining of Customer Balance Account ...................................................... 36


1. Introduction CFTC regulations which came into effect on November 8, 2012 require a significant change in how derivatives Clearing organizations (DCO’s) determine margin requirements in respect of customer positions. Specifically, CFTC requires DCO’s to set the minimum margin requirement in respect of a Customer at a level equivalent to that which would be required in respect of a Clearing Member holding that same position.

DCO’s will require the submission of a data file reporting individual customer accounts and their positions; this is referred to as the Gross Customer Margin file, or simply as the GCM file in order to keep the term consistent across other DCO’s.

For submission of data for customer gross margining, the regulations do not require any changes in how omnibus accounts are held in books. Omnibus accounts may be fully disclosed, partially disclosed or entirely non-disclosed. For this purpose, position data for omnibus accounts should be submitted as for any other account, with aggregate gross long and short position quantities. Then, if the omnibus account is partially or fully disclosed, data for individual customer accounts should be submitted.

This document specifies the data content and message format for FIXML GCM file submissions and provides a high level description of the processes that relate to these submissions. The specification covers ICE Clear Canada, ICE Clear Europe Energy, ICE Clear US and ICE Clear Singapore.

2. The GCM Process

2.1 Mechanism of Submission Members will submit the GCM files to ICE’s MFT server via sftp process.

In order to ensure that member’s do not require a new service account for their various submissions (i.e. GCM, PCS etc.), the Clearing House is providing members with a new global service account with the root directory of “XXX/clearing/submissions” (XXX – Trading/Clearing Member mnemonic). This root directory will contain sub-directories for various submissions. Members submitting the GCM files can use the “cd” (change directory) command from the root directory into their GCM submission folder “gcm” to deposit the GCM files.

Note: The PCS submissions will be migrated to the above directory structure in the future. For now, ICEU & ICUS members can continue submitting PCS FIXML files in the existing “XXX/clearing/pcs-submission” folder as they do today. ICE Clear Canada will use the new directory structure (“XXX/clearing/submissions/pcs”) from onset.

GCM files submitted by Members must comply with the following naming convention:

GCM_MMM_TT_YYYYMMDD_RRRRRRRRRRRRRRRR.xml

Where

MMM is the Member Identifier and corresponds to the Clearing Member/Trading Member mnemonic. The MMM identification within the filename must correspond to the name of the directory within which the file is submitted. Therefore, if the file is submitted to the “/clearing/submissions/gcm” directory of Member ABC, on MFT, the file must be named GCM_ABC_TT_YYYYMMDD_ RRRRRRRRRRRRRRRR.xml. Any file in which the Member Identifier does not correspond to the Member directory identifier will be failed.

TT is the File Submission Type. “ED” is used for Gross Customer Margin File.


YYYYMMDD is the Current Business date.

RRRRRRRRRRRRRRRR is an alpha-numeric Reference Id provided by the Member. This must be unique for a business day. This is used by the system as a means of uniquely identifying files submitted throughout the day and is included in any e-mail notifications issued by the system should the file or any instruction within the file be rejected; the field can be up to 16 alpha-numeric characters in length.

Note: “_” (underscore) cannot be used in the Reference ID field as this is used as a delimiter.

Members may adopt their own convention for the reference Id but it is suggested that the Reference Id contain a version or sequence number of some description in order to ensure the uniqueness of files submitted.

Members can deposit files containing GCM instructions throughout the day. The system will validate the instructions in the file and these will be stored in the system to be used during the EOD Margin run. If the file or some entries in the file are rejected, Members will be notified via email.

Once identified as a file to be processed, the file submitted by the Member will be renamed to “.submitted”, that is, “.submitted will be appended to the filename residing under MFT server. For example, a file name GCM_MMM_ED_20101106_ 1.xml will be renamed to GCM_MMM_ED_20101106_ 1.xml.submitted. This makes it clear which files have/have not been submitted for processing. There may be a delay between the point at which the Member deposits the file on MFT and the file being identified for processing and being renamed.

Renaming of a file to “.submitted” does not signify that the file has been “accepted”; the file may subsequently fail validation of the content as a whole or individual instructions contained in the file may be rejected. Renaming of the file merely signifies that the file is being processed. Any subsequent errors will be notified via notification e-mails. Members will have access to the “MPIGCM –Invalid GCM Submissions” pdf report on MFT to identify errors in their GCM file submission.

Any file that has the same filename as that of a previously submitted file will be rejected. It is the Member’s responsibility to ensure that all files submitted on a given business date have a unique filename and that they use the Reference Id within the filename in a manner that ensures that this uniqueness is maintained. In effect, the Reference Id must be unique across the set of files submitted by a given Member, the Submission Type and Business Date.

If a Clearing Member submits GCM file instructions relating to the customer positions of a non-clearing Member, i.e. for a position account of another Member (CM sub-division in case of ICUS), then, the

instructions should be included in a file named with the Clearing Member’s own mnemonic, i.e. MMM should refer to the clearer and submitted via the Clearing Member’s own MFT directory. Should a clearer want to submit separate files for each set of non-clearer positions, then, these separate files should be distinguished through the Reference Id within which the Member might chose to include the mnemonic of the Trading Member.

For example, if the clearer were ABC and the Trading Members (non-Clearing firm/CM sub division) on whose behalf GCM instructions are submitted were UVW and XYZ, the following naming would be appropriate for GCM submissions submitted at EOD on 28 March 2012:

• GCM_ABC_ED_20120328_1.xml containing customer positions relating to the clearer’s own positions;

• GCM_ABC_ED_20120328_XYZ_1.xml containing customer positions relating to XYZ’s positions;

• GCM_ABC_ED_20120328_UVW_1.xml containing customer positions relating to UVW’s positions.


Note that in each case a sequence number is applied, in this case 1. Should the clearer need to resubmit any of the instructions or indeed, a complete file again, then this sequence number would have to be incremented on subsequent submissions in order that the naming of the file and hence identification of instructions within the file, remains unique. So, if the GCM_ABC_ED_20120328_1.xml file were rejected in its entirety, the re-submitted file with any corrections would need to be named something like: GCM_ABC_ED_20120328_2.xml.

Notification e-mails in respect of GCM file submissions will be sent to the e-mail address/distribution list set up by the Member via the ECS e-mail notification screen.

2.2 Processing ICE Clearing House will require submission of GCM files containing Customer Positions at end of day on each Clearing business date. The deadline for EOD GCM file submission by Members will be 06:00pm Central Time for ICCA, 12:00am midnight London Prevailing time for ICEU submissions and 07:00pm Eastern Prevailing time

for ICUS submissions (these deadlines may be subject to change).

ICE will also provide a facility so that Clearing Members are able to submit an early provisional GCM file prior to the end of day submission. The early file can be sent to the Clearing House at any time prior to the EOD GCM file submission deadline. Providing an early file for customer positions will ensure that the Members are not subjected to a large margin call in their “Customer Balancing Account” in cases where the Member fails to provide a final file by the deadline due to any technical issues at their end. The Members may submit an early file at the time of their choosing. The submission of early file may differ across various Members based on when majority of their Customer trading finishes.

If prior Customer Positions exists in the system for a “Position Account”, these will be completely replaced by any subsequent GCM file submissions containing Customer Position for the same Position Account.

For e.g. Clearing Member “TCU” submits an early GCM file containing Customer Positions for their own Position Accounts & the Position Accounts relating to their Trading Members “ABC” and “XYZ”. Positions in the early file relate to Position Account “TCUW”, “ABCW”, “XYZW”. The EOD file provided by “TCU” contains updated Customer Positions for “ABCW” only. The Clearing House will, for the current Business date, replace all Customer Positions in the system relating to the Position Account “ABCW” with the Customer Positions in the most recent file. The Customer Positions in the system relating to “TCUW” and “XYZW” are not changed.

Note: There is no limit on how many files can be submitted by a Clearing Member for a given business date. The Clearing House will always take the customer positions for a Position Account from the file that was received last on the MFT server as the EOD GCM file submission for calculation of Margin.

The Clearing House will import the GCM file as soon as it arrives on MFT. The file will go through some basic validation checks. For e.g. verify if the file contains valid XML data and the contract specified in the Instrument block is a valid ICEU/ICUS/ICCA contract. Members will be provided with reports to identify any failed instructions (MPIGCM- Invalid GCM Submissions report). Clearing House will also provide an early “MPGCMB - GCM Customer Balancing Account” report which will show the customer balancing account long and customer balancing account short which will be margined as per details covered in section 3.5.

For positions in Expiring Options: Clearing firms differ in the timing of when they process final exercises and assignments in their books. Preferably, the GCM file should be created as if final processing had already occurred, with exercised positions in options reported as being transformed into their underlying futures. This applies to both – early options exercise/assignment and to those options exercised/assigned on expiry. If the Member systems have not been updated to reflect results of an options expiry process prior to submitting the


GCM file to the Clearing House, we will accept and margin the expired option positions as underlying futures position provided these were in-the-money options. This may, however, result in a bigger “Customer Balancing” account (due to differences arising from any in-the-money options abandoned/out-of-money options exercised) resulting in a margin value which is not be equal to the margin value calculated if the Members were to provide final customer positions for the resultant futures taking into account the results of an option expiry.

For Positions in Deliverable Futures (ICUS & ICCA Only): In the US, a seller can notify intent for delivery prior to the settlement date for a deliverable contract. This can result in a customer having positions in delivery and in futures for the same contract e.g. SB 20120700. Clearing House has included a new

enumeration quantity type “DLV” in order to enable members to report customer positions in delivery. This is relevant for positions in delivery since the Clearing House will create separate Customer Balancing Account for the delivery and open futures positions prior to settlement. Post settlement, CH will take any reported open futures positions as underlying deliverable for the purpose of calculation of Customer Balancing Account and Gross Margining.

Handling of Duplicate Omnibus Account ID in a GCM file: Members are required to provide the Clearing House with details of the omnibus account positions on their book and the positions of each individual disclosed customer position (by specifying the parent omnibus account in the /Pty/Sub@ID Typ = “42” role) underlying this omnibus account. The Clearing House will calculate the non-disclosed customer positions using the information above.

In order to be able to uniquely identify a customer underlying an omnibus account or an omnibus account underlying another parent omnibus account, omnibus account ID’s for a specific position account and contract cannot be duplicated. The Clearing House will reject the entire GCM file if the uniqueness of the omnibus account ID’s within a position account and contract is not met.

We recommend that members concatenate the omnibus account ID with the parent omnibus account ID so that the members can easily view the omnibus account hierarchy on the various reports provided by the clearing house while maintaining uniqueness. For e.g. A Disclosed Customer Position for “Customer 1” underlying omnibus account “NGCMSUBOMNI” which itself is underlying another parent omnibus account “FCMOMNI can be reported as “FCMOMNI>NGCMSUBOMNI”.

Deriving PCS from GCM: GCM processing is being enhanced to enable the Clearing House to derive PCS using the customer positions submitted in the GCM file. The system will use the customer positions reported in the GCM file to derive the PCS final long which will be used to update the FCM’s position at the CH. The functionality will be enabled for all members in ICUS and for FCM’s Clearing US Customer business via ICEU (CSEGW Segregation). The process differs for ICEU & ICUS due to different PCS implementation and is described below.

ICEU – This change will be configurable for FCM’s clearing US Customer business via ICEU (CSEGW Segregation). If enabled, the change will apply to all underlying accounts cleared through the CSEGW segregation account. FCM’s can continue sending PCS using the existing PCS mechanism which will be applied to the member’s position on a real-time basis. Existing PCS can also be used for AM PCS and for closing out positions for intraday expiring contracts. At EOD, the system will use the long position in the GCM file


aggregated across all customers and non-disclosed positions to derive a PCS delta which will be applied to the FCM’s position at the Clearing House.

ICUS – The functionality to derive PCS from GCM will be enabled for all FCM’s clearing via ICUS. Firms can continue using PCS submitted via GUI and File submissions. If a PCS file is submitted, the process to derive PCS from GCM will be skipped for this member. If there are no PCS instructions submitted using a file submission, the system will use the GCM file to derive PCS. Also, any GUI submitted PCS always take precedence over any file submission.

There are no changes to the PCS submissions for non-FCM business or to the current PCS processing.

2.3 Message Details

2.3.1 Header-Trailer

The FIXML GCM file represents a batch of GCM messages which are enveloped between a header and a trailer.

The Header and trailer indicate the beginning and end of the file to be processed. Below is an example of the required header for GCM:

At the end of the file the and the blocks need to be closed as follows:

2.3.2 Main Block

The main block for GCM messages is the Position Maintenance Request () record. The following table represents the FIXML tags and values found in this block.

FIXML Tag Description Values @ReqID Firm generated Request ID Alpha-Numeric

The Request Id is specified by the Member and can be used by the Member to reference the instruction. The Request Id does not have to be unique. The Request Id is limited to 16 characters.

@TxnTyp Transaction Type “4” - for final submission @AdjTyp Adjustment Type “4” – Customer Specific Submission @Actn Action Type “1” for New @BizDt Business Date for this file: Year-Month-

Day (YYYY-MM-DD) Current Business Date


@SetSesID Session ID Settlement Cycle.

“EOD”

@TxnTm Timestamp without GMT offset – UTC. (YYYY-MM-DDTHH:MM:SS)

"2010-02-26T11:31:32" The timestamp is specified by the Member and is not subject to any validation.

@SettlCcy Margin currency The preferred currency in which margin will be calculated and reported.

Optional Valid values are: “USD” “EUR” “GBP” Note: This field is not supported in production today. This element will be supported with the implementation of ICE’s MAPS Margining system. If not provided, system will default to the

preferred currency of the customer segregation account.

@RptTyp Report Type The report type identifies the level of detail the member wants to receive margin results.

Optional Valid values are: “0” – Summary (Total initial margin for the portfolio) “1” – Detailed by commodity code in margin currency Note: This field is not supported in production today. This element will be supported with the implementation of ICE’s MAPS Margining system. If not provided, system will default to Summary.

2.3.3 Instrument Block (Instrmt)

The purpose of the Instrument Block is to identify all contract information on the message. The Instrument Block is required on all Maintenance Requests. With the Instrument Block, the FIXML GCM file may require an Underlying block. This block would only be required if its presence is necessary for determining the correct commodity/contract. See below table for specific FIXML tags found within this block:

FIXML Tag Description Values /Instrmt@Exch Exchange for commodity Optional

EU: “IFEU” - ICE Futures EU


“IFED” - ICE Future Energy Division “NDEX” - ICE ENDEX Futures EU “IFUT” - European Utilities Division “IFEN” - Oil and Refined Products Division “IFLL” - Financial Products Division “IFLO” - Equity Products Division “IFLX” - Agricultural Products Division US: “IFUS” – ICE Futures US CA: “IFCA” – ICE Futures Canada SG: “IFSG” – ICE Futures Singapore Instrument Exchange (/Instrmt@Exch) is

mandatory where there are duplicate commodity codes across multiple ICE Exchanges (“G” – Gas Oil on Exchange IFEU and “G” – Short Gilt Future on Exchange IFLL). Optional otherwise.

/Instrmt@SecTyp Security Type “OOF” for Options “FUT” for Futures “CMB” for Combos (ICUS Only) “OOC” for Options on Combos (ICUS Only)

/Instrmt@ID Commodity Code Any valid commodity code. This is sometimes referred to as the Physical Commodity in the EU.

/Instrmt@MMY Contract Code or Expiry Formatted “YYYYMMDD” For monthly expirations, DD will be populated with ‘00’. Note: Combo products in ICUS have non-numeric Period codes. For e.g. 201207C1. These will be accepted as long as it is recognized as a valid period code in the System.

/Instrmt@PutCall Put Call indicator “0” for put “1” for call

/Instrmt@StrkPx Strike Price Numeric strike price with sign and decimal if applicable


The below table depicts the FIXML tags associated with the underlying block. This block should only be supplied when it is necessary to identify the instrument. The Underlying Block is NOT REQUIRED for any ICE products at present but this is included in this specification in the event that it is required in the future.

FIXML Tag Description Values /Undly@Exch Exchange for underlying commodity EU:

“IFEU” - ICE Futures EU “IFED” - ICE Future Energy Division “NDEX” - ICE ENDEX Futures EU

“IFUT” - European Utilities Division “IFEN” - Oil and Refined Products Division “IFLL” - Financial Products Division “IFLO” - Equity Products Division “IFLX” - Agricultural Products Division US: “IFUS” – ICE Futures US CA: “IFCA” – ICE Futures Canada SG: “IFSG” – ICE Futures Singapore

/Undly@SecTyp Underlying Security Type “FUT” for Futures “OOF” for Options “CMB” for Combos (ICUS Only) “OOC” for Options on Combos (ICUS Only)

/Undly@ID Underlying Commodity Code Any valid underlying commodity code. This is sometimes referred to as the Physical Commodity in the EU.

/Undly@MMY Underlying Contract Code or Expiry Formatted “YYYYMMDD” For monthly expirations, DD will be populated with ‘00’. Note: Combo products in ICUS have non-numeric Period codes. For e.g. 201207C1. These will be accepted as long as it is recognized as a valid period code in the System.

/Undly@PutCall Put Call indicator “0” for put “1” for call

/Undly@StrkPx Underlying Strike Price Numeric strike price with sign and decimal if applicable


2.3.4 Party Blocks (Pty)

The purpose of the Parties Block is to identify the customer position underlying a position account. The following table lists the party blocks to be used for the GCM submission.

FIXML Tag Description Values /Pty@ID R=”1” Trading Firm – Required. FCM Identifier (may be Clearing or non-

Clearing FCM)

/Pty@ID R=”38” Position Account. This is the Gross Position Account of the Trading Member for which EOD customer positions are required.

Position Account

ICUS – “C” for Customer or “H” for House account. GCM file is required for Position accounts under “CSEG” segregation. ICUS members can also provide (not mandatory) positions for the House Position Account and this will be used to derive the Final Long PCS for this account. The system will not generate Balancing Account for House accounts and the GCM reported House positions will not be used for EOD Margin calculation. ICCA – “C” for Customer or “H” for house account. GCM file is required for Position accounts under “CSEG” segregation only. ICEU - FCMs might have any of the following Customer Omnibus Position Accounts – “S”,”W”,”F”,”Z”, “T”, “M” and “N”. ICSG - ICSG - “S” - “Segregated Customer” & “T” - “Segregated - T” and “H” for “House”. GCM submissions are only required for “S” and “T” position accounts for ICSG.

/Pty@ID R=“24” Customer Account Customer Account Identifier is mandatory

for positions underlying a Customer position account. The field is not mandatory when reporting positions for the House Position Account

unless an omni-account underlying a House account is being reported in which case the Customer Account must be provided.


The Customer Account field (except when Party Role 38 = “H”)

� Cannot be blank; � Cannot be missing; � is limited to 64 characters; � can be made up of Alphanumeric

characters (A-Z, a-z, 0-9), space, period (“.”), hyphen (“-”), or underscore (“_”) only;

� cannot contain text “BALANCE ACCOUNT” or “NONDISCLOSED” (upper or lower case)

The instruction will be rejected if it does not satisfy above rules. Members are requested to submit total position underlying an omnibus account (by providing the omnibus account ID in the Customer Account Field and the Customer Account Type = “O”) and the positions for disclosed customer accounts underlying this omnibus account. The Clearing House will derive the non-disclosed positions by subtracting the total of all disclosed customer positions underlying an omnibus account from the total position for the omnibus account as submitted by member. If the reported GCM long/short submissions underlying an omnibus account exceed the Omni account position, the CH will not calculate any non-disclosed positions underlying the omnibus account. Please refer to section 3.5 for more details. When reporting omnibus accounts (Customer Account Type = “O”), the omnibus account ID’s must be unique within a position account and contract otherwise the entire file will be rejected. Note: The instruction for the omnibus account (/Pty/Sub@ID Typ = “42”) and the details of the disclosed customer positions (/Pty@ID R=“24”) must be provided in the same GCM file.


ICUS/ICEU/ICCA/ICSG – Members are allowed to hold non-disclosed/partially-disclosed positions for Futures contracts.

/Pty/Sub@ID Typ = “5”

Full Legal Name/Customer Name Full Legal Name/Customer Name is mandatory in relation to EOD Customer Position Submissions for disclosed accounts. This field is limited to 64 characters. This is the full legal name/customer name for the omnibus account or the disclosed customer account. ICUS/ICEU/ICCA/ICSG – Members are allowed to hold non-disclosed/partially-disclosed positions for Futures contracts.


Customer Account Type The customer account type indicates whether the account is Member, Hedge, Speculator or Omnibus. If not provided, the default is “S” - Speculator. Valid Values - “M” – Member “H” = Hedge “O” = Omnibus “S” = Speculator Note: “O” is the value members must submit when providing the position for an omnibus account on their books. If no individual customer positions are disclosed, the entire omnibus account position is considered as non-disclosed and margined outright.


Parent Omnibus Account If the FCM is reporting positions that it holds in an Omnibus account facing another FCM, then “Parent Omnibus Account” role

specifies the identity of the Omnibus account on the books of the FCM. In this scenario, the Parent Omnibus Account details must be provided. The Parent Omnibus Account field

� is limited to 64 characters; � can be made up of Alphanumeric

characters (A-Z, a-z, 0-9), space,


period (“.”), hyphen (“-”), or underscore (“_”) only.

� cannot contain text “BALANCE ACCOUNT” or “NONDISCLOSED” (upper or lower case)

Note: The instruction for the omnibus account (/Pty/Sub@ID Typ = “42”) and the details of the disclosed customer positions (/Pty@ID R=“24”) must be provided in the same GCM file.

/Pty@ID R=”21” Clearing House Code EU: “ICEU” – ICE Clear EU US: “ICUS” – ICE Clear US CA: “ICCA” – ICE Clear Canada SG: “ICSG” – ICE Clear Singapore

/Pty@ID R=”22” Exchange Code Optional

EU: “IFEU” - ICE Futures EU “IFED” - ICE Future Energy Division “NDEX” - ICE ENDEX Futures EU “IFUT” - European Utilities Division “IFEN” - Oil and Refined Products Division “IFLL” - Financial Products Division “IFLO” - Equity Products Division “IFLX” - Agricultural Products Division US: “IFUS” – ICE Futures US

CA: “IFCA” – ICE Futures Canada SG: “IFSG” – ICE Futures Singapore

Notes:

a. ICE’s use of “Position Account” (role no. 38) differs from CME’s use. The details highlighting the changes are covered in Appendix Section 3.4.

b. A new attribute/element called Legal Entity Identifier “LEI” will be added to the specifications once the FIX committee has finalised specifications for this field. The “LEI” will complement or replace the Customer Account field for identifying a Customer.


2.3.5 Quantity Blocks (Qty)

GCM uses quantity blocks to indicate the firm’s outright and spread positions. The table below lists the quantity blocks to be used for GCM submission.

FIXML Tag Description Values /Qty@Typ Type of Quantity “TQ” for final position

“DLV” – for positions in delivery. ICUS & ICCA only. This is to enable members to report positions which are in delivery. In ICUS, a seller can notify intent for delivery prior to the actual settlement date. The quantity type of “DLV” must be used to report such positions. Note: Any positions reported as open futures positions after contract settlement date will be automatically converted into the underlying delivery positions for the purpose of calculating Customer Balancing Account and Gross Margining.

/Qty@Long Gross Long Quantity Numeric Value – Long position on Customer account specified by /Pty@ID R=”24”. Firms can report Gross Customer Position i.e. Both Gross Long Quantity & Gross Short Quantity are non-zero. The margin calculation for each customer will continue to be calculated on the net basis.

If /Pty@ID R=”24” relates to an omnibus account on the book of the Clearing Member, CH will accept both long and short values.

/Qty@Short Gross Short Quantity Numeric Value - Short position on Customer account specified by /Pty@ID R=”24” Firms can report Gross Customer Position i.e. Both Gross Long Quantity & Gross Short Quantity are non-zero. The margin calculation for each customer will continue to be calculated on the net basis.

If /Pty@ID R=”24” relates to an omnibus account on the book of the Clearing Member, CH will accept both long and short values.


Clearing House Expects Members to submit Customer Positions per Contract and not trade level data. Clearing House will only accept one instruction in a file for a Customer Account Identifier, Parent Omnibus Account and Contract key combination. Any subsequent instructions having identical Customer Account Identifier, Parent Omnibus Account and Contract will be rejected.


3. Appendix

3.1 FIXML GCM File Examples – ICE Clear EU


3.1.1 ICEU - Scenario 1

Clearing Member “TCU” providing Clearing house with the customer positions for customers “TCUW-CUST3” & “TCUW-CUST4” underlying their Position Account “W”.

Message Time Clearing Org Member Exchange ID Trading (Clearing) Firm Position Account Customer Account Customer Name/Full Legal Name

Customer Account Type

Period Code (‘00’ for Monthly Expirations) Final Long or Short Position Qty




ID="B" Product Code MMY="20120400"/> Period Code (‘00’ for Monthly Expirations) Final Long or Short Position Qty



Clearing Member “TCU” has a relationship with FCM “FNY”. However, FNY is not configured in the ICE Clearing systems & therefore their positions are reflected in the TCU “W” account underlying account “FNYOMNI”. This scenario covers Clearing Member “TCU” providing Clearing House with the position details for the omnibus account “FNYOMNI” and the position for each disclosed customer account (FNY-CUST5 and FNY-CUST6) underlying this omnibus account within TCU’s “W” Position Account. GCM Instruction providing details for the Omnibus Account “FNYOMNI” Message Time Clearing Org Member Exchange ID Trading (Clearing) Firm Position Account Customer Account Customer Name/Full Legal Name

Customer Account Type; “O” for omnibus account

Strike Price (Can be negative) Final Long and/or Short Position Qty

GCM Instruction providing Customer Position for “FNY-CUST5” underlying Omnibus Account “FNYOMNI” Message Time


Clearing Org Member Exchange ID Trading (Clearing) Firm Position Account Customer Account Customer Name/Full Legal Name

Customer Account Type Parent Omnibus Account, if relevant

Strike Price (Can be negative) Final Long or Short Position Qty

GCM Instruction providing Customer Position for “FNY-CUST6” underlying Omnibus Account “FNYOMNI” Message Time Clearing Org Member Exchange ID Trading (Clearing) Firm Position Account Customer Account Customer Name/Full Legal Name


Strike Price (Can be negative) Final Long or Short Position Qty


Note: If the total positions for each customer do not match the positions provided for the parent Omnibus account, the balance is considered as non-disclosed. Non-disclosed customer positions are not allowed in ICEU.


This scenario depicts reporting of customer positions underlying omnibus account which itself is underlying another parent omnibus account (omnibus account hierarchy).

Clearing Member “TCU” providing Clearing House with details for omnibus account “ABYSUBOMNI” (which is underlying another omnibus account “FNYOMNI”).


Customer Account Type; “O” for Parent omnibus ac Parent Omnibus Account, if relevant

Period Code (‘00’ for Monthly Expirations) Final Long and/or Short Position Qty

Customer Positions underlying omnibus account “ABYOMNI” Message Time



Customer Account Type; “O” for Parent omnibus ac Parent Omnibus Account, if relevant



“TMU” is a Trading Member that is set-up on ICE Clearing systems. “TMU” has customers “TMUW-CUST1” and “TMUW-CUST2” and clears via Clearing Member “TCU”. Below scenario relates to the Clearing Member “TCU” submitting customer positions underlying Trading Member TMU’s “W” position account. In ICEU, a Trading Member can also submit their customer positions directly to ICE.








Note: No Omnibus Account is specified here as the Customer Positions reported are reported directly in relation to TMU’s “W” Position Account. These Positions are not reflected within the “W” Position Account of TCU in the same way as those relating to FNY are.


3.2 FIXML GCM File Examples – ICE Clear US

3.2.1 ICUS - Scenario 1

Clearing Member “133” providing Clearing House with Customer Positions for “113C-CUST3” & “113C-CUST4” underlying their Position Account “C”.

Message Time









This scenario relates to Clearing Member “133” providing Clearing house with the Customer Positions underlying partially disclosed Omnibus account “111OMNI”. The submission is made up of a) total position for omnibus account “111OMNI” and a) position for disclosed customer account “111-CUST5” underlying


“111OMNI”. Clearing House will derive the non-disclosed positions underlying “111OMNI” by subtracting customer positions for “111-CUST5” from the total position for “111OMNI” omnibus position account. GCM Instruction providing position for the Omnibus Account “111OMNI”: Message Time Clearing Org Member Exchange ID Trading (Clearing) Firm Position Account Customer Account Customer Name/Full Legal Name



GCM Instruction providing Customer Position for “111-CUST5” underlying Omnibus Account “111OMNI”: Message Time Clearing Org Member Exchange ID Trading (Clearing) Firm Position Account Customer Account Customer Name/Full Legal Name




Clearing House will derive the non-disclosed position underlying the omnibus account “111OMNI” as Long = “1100” and Short = “100” by subtracting each disclosed customer positions from the total omnibus account position.


This scenario relates to Clearing Member “133” providing Clearing house with the Positions underlying Non-disclosed omnibus account “222OMNI”.

As there are no disclosed Customer account details provided for the omnibus account “222OMNI”, the Clearing House will derive the non-disclosed account against “222OMNI” as Long="143" Short=”342”.






“731” is a Clearing Member Division who is also set-up on ICE Clearing systems. “731” has customers “731C-CUST1” and “731C-CUST2” and clears via Clearing Member “133”. Below scenario relates to the Clearing Member “133” submitting customer positions underlying Member “731C” position account.









Reporting of Customer Positions for a contract (for e.g. SB 20120400) that is in delivery prior to the contract settlement date. In the example below, clearing member is reporting that Customer “731C-CUST1” is 400S in the futures position for SB 20120400 and also 342S in the SB 20120400 delivery position (reported by Qty Typ = “DLV”).





TxnTm="2012-03-28T00:00:00"> Message Time Clearing Org Member Exchange ID Trading (Clearing) Firm Position Account Customer Account Customer Name/Full Legal Name


Period Code (‘00’ for Monthly Expirations) Final Long or Short Position Qty.

Typ = “DLV” - Reporting of positions in delivery

3.3 FIXML GCM File Examples – ICE Clear Canada ICE Clear Canada’s implementation of Gross Margining will be the same as ICE Clear USA’s except for the following:

Clearing Org Member Exchange ID Product Exchange ID


3.4 Comparison of Position Accounts Usage between ICE and CME There is variability across the CCP’s in the usage of the “position account” role (role number 38) in FIXML. (CCP’s use the term “position account” in the same manner, but differ in how the value is assigned). For the sake of discussion, we’ll denote this as the “CME usage” and the “ICE usage”. For CME: Position account is a value, typically three or four alphanumeric bytes, which Clearing firms typically do not know and do not use. It is provided by CME on output back to the firm, but again, firms typically do not know and do not use it. Rather, CME derives the position account from the submitted data: (a) the trade management firm ID; (b) the product; (c) the customer account and origin code. Note that the origin is submitted as a sub role of the customer account. So the party submission for CME would look something like this: // Clearing organization // Clearing Member firm ID // firm exchange // trade mgmt firm ID // customer account // customer origin // account name

3.5 Calculation and Margining of Customer Balance Account The Clearing House has made changes to the way the Customer Balancing account is calculated and margined. This is for several reasons. First, if the GCM submissions are over-reported, we will not calculate and margin firms on the customer balancing account in relation to the specific position account and contract. The second change relates to the scenario where the firm has under reported their GCM submissions. This can happen if the firm has not yet closed out their position on the Clearing House books but the GCM reported is net by customer. In cases where the customer balancing account long is equal to the customer balancing account short, we do not margin the resulting balance account. However, if the balance account long is not equal to balance account short, the long and the short positions are margined outright. Please see examples below for further clarification.

Customer Balance Account Calculation - Examples (in relation to a specific position account and contract) – below applies to ICEU, ICUS and ICCA:

Clearing House

GCM Balancing Account Marginable Balancing Account

Comments #

Long Short Long Short Long Short Long Short

[CH Long - MIN(CH Long, GCM Long)]

[CH Short - MIN(CH Short, GCM Short)]

1

1000 1000 5 5 995 995 0 0 Since customer balance account Long is equal to customer

balance account Short, the

marginable customer balance account will be zero.

2

1000 1000 4 5 996 995 996 995 Since customer balance account

Long is not equal to customer

balance account Short, the balance account Long and Short

will be margined outright.

1000 1000 2000 2000 0 0 0 0 Since total GCM submissions are

greater than Clearing House

position, the Clearing House will

not generate a balancing

account

3

4 1000 1000 500 1500 500 0 500 0 The “GCM submissions short” is

greater than the CH short position. Only customer balance

account on the long position is created in this scenario.

ICE - Clear CA, EU, US & SG Combined Gross Customer Margin (GCM… · 2. The GCM Process 2.1 Mechanism of Submission Members will submit the GCM files to ICE’s MFT server via sftp

Documents