Please respond to: LME Clear Relationship Management Lmeclearing@lme.com This document is published by LME Clear Limited. To the best of the publisher s knowledge and belief, statements made regarding EMIR reporting requirements are correct at the time of going to press. All such statements and all opinions expressed herein are published for the general information of readers but are not to be taken as recommendations for any course of action. The publisher accepts no liability for the accuracy of any statement or representation. Exposure Data Reporting User Requirements
Contents 1 Introduction 4 2 Daily Reporting of LME ETD s with MTM 4 2.1 & MTM File formats 7 2.2 s, Mini / Index Futures and Average Price Futures s File 7 2.2.1 Filename 7 2.2.2 Header Record 7 2.2.3 Records 8 2.2.4 File example 8 2.3 Traded s and TAPOs s File 9 2.3.1 Filename 9 2.3.2 Header Record 9 2.3.3 Records 9 2.3.4 File example 10 3 Daily Reporting of Collateral Holdings 10 3.1 Collateral posted to Users by Clients 10 3.2 Initial Margin Requirements 10 3.2.1 Filename 11 3.2.2 Header Record 11 3.2.3 Collateral Records 11 3.2.4 File example 12 4 Ad Hoc Reporting of Lifecycle Events on LME s 12 4.1 Lifecycle Events 12 4.1.1 Filename 13 4.1.2 Header Record 13 4.1.3 Life-cycle Event Records 14 4.1.4 File example 14 5 LME Lifecycle Event triggers 15 5.1 Exercise on final exercise day for American style traded : 15 5.2 Automatic exercise of Asian style TAPOs : 15 5.3 Early exercise on American style traded : 15 5.4 Transfer 15 5.5 Early Termination used by LME Clear only to manage a Default 15 5.6 Compression 15 6 LME Lifecycle Event Examples 16 6.1 Exercise on final exercise day for American style traded : 16 6.2 Automatic exercise of Asian style TAPOs : 18 6.3 Early exercise on American style traded : 20 Page 2
Change Log Date Version Change 25/09/15 0.2 Changes in this version cover: New LME Clear Compression service New LME Premium Aluminium and Ferrous Cash Steel contracts Reporting changes resulting from EMIR Data Validation Level 2 Removal of LBMA Gold & Silver contract references Specific changes are as follows: - 1 Introduction updated to current state - References to OTC LBMA Gold and Silver contracts, which are no longer captured via the LME, removed from various sections of document. Cleared OTC Gold & Silver s File section completely removed. - 2 Daily Reporting of LME ETD s with MTM updated with LMEwire Output section to clarify the outputs reported to DTCC dependent on the member inputs - 2.2 s, Mini / Index Futures and Average Price Futures s File and 4 Ad Hoc Reporting of Lifecycle Events on LME s updated to include details for reporting new Premium Aluminium and Ferrous Cash Steel contracts - 4 Ad Hoc Reporting of Lifecycle Events on LME s updated to include reporting of changes when using the LME Clear Compression service Page 3
1 Introduction LMEwire currently provides an automatic trade reporting service for LME matched contracts for certain LME Clearing Members to the DTCC Trade Repository; LMEwire takes its trade feed for this reporting service directly from LMEmercury. The requirement to report trades under EMIR came into force in February 2014. In accordance with Article 5 of the Commission Delegated Regulation (EU) No 1247/2012 of 19 December 2012, the reporting start date shall be extended by 180 days for the reporting of information regarding the exposure data (collateral and mark to market data). Therefore Valuation and Collateral data reporting to trade repositories came into effect from 11th August 2014. LMEwire was previously enhanced to support the reporting of valuation and collateral data. It is the industry approach that for Exchange Traded Derivatives, ETD, and MTM is held at a level and that Collateral is held at an account/portfolio level. Users submit basic valuation and collateral data daily to LMEwire in a.csv file format; LMEwire then appropriately enriches this basic data to meet the EMIR reporting requirements. The LMEwire.csv file format has been modelled on that used by LME Clearing Members for their daily DPRS reporting to the Exchange. However Users need to be aware that the LMEwire file, in order to meet EMIR reporting criteria, requires different data extracts and additional calculated values. For the avoidance of doubt this LMEwire reporting process is additional to, and separate and distinct from, the Exchange DPRS requirement that remains in place and is unchanged. This document provides the specifications for the daily files that LMEwire Users will have to provide to LMEwire for EMIR exposure data reporting. With regard to the process for the submission of files to LMEwire, Users should refer to the LMEwire User guide. 2 Daily Reporting of LME ETD s with MTM s, for the purpose of EMIR reporting of ETD, are calculated as the net of the long and short obligations for each traded instrument for each account. All s and valuations are reported from the point of view of the Account being reported. LME s File examples: Non-financial Counterparties below the clearing threshold, NFC minus, are exempted from this reporting. It is up to the Page 4
Reported Data File Row L,ABC,H001,CAD,F,20140924,10,USD,5000.00 Interpretation The account, H001, (Member ABC s main House account) is long 10 lots of LME CAD s for Prompt 24Sep14 and the MTM on the is positive USD5,000.00 in favour of the House account. ABC is long and is making money on the. L,ABC,CLI001,AAD,F,20140924,100,USD,555.00 The account, CLI001, (Client 1 s account with ABC) is long 100 lots of LME AAD s for Prompt 24Sep14 and the MTM on the is positive USD555.00 in favour of the Client account. Client 1 is long and is making money on the. A traded instrument is defined as a combination of the transaction type, the Exchange product code and the prompt date. For options the nature of the option, call or put, and the strike price are included as additional instrument parameters. Instrument examples: Parameter Instrument Instrument Type Traded Exchange Product Code CAD AHE Prompt Date 16 th October 2014 3 rd December 2014 (DEC 14) Call / Put - Call Strike Price - 2,000.00 In this case account means a trading account in the Users books and records that directly corresponds to one of the Client Codes provided in the LME DPRS reporting of the User. MTM is calculated on a basis and therefore it is appropriate to report s and to extend the reporting record for each instrument to include the MTM calculated as at close of business T+0 for that instrument when its is reported on T+1 LMEwire interprets that Mark to Market, MTM, should be reported for each, for each account, according to the Variation Margin methodology applicable to the relevant traded instrument. Therefore as at close of business on T+0: On an LME forward the MTM will be the Discounted Contingent Variation Margin, DCVM. On an LME traded option or TAPO the MTM will be the Net Liquidation Value, NLV. On an LME Mini, Index future or Ferrous Cash Steel it will be zero, as the daily Realised Variation Margin, RVM, is realised on a daily basis and effectively reduces the MTM to zero overnight. Page 5
Also, in line with the FIA Europe WG interpretation of the ESMA Q&A: valuation date and time will be hardcoded and reported as 23:59:00 UTC on T+0 Valuation type will be M, MTM, as opposed to mark to model. The User will need to produce daily file extracts of s with MTM values to be consumed by LMEwire in order for LMEwire to be able to provide a complete delegated EMIR reporting service. The requirements of these files are that at a minimum they have to allow identification of the following: The LMEwire User The Account being reported* The Instrument to which the relates The direction and size The MTM direction and size *LMEwire must possess sufficient static data to allow it to attribute the account reference provided by the Submitter to the correct counterparty legal entity, i.e. LMEwire must be able to roll up the account to the relevant LEI be that the User s, for an internal account, or a Client s. Tables are provided on the basis that separate files are created for: s, Mini and Index Futures and Average Price Futures Traded s and TAPOs In all cases each data input file consists of a single header record followed by zero or more records. The header record layout is identical for all data input files. The record layouts vary between the different data input files. All fields must be present except where expressly noted otherwise. The reporting of null s, where BOTH the underlying instrument net and the MTM value are nil will be supported by LMEwire when 0 is present in the relevant fields in the file record. However, LMEwire s understanding is that null s do not need to be reported. For the avoidance of doubt, square or flat s, where the underlying instrument net is nil but there remains a forward open MTM value, either positive or negative, are expected to be reported. LMEwire output As a result of the introduction of EMIR Level 2 Validation, which comes into effect on 2nd November 2015, LMEwire will take & MTM files reported to LMEwire by users and create separate and MTM records that will be reported to the DTCC. and MTM records received by LMEwire will lead to 2 or 4 records being reported by LMEwire to DTCC. If the Account ID / Client Code provided in a & MTM record: applies to the member (i.e. it has been recorded in LMEwire as such) there will be 2 records reported - 1 and 1 MTM for the member Page 6
applies to a member s client that uses LMEwire for reporting, there will be 4 records reported 1 and 1 MTM for the client and 1 and 1 MTM for the member cannot be found in LMEwire, there will still be 2 records reported - 1 and 1 MTM for the member 2.1 & MTM File formats All of the files described in this section are in plain ASCII text format, that is to say they include the characters 0x20 to 0x7E Plus CR (0x0D), LF (0x0A), TAB (0x09) only. Each file consists of a number of records. Each record is a single line of text, terminated by the CR and LF characters. Each record consists of one or more data fields, which are comma separated. Any space characters between fields are ignored. Fields must be comma delimited, and the record must contain only ASCII characters. 2.2 s, Mini / Index Futures and Average Price Futures s File The daily file should contain one record for each open instrument for each Account ID/Client ID. 2.2.1 Filename The daily s, Mini / Index Futures and Average Price Futures s File must be called: LME_WIRE_POS_FWD_FUT_[MEMBER]_[YYYY]-[MM]-[DD].csv Where: [YYYY] indicates a four-digit year, 0000 through 9999. [MM] indicates a two-digit month of the year, 01 through 12. [DD] indicates a two-digit day of that month, 01 through 31. This date in the Filename is expected to be the date on which the file is being loaded to LMEwire 2.2.2 Header Record Field Name Field Comment Record Type X H Report Date X (8) ISO format, YYYY-MM-DD e.g. 2014-09-22 Member mnemonic X (3) i.e. ABC Note: The Report Date in the Header File is the date of the data being provided to LMEwire; i.e. if a User is reporting valuation data as at COB 22Sep14 on 23Sep14 then the date in the Header record will be 2014-09-22. Page 7
2.2.3 Records Field Name Field Comment Record Type X L Member Code X (3) i.e. ABC Account ID / Client Code X (up to 20) Defined by the Member, may use HOUSE or CLIENT for CCP accounts but expect Client codes to be consistent with those in Member DPRS reporting and LMEsmart TAG 109 Client ID. Should allow for LEI), e.g. 12345678901234567890 (Not padded) Exchange Product Code X (3) i.e. AAD, AAE, AAS, AAY, AHD etc. Contract Type Prompt Date X 9 (8) or X (5) 9 (up to 10) F, M, I or S for s, Minis, Index or Average Price Futures respectively ( F includes Premium Steel and Ferrous Cash steel contracts: AND, AWD, AED, ASD, SBD, SCD, SRD) YYYYMMDD for s other than Ferrous Cash Steel (SBD, SCD, SRD), where Prompt format must be MMMYY MMMYY for Minis, Index or Average Price Futures Number of. Whole number value, can be positive, negative or zero MTM Value Currency X (3) ISO format, i.e. USD, EUR, GBP or JPY etc. MTM Value 9 (14) Allow 2 decimal points. Can be positive, negative or zero Note that duplicate records are not allowed within a single file for each unique combination of Member Code, Client Code, Exchange product Code, Contract Type and Prompt date only one record is allowed in a single file. Duplicate records will result in a warning message in LMEwire. Duplicated records are permitted across separate files to allow for corrections. 2.2.4 File example H,2014-09-22,ABC RecordType,MemberCode,ClientCode,ExchangeProductCode,ContractType,PromptDate,,Mt mvaluecurrency,mtmvalue L,ABC,H001,CAD,F,20140924,10,USD,5000.00 L,ABC,CLI001,AAD,F,20140924,100,USD,555.00 L,ABC,CLI001,AHD,F,20140924,-1000,USD,4567.00 L,ABC,CLI001,OLD,S,OCT14,1000,USD,-250000.00 Page 8
2.3 Traded s and TAPOs s File The daily file should contain one record for each open instrument for each Account ID/Client ID. 2.3.1 Filename The daily Traded s and TAPOs s File must be called: LME_WIRE_POS_OPT_[MEMBER]_ [YYYY]-[MM]-[DD].csv Where: [YYYY] indicates a four-digit year, 0000 through 9999. [MM] indicates a two-digit month of the year, 01 through 12. [DD] indicates a two-digit day of that month, 01 through 31. This date in the Filename is expected to be the date on which the file is being loaded to LMEwire. 2.3.2 Header Record See 2.2.2 2.3.3 Records Field Name Field Comment Record Type X O Member Code X (3) i.e. ABC Account ID / Client Code X (up to 20) Defined by the Member, may use HOUSE or CLIENT for CCP accounts but expect Client codes to be consistent with those in Member DPRS reporting and LMEsmart TAG 109 Client ID Exchange Product Code X (3) i.e. AAD, AAE, AAS, AAY, AHD etc. Contract Type X T or A, for Traded s or TAPOs respectively Type X C (Call) or P (Put) Strike Price 9 (10) Must be a positive number Prompt Date 9 (8) or X (5) 9 (up to 10) MMMYY Number of. Whole number value, can be positive, negative or zero MTM Value Currency X (3) ISO format, i.e. USD, EUR, GBP or JPY etc. MTM Value 9 (14) Allow 2 decimal points. Can be positive, negative or zero Note that duplicate records are not allowed within a single file for each unique combination of Member Code, Client Code, Exchange product Code, Contract Type, Type, Strike Price and Prompt date only one record is allowed in a single file. Duplicate records will result in a Page 9
warning message in LMEwire. corrections. Duplicated records are permitted across separate files to allow for 2.3.4 File example H,2014-09-22,ABC RecordType,MemberCode,ClientCode,ExchangeProductCode,ContractType,Type, StrikePrice,PromptDate,,MtmValueCurrency,MtmValue O,ABC,CLI001,AHD,T,C,1600,OCT14,1000,USD,300000.00 O,ABC,CLI001,AHD,A,P,1600,OCT14,-100,USD,-300.00 3 Daily Reporting of Collateral Holdings Collateral requirements are calculated on an account/portfolio basis to cover all the open s within that account/portfolio. FIA Europe WG interpretation of the most recent ESMA Q&A: ETD s are one-way collateralised, OC ; Clients lodge collateral with Members; Members lodge collateral with the CCP. Collateral reporting is executed by the entity lodging the collateral, Clients report collateral lodged with Members, Members report collateral lodged with the CCP. The value of collateral is to be reported without the application of haircuts. Therefore it is proposed that LMEwire Users provide the following information on a daily basis to LMEwire. 3.1 Collateral posted to Users by Clients To support delegated reporting for clients, for each account/portfolio the User should report the total value of collateral held, together with the currency code of that value, for that account/portfolio. 3.2 Initial Margin Requirements At the present time, ESMA does not require the reporting of Initial Margin requirements on ETD s. However, it is possible that this will change and that Clearing Members may in the future be required to report a total risk exposure to individual Client accounts, i.e. to report either the Initial Margin Requirement for each account or the net total of both the Initial Margin and the Variation Margin for each account. In order to cater for this possible future requirement the Collateral Holdings reporting file format allows for the User to pass a calculated Initial Margin value for each account to LMEwire. (The Variation Margin is already being passed to LMEwire as part of the daily and MTM reporting detailed in Section: Error! Reference source not found. Error! Reference source not found..) Page 10
At the present time LMEwire Users may choose whether they report zero in the Initial Margin Requirement field for each account or whether they populate it with the correctly calculated IM value for each account. The requirements of this file are that, at a minimum, it has to allow identification of the following: The LMEwire User The Account being reported* The Collateral Holding Value Currency The Collateral Holding Value *LMEwire must possess sufficient static data to allow it to attribute the account reference provided by the Submitter to the correct counterparty legal entity, i.e. LMEwire must be able to roll up the account to the relevant LEI be that the Submitter s, for an internal account, or a Client s. 3.2.1 Filename The daily Collateral Holdings File must be called LME_WIRE_COL_[MEMBER]_ [YYYY]-[MM]-[DD].csv Where: [YYYY] indicates a four-digit year, 0000 through 9999. [MM] indicates a two-digit month of the year, 01 through 12. [DD] indicates a two-digit day of that month, 01 through 31. This date in the Filename is expected to be the date on which the file is being loaded to LMEwire. 3.2.2 Header Record See 2.2.2 3.2.3 Collateral Records Field Name Field Comment Record Type X C Member Code X (3) i.e. ABC Account ID / Client Code Collateral Value Currency X (up to 20) X (3) Defined by the Member, may use HOUSE or CLIENT for CCP accounts but expect Client codes to be consistent with those in Member DPRS reporting and LMEsmart TAG 109 Client ID. (Should allow for LEI), e.g. 12345678901234567890 ISO format allowed, i.e. USD Collateral Value 9 (20) Allow 2 decimal points, expected to be positive or zero Page 11
Initial Margin Requirement 9 (20) This will be the USD requirement calculated by USER for each account. May be reported as 0 at this time. (Need not be signed but will always be taken as a liability for the named account.) Duplicated records are permitted within a single file. Duplicated records are permitted across separate files to allow for corrections. 3.2.4 File example H,2014-09-22,ABC RecordType,MemberCode,ClientCode,CollateralValueCurrency,CollateralValue,InitialMar ginrequirement C,ABC,CLI001,USD,5000000.00,15000.00 C,ABC,CLI002,USD,250000.00,150000.00 C,ABC,CLI003,EUR,336.00,500700.00 4 Ad Hoc Reporting of Lifecycle Events on LME s This requirement applies the following principles: that the Lifecycle Event reporting should provide the audit trail for any change to a that is not covered by either the booking of a new trade or the expiry of the instrument at the expected termination date, and that there will be only one net Lifecycle Event reported for a single UTI, on a single business day for an individual account, and that nil s, which are zero for both the underlying and MTM, are not reported. 4.1 Lifecycle Events The Lifecycle Events that are applicable to LME products are: Exercise/Abandonment & Assignment for: o Early Exercise and Assignment on American style traded s, o Exercise/Abandonment and Assignment on final exercise day for American style traded s, o Automatic Exercise/Abandonment and Assignment of Asian style TAPOs s, Transfer Early Termination under LME Rules used only by the CCP to manage Default Compression LME Clear compression service has been utilised to reduce number of open trades but net remains the same. Change field should be populated with zero The requirements of this file are that, at a minimum, it has to allow identification of the following: The LMEwire User The Account being reported* Page 12
The Instrument to which the Life-cycle Event relates The Change direction and size The Lifecycle Event Type OE, OA, PT ET or CO *LMEwire must possess sufficient static data to allow it to attribute the account reference provided by the Submitter to the correct legal entity, i.e. LMEwire must be able to roll up the account to the relevant LEI be that the Submitter s, for an internal account, or a Client s. A single file is designed to handle events for both Futures and s. Where Contract Type is shown as F, M, I or S the fields for Type and Strike Price should be populated with zero. Where Contract Type is shown as T or A, fields for Type and Strike Price must be populated with a non-zero value. Change field contains the number of lots that the is changing by because of the Lifecycle Event and not the End of Day. In line with all other reporting, all changes are reported from the point of view of the Account being reported. The resulting from a Lifecycle Event, and the addition of any new trades, will be reported as part of the daily file submitted by the Member under Section: 2 2 Daily Reporting of LME ETD s with MTM. The ad hoc file should contain one Lifecycle Event record for each open instrument change for each Account ID/Client ID, i.e. there will be only one net Lifecycle Event for a single UTI on a single business day for an individual account. 4.1.1 Filename The ad hoc Lifecycle Event Reporting File must be called LME_WIRE_LIF_[MEMBER]_ [YYYY]-[MM]-[DD].csv Where: [YYYY] indicates a four-digit year, 0000 through 9999. [MM] indicates a two-digit month of the year, 01 through 12. [DD] indicates a two-digit day of that month, 01 through 31. This date in the Filename is expected to be the date on which the file is being loaded to LMEwire. 4.1.2 Header Record See 2.2.2 Page 13
4.1.3 Life-cycle Event Records Field Name Field Comment Record Type X E Member Code X (3) i.e. ABC Account ID / Client Code X (up to 20) Defined by the Member, may use HOUSE or CLIENT for CCP accounts but expect Client codes to be consistent with those in Member DPRS reporting and LMEsmart TAG 109 Client ID. (Should allow for LEI), e.g. 12345678901234567890 Exchange Product Code X (3) i.e. AAD, AAE, AAS, AAY, AHD etc. Contract Type X F, M, I or S for s, Minis, Index or Average Price Futures respectively ( F includes Premium Steel and Ferrous Cash steel contracts: AND, AWD, AED, ASD, SBD, SCD, SRD) T or A, for Traded s or TAPOs respectively Type X C (Call) or P (Put) Strike Price 9 (10) Must be a positive number Prompt Date 9 (8) or X (5) YYYYMMDD for s, other than Ferrous Cash Steel (SBD, SCD, SRD), where Prompt format must be MMMYY MMMYY for Minis, Index or Average Price Futures, Traded s TAPOs Change 9 (up to 10) Number of. Whole number value, can be positive, negative or zero Possible Values: Lifecycle Event Type X (2) OE Exercise, OA Assignment, PT Transfer, ET Early Termination or CO - Compression. Note that duplicate records are not allowed within a single file for each unique combination of Member Code, Client Code, Exchange product Code, Contract Type, Type, Strike Price and Prompt date only one record is allowed in a single file. Duplicate records will result in a warning message in LMEwire. Duplicated records are permitted across separate files to allow for corrections. 4.1.4 File example H,2014-11-05,ABC RecordType,MemberCode,ClientCode,ExchangeProductCode,ContractType,Type,StrikePric e,promptdate,change,lifecycleeventtype E,ABC,CLI001,AHD,F,0,0,20141119,100,OE E,ABC,CLI001,CAD,F,0,0,20141119,-250,OA E,ABC,CLI002,ZSD,T,C,1600,DEC14,-50,PT E,ABC,CLI003,ZSD,T,C,1600,DEC14,50,PT Page 14
5 LME Lifecycle Event triggers 5.1 Exercise on final exercise day for American style traded : Although the instrument is reduced to zero in line with the expiry date of the instrument, irrespective of whether a strike was exercised or abandoned, in order to provide an adequate audit trail it is seen as necessary to report Life-cycle Events detailing the volumes exercised and assigned against the instrument. The s is adjusted by the exercised and assigned option business events, net across all option strikes, and therefore to provide the audit trail Lifecycle events need to be reported for these changes to the net underlying s s. 5.2 Automatic exercise of Asian style TAPOs : Although the instrument is reduced to zero in line with the expiry date of the instrument, irrespective of whether a strike was exercised or abandoned, in order to provide an adequate audit trail it is seen as necessary to report Life-cycle Events detailing the volumes exercised and assigned against the instrument. The s is not impacted on a net basis by the exercised and assigned option events, although there is a cashflow/mtm impact, and therefore no Lifecycle Events need to be reported against the net underlying s s. 5.3 Early exercise on American style traded : In this case, both the and the underlying change on a date that does not correspond to the expected expiry date of either the instrument or the underlying s instrument. Therefore, to provide the necessary audit trail for the changes two Lifecycle events need to be reported: o one in the instrument, and o one in the underlying 5.4 Transfer Should produce two Lifecycle events: o One audit trailing the removal/expiry of the on the account losing the instrument o One audit trailing the creation of the on the account gaining the instrument 5.5 Early Termination used by LME Clear only to manage a Default Should produce a single Lifecycle Event showing the early termination of the instrument 5.6 Compression More than 1 open is compressed in LMEmercury using the LME Clear compression service Page 15
6 LME Lifecycle Event Examples 6.1 Exercise on final exercise day for American style traded : Partial Exercise on Final Exercise Date of American style traded on the Buyers Account: (10 lots Exercised, 10 lots Abandoned on = Final Exercise Date) Date Buy Sell UTI type Reported as Type (EMIR Field 58) Details of (EMIR Field 59) Sell 50 CAD Buy 20 7000 Calls 50 CAD Buy/Long 20 7000 Calls Exercise 10 7000 Calls Exercise Abandon 10 7000 Calls Abandon business event not reported because option is due to be zero at end of as instrument expires on that date. Exercise Future Buy/Long 10 CAD Exercise Buy/Long NIL Expired not reported. 40 CAD Partial Assignment on Final Expiry Date of American style traded on the Sellers Account: (10 lots Assigned, 10 lots Expired on = Final Exercise Date) 2 Exercise or Assignment is reported as a reversal of the existing instrument and is not dependent on Put or Call, e.g. the exercise event for a Long Call option would also be shown as a event Assumes reporting entity has the status of a Full reporter with the TR. Page 16
Date Buy Sell UTI type Reported as Type (EMIR Field 58) Details of (EMIR Field 59) Sell 20 7000 Calls 20 7000 Calls Assigned Buy/Long 10 7000 Calls Other Assignment Expired/Abandon Buy/Long 10 7000 Calls Abandon business event not reported because option is due to be zero at end of as instrument expires on that date. Assigned Future 10 CAD Other Assignment NIL Expired not reported. 10 CAD Page 17
6.2 Automatic exercise of Asian style TAPOs : Automatic exercise of Asian style TAPOs on the Buyers Account: ( = Automatic Exercise Date, AHD December USD2, 200 Puts In the Money - Exercise AHD December USD2,500 Calls Out of the Money Expire) Date Buy Sell UTI type Reported as Type (EMIR Field 58) Details of (EMIR Field 59) Buy 10 AHD 05Jan15 Buy 10 2200 Puts Buy 10 2500 Calls Buy/Long 10 AHD 05Jan15 Buy/Long 10 2200 Puts Buy/Long 10 2500 Calls Exercise 10 2200 Puts Other Exercise Abandon 10 2500 Calls Abandon business event not reported because option is due to be zero at end of as instrument expires on that date. Exercise Future NIL AHD 05Jan15 Exercise business event not reported as net zero and cashflow/valuation impact on underlying only Buy/Long NIL 2200 Puts Expired not reported. Buy/Long NIL 2500 Calls Expired not reported. Buy/Long 10 AHD 05Jan15 Page 18
Automatic exercise of Asian style TAPOs on the Sellers Account: ( = Automatic Exercise Date, AHD December USD2,200 Puts In the Money - Exercise AHD December USD2,500 Calls Out of the Money Expire) Date Buy Sell UTI type Reported as Type (EMIR Field 58) Details of (EMIR Field 59) Sell 10 2200 Puts Sell 10 2500 Calls 10 2200 Puts 10 2500 Calls Assigned Buy/Long 10 2200 Puts Other Assignment Expired/Abandon Buy/Long 10 2500 Calls Abandon business event not reported because option is due to be zero at end of as instrument expires on that date. Assigned Future Buy/long NIL AHD 05Jan15 Assignment business event not reported as net zero and cashflow/valuation impact on underlying only NIL Expired not reported. NIL Expired not reported. Buy/long NIL AHD 05Jan15 Page 19
6.3 Early exercise on American style traded : Early full exercise on American style traded on the Buyers Account: Date Buy Sell UTI type Reported as Type (EMIR Field 58) Details of (EMIR Field 59) Sell 50 CAD Buy 15 50 CAD Buy/Long 15 Exercise 15 1 Other Exercise Exercise Future 15 CAD Other Exercise Buy/Long NIL fully Exercised not reported. 65 CAD Early full assignment on American style traded on the Sellers Account: 4 Exercise or Assignment is reported as a reversal of the existing instrument and is not dependent on Put or Call, e.g. the exercise event for a Long Call option would also be shown as a event. Page 20
Date Buy Sell UTI type Reported as Type (EMIR Field 58) Details of (EMIR Field 59) Sell 15 15 Assigned Buy/Long 15 Other Assignment Assigned Future Buy/Long 15 CAD Other Assignment NIL fully Assigned not reported. Buy/Long 15 CAD Page 21