How To Comply With The European Market Infrastructure Regulation

Transcription

1 IMPROVING THE FUNCTIONING OF THE OTC DERIVATIVES MARKETS IN THE EUROPEAN UNION SUMMARY OF TECHNICAL STANDARDS FOR THE REGULATION ON OTC DERIVATIVES & TRADE REPOSITORIES

2 ABOUT DTCC DTCC has operating facilities and data centers around the world and, through its subsidiaries, automates, centralizes, and standardizes the post-trade processing of financial transactions for thousands of institutions worldwide. With 40 years of experience, DTCC is the premier post-trade market infrastructure for the global financial services industry, simplifying the complexities of clearance, settlement, asset servicing, global data management and information services for equities, corporate and municipal bonds, government and mortgage-backed securities, derivatives, money market instruments, syndicated loans, mutual funds, alternative investment products, and insurance transactions. In 2012, DTCC s subsidiaries processed securities transactions valued at approximately US$1.6 quadrillion. Its depository provides custody and asset servicing for securities issues from 131 countries and territories valued at US$37.2 trillion. DTCC s global trade repositories record more than US$500 trillion in gross notional value of transactions made worldwide.

3 INTRODUCTION The technical standards developed by the European Securities and Markets Authority (ESMA) were published in the Official Journal on 23 February 2013 and entered into force on 15 March They specify further the obligations under the European Market Infrastructure Regulation (EMIR) on OTC derivatives, central counterparties and trade repositories. EMIR aims to improve the functioning of OTC derivatives markets in the European Union (EU) by applying central clearing and risk mitigation techniques, increasing transparency via trade repositories and ensuring the sound and resilient operation of central counterparties (CCPs). For trade repositories, the regulatory technical standards (RTS) and the implementing technical standards (ITS) provide details of the reporting obligations, the content of the application for registration to ESMA and the information to be provided to relevant regulatory bodies to enable systemic risk analysis. KEY CONSIDERATIONS IN THE DEVELOPMENT OF ESMA STANDARDS & REQUIREMENTS ESMA makes reference to industry data standards in order to achieve consistency between the EU and its international counterparties, thereby ensuring EU-based trade repositories can operate globally. ESMA consulted various existing working groups to build on global harmonization of requirements: June 2010 ODRF guidance on access to trade repository held data on credit default swaps CPSS-IOSCO report on OTC derivatives data reporting and aggregation requirements CPSS-IOSCO task force on access to trade repository held data and principles for financial market infrastructures (FMI) ESMA adopted a criteria-based approach to developing the technical standards. Key points to address in developing the RTS regarding details to be reported to trade repositories included a determination of: 1. The purpose and content of reporting. 2. The elements needed to correctly identify contracts and the corresponding counterparties. 3. The level of granularity of information that is reported to trade repositories. Key points to address in developing the ITS regarding format and frequency included: 1. The required fields to be reported for each data. 2. Standard codes for the identification of counterparties, contracts, trades, currencies, products. 1 REPORTING TO ESMA The main purpose for reporting to ESMA is to provide transparency in the derivatives markets that facilitates identification and mitigation of systemic risk and in so doing, fulfills the G20 transparency commitment made at the 2009 Pittsburgh conference. ESMA will also be able to harmonize data requirements and create consistency across the post-trade reporting regimes in both EMIR and the Markets in Financial Instrument Directive/Regulation (MiFID/MiFIR) (transaction reporting). Trade repositories will be required to register as Approved Reporting Mechanisms (ARMs) in order to support MIFID/R reporting requirements.

4 ESMA REPORTING OBJECTIVES ESMA aims to increase transparency in the derivatives industry by: Ensuring firms specify the details of derivatives transactions that need to be reported to trade repositories. Defining the trade repository data to be made available to relevant authorities. Creating a set of information required to be provided to ESMA for the authorization and supervision of trade repositories. BENEFITS OF EMIR REPORTING UTILIZING THE GLOBAL TRADE REPOSITORY (GTR) 2 Benefits to regulatory bodies Provides regulators with direct access to both domestic and global data, e.g. material interest in an instrument traded by foreign parties outside of their jurisdiction. Timely access to comprehensive accurate data in a crisis (Lehman failure was the original driver behind trade repository developments). Avoids need for regulators to standardize and aggregate data from multiple sources. Enables more sophisticated central analytics for regulator use to be developed. Benefits to market participants Single point of connectivity, reconciliation and control significantly reduces participant cost burden of adhering to many different standards and requiring multiple interfaces. Leverages the service to achieve additional operational efficiencies, e.g. ability to integrate with over 30+ separate market infrastructure providers and serve as a hub which feeds and can accelerate the market adoption of other processes e.g. clearing and portfolio compression. Over time we expect DTCC s multi-asset GTR will further enhance this hub & spoke model and enable automation of other facets of OTC markets. Benefits to the public Significantly increases public confidence in markets knowing the regulators have access to relevant data. Centralizes data, for example net open interest can only be calculated accurately with a complete data set. Data fragmentation can also lead to systematic overstatement, which itself could cause panic responses such as unnecessary sell-offs. WHAT TO REPORT FOR EMIR EMIR requires the reporting of all derivatives trades, both exchange-traded and OTC. Exchange-traded derivatives ESMA requires listed products to be reported to trade repositories. As a result, ESMA is reviewing various stakeholders input with regards to mandatory reporting of exchange-traded derivatives. Further information on this requirement will be made available in due course.

5 OTC derivatives ESMA requires a minimum set of information to be provided. DTCC s GTR will support the reporting of all OTC derivatives trades as required under EMIR. The data table related to OTC derivatives which is found in the annex of the technical standards and is also included in the annex of this document, is divided into two sections: Section 1: Counterparty data both counterparties and appointed reporting entities have to provide this information. Section 2: Common data - one counterparty can report this set of information on behalf of themselves and of the other counterparty. Reports submitted on behalf of both parties should be indicated as such and submitted only once. ESMA provides specifications for the format of reporting and application of codes to be used by all reporting entities, whether counterparty to the trade or delegated reporting entity: ESMA believes that entities, products and contracts should be accurately and unambiguously represented when reporting to trade repositories. This process will ensure standardization, a more efficient and effective analysis of data and cost effectiveness in reporting to trade repositories. Universal codes should be used to identify trades. In the event that trades have been submitted to different repositories, this will facilitate reconciliation between repositories. Unique Trade Identifiers (UTI) Unique global trade IDs are required in order to ensure accurate identification of reported trades. This will improve the ability to reconcile trades both with and between counterparties, CCPs and trade repositories, and reduce the likelihood of duplicate reporting. ESMA has placed the responsibility of creating UTIs on the counterparties to the contract. However, it is possible to delegate the generation of the UTI. 3 Legal Entity Identifiers (LEI) Identification of counterparties, CCPs, beneficiaries and brokers will be achieved by using a global legal entity identifier. An interim LEI meeting the conditions indicated by the LEI Regulatory Oversight Committee (ROC) is expected to be used for reporting purposes under EMIR. DTCC and SWIFT have developed a global solution (the CICI utility ) to the identification of legal entities. The first implementation of this global solution has been to facilitate compliance with the CFTC reporting rules. The CICI utility functions as a pre-local operating unit (LOU) and plans to become one LOU within the global LEI system. The Regulatory Oversight Committee (ROC) and Financial Stability Board (FSB) have been tasked with ensuring a robust framework for mutual acceptance where LEIs created by approved LOUs can be accepted by other jurisdictions. Recently the CFTC made a statement accepting other pre-leis under certain conditions. Universal/Unique Product Identifiers (UPI) There has been an industry request for adoption of the ISDA UPI taxonomy; however, concerns were raised that it may not capture exotic/bespoke/hybrid products. In the event that a globally agreed product identifier is not available, a number of alternatives have been identified: International Securities Identification number - ISIN Alternative Instruments identifier - AII Classification of Financial Instruments code - CFI

6 Hybrid trades may also be reported, on the basis that both counterparties agree to use the asset class the hybrid closely resembles. Valuation ESMA has a strong desire to ensure that data fields meaningfully show the exposures of counterparties to other counterparties. Data reported to repositories should include fields that provide an indication of the exposure between counterparties and allow regulators to see a comprehensive picture of the positions of firms with each other, including collateral exchanged. Based on this, daily valuation is required in order to obtain the mark-to-market valuation of the outstanding contracts. Mark-to-market or mark-to-model valuation will assist in ensuring a more accurate quantification of the counterparties exposure. CCPS are required to provide valuation data on cleared OTC contracts. 4 Collateral ESMA requires collateral information to complement the information on exposures. Counterparties can report collateral exchanged for an individual contract to trade repositories and may report collateral exchanged on a portfolio basis (using a unique code applicable to the portfolio), if individual contract information is unavailable. Portfolio information should include collateral value and currency. Counterparties and CCPs have been given 6 months after the reporting start date of respective asset classes to implement reporting mechanisms to capture both daily valuation and collateral information. Modifications and terminations of contracts are also required to be reported under EMIR. Both counterparties must report, although firms will be able to do so on behalf of their clients. ESMA is favorable to centralized reporting. WHO REPORTS The reporting obligation is placed on both counterparties - financial and non-financial - to a derivatives contract (including CCPs) without prejudice to the fact that counterparties may delegate reporting to one of the two counterparties. Individuals however, are not subject to the reporting obligation under EMIR; the other counterparty (in case it is not another individual) will have the obligation to report the trade to a trade repository. ESMA also allows the use of third party providers (TPP) e.g., agents/middleware providers, inside or outside the EU, for reporting purposes. TPPs are subject to ESMA laws and must guarantee protection of data sent to trade repositories. The European regulators are not prescriptive towards choosing appropriate TPPs, but can intervene in the event of non-performance/non-compliance by TPPs. Clarity is being sought by respondents on which TPPs would be permitted. The GTR provides open access to TPPs to promote efficient reporting processes. This includes: Electronic Execution Platforms Clearing Houses (CCPs) and Derivatives Clearing Organizations (DCOs) Confirmation providers Intermediaries (e.g. interdealer brokers) Custodians and asset servicers Any other middleware providers

7 WHEN TO REPORT Under EMIR, OTC and exchange-traded derivatives transactions entered into by EU counterparties are to be reported by end of day on T+1 to a trade repository that is either registered with ESMA or recognized by ESMA if outside the EU. Compliance/ Reporting Start Date Based on the latest EMIR timeline that ESMA has published on the esma.europa.eu web page, the possible compliance dates (to be confirmed) are as per below: January 2014 Credit, interest rate, equity, FX and commodity derivatives contracts. July 2014 Collateral & daily valuation on credit, interest rate, equity, FX and commodity derivatives contracts. The reporting start date, which will be the same for all counterparties, is based upon two criteria: Reporting is to start 90 days following the authorization of a trade repository for the relevant asset classes to ensure avoidance of direct reporting and afford the trade repositories and counterparties adequate time to implement their reporting mechanisms. Firms will be required to report directly to ESMA on 1 July 2015 in the event that trade repositories are not registered for the relevant asset classes by then this is to give the industry legal certainty that reporting will start. Participants have 90 calendar days to report derivatives contracts that are outstanding on 16 August 2012, and are still outstanding on the reporting start date of the respective asset classes. Participants have 3 years to report derivatives contracts that were outstanding on 16 August 2012 or were entered into on or after 16 August 2012 and are not outstanding on or after the reporting start date of the respective asset classes. 5 HOW TO REPORT As well as direct connectivity to multiple TPPs such as MarkitWire or Traiana, DTCC will provide users with the flexibility to connect to the GTR using a variety of interfaces. Firms that have an existing connection to DTCC via DTCC s proprietary Securely Managed and Reliable Technology (SMART) Network, BT Radianz or SWIFT will be able to leverage their connection to submit records into the GTR. In addition to providing a direct MQ link, DTCC will make the following available to users: Secure File Transfer (SFTP) where firms can submit a large volume of trade data into the GTR. A Web Graphical User Interface to firms that wish to Login and Upload their trade data directly into the GTR. Web Services functionality to firms interested in submitting data to the GTR in an MQ Transaction -like format utilizing a secure internet connection. SWIFT Channel, using CSV file (SWIFT File Act).

8 WHO DO WE CONTACT WITH QUESTIONS ABOUT THE REPOSITORY? Europe and Middle East Asia-Pacific Japan Singapore Canada, North, Central and South America GTR-Americas@dtcc.com Onboarding Hotlines: North America , Option 3, 2, and 1. Europe and Asia , Option 2 and 2. 6 GTR_onboarding@dtcc.com ESMA has published answers to FAQs on 20 March 2013 and 6 June 2013 on the esma.europa.eu web page.

9 Appendix: Table of fields to be reported under ESMA SECTION 1 COUNTERPARTY DATA FIELD DETAILS TO BE REPORTED FORMAT Parties to the contract 1. Reporting timestamp Date and time of reporting to the trade repository 2. Counterparty ID Unique code identifying the reporting counterparty. In case of an individual, a client code shall be used. 3. ID of the other counterparty 4. Name of the counterparty 5. Domicile of the counterparty 6. Corporate sector of the counterparty Unique code identifying the other counterparty of the contract. This field shall be filled from the perspective of the reporting counterparty. In case of an individual, a client code shall be used. Corporate name of the reporting counterparty. This field can be left blank in case the counterparty ID already contains this information. Information on the registered office, consisting of full address, city and country of the reporting counterparty. This field can be left blank in case the counterparty ID already contains this information. ISO 8601 date format / UTC time format. Legal Entity Identifier (LEI) (20 alphanumerical digits), interim entity identifier (20 alphanumerical digits), BIC (11 alphanumerical digits) or a client code (50 alphanumerical digits). Legal Entity Identifier (LEI) (20 alphanumerical digits), interim entity identifier (20 alphanumerical digits), BIC (11 alphanumerical digits) or a client code (50 alphanumerical digits). 100 alphanumerical digits or blank in case of coverage by Legal Entity Identifier (LEI). 500 alphanumerical digits or blank in case of coverage by Legal Entity Identifier (LEI). Taxonomy: A=Assurance undertaking authorised in accordance with Directive 2002/83/EC; C=Credit institution authorised in accordance with Directive 2006/48/EC; F=Investment firm in accordance with Directive 2004/39/EC; I=Insurance undertaking authorised in accordance with Directive 73/239/ EEC; L=Alternative investment fund managed by AIFMs authorised or registered in accordance with Directive 2011/61/EU; O=Institution for occupational retirement provision within the meaning of Article 6(a) of Directive 2003/41/EC; R=Reinsurance undertaking authorised in accordance with Directive 2005/68/EC; U=UCITS and its management company, authorised in accordance with Directive 2009/65/EC; or blank in case of coverage by Legal Entity Identifier (LEI) or in case of non-financial counterparties Financial or non-financial nature of the counterparty Indicate if the reporting counterparty is a financial or non-financial counterparty in accordance with Article 2(8,9)of Regulation (EU) No 648/ Broker ID In case a broker acts as intermediary for the reporting counterparty without becoming a counterparty, the reporting counterparty shall identify this broker by a unique code. In case of an individual, a client code shall be used. F=Financial Counterparty, N=Non-Financial Counterparty. Legal Entity Identifier (LEI) (20 alphanumerical digits), interim entity identifier (20 alphanumerical digits), BIC (11 alphanumerical digits) or a client code (50 alphanumerical digits). 9. Reporting entity ID 10. Clearing member ID In case the reporting counterparty has delegated the submission of the report to a third party or to the other counterparty, this entity has to be identified in this field by a unique code. Otherwise this field shall be left blank. In case of an individual, a client code shall be used, as assigned by the legal entity used by the individual counterparty to execute the trade. In case the reporting counterparty is not a clearing member, its clearing member shall be identified in this field by a unique code. In case of an individual, a client code, as assigned by the CCP, shall be used. Legal Entity Identifier (LEI) (20 alphanumerical digits), interim entity identifier (20 alphanumerical digits),bic (11 alphanumerical digits) or a client code (50 alphanumerical digits). Legal Entity Identifier (LEI) (20 alphanumerical digits), interim entity identifier (20 alphanumerical digits), BIC (11 alphanumerical digits) or a client code (50 alphanumerical digits).

10 Appendix: Table of fields to be reported under ESMA Beneficiary ID The party subject to the rights and obligations arising from the contract. Where the transaction is executed via a structure, such as a trust or fund, representing a number of beneficiaries, the beneficiary should be identified as that structure. If the beneficiary of the contract is not a counterparty to this contract, the reporting counterparty has to identify this beneficiary by a unique code or, in case of individuals, by a client code as assigned by the legal entity used by the individual. 12. Trading capacity 13. Counterparty side 14. Contract with non-eea counterparty 15. Directly linked to commercial activity or treasury financing 16. Clearing threshold 17. Mark to market value of contract 18. Currency of mark to market value of the contract Identifies whether the reporting counterparty has concluded the contract as principal on own account (on own behalf or behalf of a client) or as agent for the account of and on behalf of a client. Identifies whether the contract was a buy or a sell. In the case of an interest rate derivative contract, the buy side will represent the payer of leg 1 and the sell side will be the payer of leg 2. Indicates whether the other counterparty is domiciled outside the EEA. Information on whether the contract is objectively measurable as directly linked to the reporting counterparty s commercial or treasury financing activity, as referred to in Art. 10(3) of Regulation (EU) No 648/2012. This field shall be left blank in case the reporting counterparty is a financial counterparty, as referred to in Art. 2 (8) Regulation (EU) No 648/2012. Information on whether the reporting counterparty is above the clearing threshold as referred to in Art. 10(3) of Regulation (EU) No 648/2012. This field shall be left blank in case the reporting counterparty is a financial counterparty, as referred to in Art. 2 (8) Regulation (EU) No 648/2012. Mark to market valuation of the contract, or mark to model valuation where applicable under Article 11(2) of Regulation (EC) No 648/2012. The currency used for the mark to market valuation of the contract, or mark to model valuation where applicable under Article 11(2) of Regulation (EC) No 648/ Valuation date Date of the last mark to market or mark to model valuation. 20. Valuation time Time of the last mark to market or mark to model valuation. 21. Valuation type Time of the last mark to market or mark to model valuation. 22. Collateralisation Whether collateralisation was performed. Legal Entity Identifier (LEI) (20 alphanumerical digits), interim entity identifier (20 alphanumerical digits), BIC (11 alphanumerical digits) or a client code (50 alphanumerical digits). P=Principal, A=Agent. B=Buyer, S=Seller. Y=Yes, N=No. Y=Yes, N=No. Y=Above, N=Below. Up to 20 numerical digits in the format xxxx,yyyyy. ISO 4217 Currency Code, 3 alphabetical digits. ISO 8601 date format. UTC time format. M=mark to market / O=mark to model. U=uncollateralised, PC= partially collateralised, OC=one way collateralised or FC- fully collateralised.

11 Appendix: Table of fields to be reported under ESMA 23. Collateral portfolio 24. Collateral portfolio code 25. Value of the collateral 26. Currency of the collateral value Whether the collateralisation was performed on a portfolio basis. Portfolio means the collateral calculated on the basis of net positions resulting from a set of contracts, rather than per trade If collateral is reported on a portfolio basis, the portfolio should be identified by a unique code determined by the reporting counterparty. Value of the collateral posted by the reporting counterparty to the other counterparty. Where collateral is posted on a portfolio basis, this field should include the value of all collateral posted for the portfolio. Specify the value of the collateral for field 25. Y=Yes, N=No. Up to 10 numerical digits. Specify the value the total amount of collateral posted; up to 20 numerical digits in the format xxxx,yyyyy. Specify the currency of field 25; ISO 4217 Currency Code, 3 alphabetical digits. SECTION 2 - COMMON DATA FIELD DETAILS TO BE REPORTED APPLICABLE TYPES OF DERIVATIVE CONTRACT Section 2a - Contract type 1. Taxonomy used The contract shall be identified by using a product identifier. 2. Product ID 1 The contract shall be identified by using a product identifier. 3. Product ID 2 The contract shall be identified by using a product identifier. 4. Underlying The underlying shall be identified by using a unique identifier for this underlying. In case of baskets or indices, an indication for this basket or index shall be used where a unique identifier does not exist. 5. Notional currency 1 6. Notional currency 2 7. Deliverable currency Section 2b - Details on the transaction The currency of the notional amount. In the case of an interest rate derivative contract, this will be the notional currency of leg 1. The currency of the notional amount. In the case of an interest rate derivative contract, this will be the notional currency of leg 2. The currency to be delivered. 8. Trade ID A Unique Trade ID agreed at the European level, which is provided by the reporting counterparty. If there is no unique trade ID in place, a unique code should be generated and agreed with the other counterparty. All contracts All contracts Identify the taxonomy used: U=Product Identifier [endorsed in Europe] I=ISIN/AII + CFI E=Interim taxonomy For taxonomy = U: Product Identifier (UPI), to be defined For taxonomy = I: ISIN or AII, 12 digits alphanumerical code For taxonomy = E: Derivative class: CO=Commodity CR=Credit CU=Currency EQ=Equity IR=Interest Rate OT= Other For taxonomy = U: Blank For taxonomy = I: CFI, 6 characters alphabetical code For taxonomy = E: Derivative type: CD= Contracts for difference FR= Forward rate agreements FU= Futures FW=Forwards OP=Option SW=Swap OT= Other ISIN (12 alphanumerical digits); LEI (20 alphanumerical digits); Interim entity identifier (20 alphanumerical digits); UPI (to be defined); B= Basket; I=Index. ISO 4217 Currency Code, 3 alphabetical digits. ISO 4217 Currency Code, 3 alphabetical digits. ISO 4217 Currency Code, 3 alphabetical digits. Up to 52 alphanumerical digits. 9

12 Appendix: Table of fields to be reported under ESMA 9. Transaction reference number 10. Venue of execution A unique identification number for the transaction provided by the reporting entity or a third party reporting on its behalf. The venue of execution shall be identified by a unique code for this venue. In case of a contract concluded OTC, it has to be identified whether the respective instrument is admitted to trading but traded OTC or not admitted to trading and traded OTC. 11. Compression Identify whether the contract results from a compression exercise. 12. Price / rate The price per derivative excluding, where applicable, commission and accrued interest. An alphanumeric field up to 40 characters ISO Market Identifier Code (MIC), 4 digits alphabetical. Where relevant, XOFF for listed derivatives that are traded off-exchange or XXXX for OTC derivatives. Y = if the contract results from compression; N= if the contract does not result from compression. Up to 20 numerical digits in the format xxxx,yyyyy. 13. Price notation The manner in which the price is expressed. VE.g. ISO 4217 Currency Code, 3 alphabetical digits, percentage. 14. Notional amount Original value of the contract. 15. Price multiplier The number of units of the financial instrument which are contained in a trading lot; for example, the number of derivatives represented by one contract. Up to 20 numerical digits in the format xxxx,yyyyy. Up to 10 numerical digits Quantity Number of contracts included in the report, where more than one derivative contract is reported. 17. Up-front payment Amount of any up-front payment the reporting counterparty made or received. 18. Delivery type Indicates whether the contract is settled physically or in cash. 19. Execution timestamp As defined in Article 1 (2). 20. Effective date Date when obligations under the contract come into effect. 21. Maturity date Original date of expiry of the reported contract. An early termination shall not be reported in this field. 22. Termination date 23. Date of Settlement 24. Master Agreement type 25. Master Agreement version Termination date of the reported contract. If not different from maturity date, this field shall be left blank. Date of settlement of the underlying. If more than one, further fields may be used (e.g. 23A, 123B, 23C ). Reference to the name of the relevant master agreement, if used for the reported contract (e.g. ISDA Master Agreement; Master Power Purchase and Sale Agreement; International ForEx Master Agreement; European Master Agreement or any local Master Agreements). Reference to the year of the master agreement version used for the reported trade, if applicable (e.g. 1992, 2002,...). Up to 10 numerical digits. Up to 10 numerical digits in the format xxxx,yyyyy for payments made by the reporting counterparty and in the format xxxx,yyyyy for payments received by the reporting counterparty. C=Cash, P=Physical, O=Optional for counterparty. ISO 8601 date format / UTC time format. ISO 8601 date format. ISO 8601 date format. ISO 8601 date format. ISO 8601 date format. Free Text, field of up to 50 characters, identifying the name of the Master Agreement used, if any. Year, xxxx.

13 Appendix: Table of fields to be reported under ESMA Section 2c - Risk mitigation / Reporting 26. Confirmation timestamp 27. Confirmation means Section 2d Clearing 28. Clearing obligation Date and time of the confirmation, as defined under Regulation (EC) the xx/2012 [Commission delegated regulation endorsing draft regulatory technical standards on OTC Derivatives] indicating time zone in which the confirmation has taken place. Whether the contract was electronically confirmed, non-electronically confirmed or remains unconfirmed. Indicates, whether the reported contract is subject to the clearing obligation under Regulation (EU) No 648/ Cleared Indicates, whether clearing has taken place. 30. Clearing timestamp Time and date when clearing took place. 31. CCP In case of a contract that has been cleared, the unique code for the CCP that has cleared the contract. All contracts All contracts ISO 8601 date format, UTC time format. Y=Non-electronically confirmed, N=Non-confirmed, E=Electronically confirmed. Y=Yes, N=No. Y=Yes, N=No. ISO 8601 date format / UTC time format. Legal Entity Identifier (LEI) (20 alphanumerical digits) or, if not available, interim entity identifier (20 alphanumerical digits) or, if not available, BIC (11 alphanumerical digits) Intragroup Indicates whether the contract was entered into as an intra-group transaction, defined in Article 3 of Regulation (EU) No 648/2012. Y=Yes, N=No. Section 2e Interest Rates 33. Fixed rate of leg Fixed rate of leg Fixed rate day count 36. Fixed leg payment frequency 37. Floating rate payment frequency 38. Floating rate reset frequency 39. Floating rate of leg Floating rate of leg 2 If a UPI is reported and contains all the information below, this is not required to be reported. An indication of the fixed rate leg 1 used, if applicable. An indication of the fixed rate leg 2 used, if applicable. The actual number of days in the relevant fixed rate payer calculation period, if applicable. Frequency of payments for the fixed rate leg, if applicable. Frequency of payments for the floating rate leg, if applicable. Frequency of floating rate leg resets, if applicable. An indication of the interest rates used which are reset at predetermined intervals by reference to a market reference rate, if applicable. An indication of the interest rates used which are reset at predetermined intervals by reference to a market reference rate, if 159 applicable. Interest rate derivatives Numerical digits in the format xxxx,yyyyy. Numerical digits in the format xxxx,yyyyy. Actual/365, 30B/360 or Other. An integer multiplier of a time period describing how often the counterparties exchange payments, e.g. 10D, 3M, 5Y. An integer multiplier of a time period describing how often the counterparties exchange payments, e.g. 10D, 3M, 5Y. An integer multiplier of a time period describing how often the counterparties exchange payments, e.g. 10D, 3M, 5Y. The name of the floating rate index, e.g. 3M Euribor. The name of the floating rate index, e.g. 3M Euribor.

14 Appendix: Table of fields to be reported under ESMA Section 2f Foreign Exchange If a UPI is reported and contains all the information below, this is not required to be reported. Currency derivatives 41. Currency 2 The cross currency, if different from the currency of delivery. ISO 4217 Currency Code, 3 alphabetical digits. 42. Exchange rate 1 The contractual rate of exchange of the currencies. Up to 10 numerical digits in the format xxxx,yyyyy. 43. Forward exchange rate Forward exchange rate on value date. Up to 10 numerical digits in the format 192 xxxx,yyyyy. 44. Exchange rate basis Quote base for exchange rate. E.g. EUR/USD or USD/EUR. Section 2g - Commodities If a UPI is reported and contains all the information below, this is not required to be reported unless to be reported according to Regulation (EU) No 1227/2011. Commodity derivatives General Commodity base Indicates the type of commodity underlying the contract. AG=Agricultural EN=Energy FR=Freights ME=Metals IN= Index EV= Environmental EX= Exotic 46. Commodity details Details of the particular commodity beyond field 45. Agricultural GO= Grains oilseeds DA= Dairy LI= Livestock FO= Forestry SO= Softs Energy OI= Oil NG = Natural gas CO= Coal EL= Electricity IE= Inter-energy Metals PR= Precious NP = Non-precious Environmental WE=Weather EM= Emissions Energy Information to be reported according to Regulation (EU) No 1227/2011, if applicable. 47. Delivery point or zone Delivery points(s) of market area(s). EIC code, 16 character alphanumeric code. 48. Interconnection Point Identification of the border(s) or border point(s) of a transportation contract. Free text, field of up to 50 characters. 49. Load type Repeatable section of fields to identify the product delivery profile which correspond to the delivery periods of a day. Repeatable section of fields to identify the product delivery profile; BL=Base Load PL=Peak Load OP=Off-Peak BH= Block Hours OT=Other 50. Delivery start date and time Start date and time of delivery. ISO 8601 date format.

15 Appendix: Table of fields to be reported under ESMA 51. Delivery end date and time 52. Contract capacity End date and time of delivery. Quantity per delivery time interval. 53. Quantity Unit Daily or hourly quantity in MWh or kwh/d which corresponds to the underlying commodity. 54. Price/time interval quantities Section 2h - Options If applicable, price per time interval quantities. If a UPI is reported and contains all the information below, this is not required to be reported. 55. Option type Indicates whether the contract is a call or a put. 56. Option style (exercise) 57. Strike price (cap/floor rate) Section 2i - Modifications to the report Indicates whether the option may be exercised only at a fixed date (European, and Asian style), a series of pre-specified dates (Bermudan) or at any time during the life of the contract (American style). The strike price of the option. 58. Action type Whether the report contains: a derivative contract or post-trade event for the first time, in which case it will be identified as new ; a modification of details of a previously reported derivative contract, in which case it will be identified as modify ; a cancellation of a wrongly submitted report, in which case, it will be identified as error ; a termination of an existing contract, in which case it will be identified as cancel ; a compression of the reported contract, in which case it will be identified as compression ; an update of a contract valuation, in which case it will be identified as valuation update ; any other amendment to the report, in which case it will be identified as other. 59. Details of action type Where field 58 is reported as other the details of such amendment should be specified here. Contracts that contain an option All contracts ISO 8601 date format. Free text, field of up to 50 characters. 10 numerical digits in the format xxxx,yyyyy. 10 numerical digits in the format xxxx,yyyyy. P=Put, C=Call. A=American, B=Bermudan, E=European, S=Asian. Up to 10 Numerical digits in the format xxxx,yyyyy. N=New M=Modify E=Error, C=Cancel, Z=Compression, V=Valuation update, O=Other. Free text, field of up to 50 characters. 13

16 This description is for informational purposes only. This Service is governed by applicable Rules, Procedures, and Services Guide for each DTCC subsidiary, which contain the full terms, conditions, and limitations applicable to this Service. We may provide you with additional information about our products and services from time to time. If at any time you wish to be removed from our distribution list, please send an to To learn about career opportunities at DTCC, please go to dtcc.com/careers. July P 4783 JUNE 20123