Improving the Functioning of the Otc Derivatives Markets in the European

Home , ISO 4217, Open interest

IMPROVING THE FUNCTIONING OF THE OTC DERIVATIVES MARKETS IN THE EUROPEAN UNION SUMMARY OF TECHNICAL STANDARDS FOR THE REGULATION ON OTC DERIVATIVES & TRADE REPOSITORIES About DTCC With over 40 years of experience, DTCC is the premier post-trade market infrastructure for the global financial services industry. From operating facilities, data centers and offices in 16 countries, DTCC, through its subsidiaries, automates, centralizes, and standardizes the post-trade processing of financial transactions, mitigating risk, increasing transparency and driving efficiency for thousands of broker/dealers, custodian banks and asset managers worldwide. User owned and industry governed, the firm simplifies the complexities of clearing, settlement, asset servicing, data management and information services across asset classes, bringing increased security and soundness to the financial markets. In 2014, DTCC’s subsidiaries processed securities transactions valued at approximately US$1.6 quadrillion. Its depository provides custody and asset servicing for securities issues from over 130 countries and territories valued at US$64 trillion. DTCC’s global trade repository maintains approximately 40 million open OTC positions and processes roughly 280 million messages a week. To learn more, please visit www.dtcc.com or follow us on Twitter @The_DTCC. 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 2013. 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 OFESMA 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 1 • 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 infra- structures (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.

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. 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)

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. 2 • 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 stake- holders’ input with regards to mandatory reporting of exchange-traded derivatives. Further information on this requirement will be made available in due course. 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) 3 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.

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 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.

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. 4 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-perfor- mance/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 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. 5 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.

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). WHO DO WE CONTACT WITH QUESTIONS ABOUT THE REPOSITORY?

Europe and Middle East [email protected]. +44 207 650 1545

Asia-Pacific [email protected] Japan +81 3 6721 8876 Singapore +65 6407 1224

Canada, North, Central and South America [email protected] +1 212 855 2430

Onboarding

Hotlines: North America +1 888 382 2721, Option 3, 2, and 1. Europe and Asia +44 207 136 6328, Option 2 and 2. [email protected] 6 ESMA has published answers to FAQs on 20 March 2013 and 6 June 2013 on the esma.europa.eu web page. 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 Date and time of reporting to the trade ISO 8601 date format / UTC time format. timestamp repository 2. Counterparty ID “Unique code identifying the reporting “Legal Entity Identifier (LEI) (20 alphanumerical digits), interim entity identi- counterparty. In case of an individual, a fier (20 alphanumerical digits), BIC (11 alphanumerical digits) or a client client code shall be used.” code (50 alphanumerical digits).” 3. ID of the other “Unique code identifying the other coun- “Legal Entity Identifier (LEI) (20 alphanumerical digits), interim entity identi- counterparty terparty of the contract. This field shall be fier (20 alphanumerical digits), BIC (11 alphanumerical digits) or a client filled from the perspective of the reporting code (50 alphanumerical digits).” counterparty. In case of an individual, a client code shall be used.” 4. Name of the Corporate name of the reporting counter- 100 alphanumerical digits or blank in case of coverage by Legal Entity Identi- counterparty party. This field can be left blank in case fier (LEI). the counterparty ID already contains this information. 5. Domicile of the “Information on the registered office, 500 alphanumerical digits or blank in case of coverage by Legal Entity Identi- counterparty consisting of full address, city and country fier (LEI). of the reporting counterparty. This field can be left blank in case the counterparty ID already contains this information.” 7 6. Corporate “Taxonomy: A=Assurance undertaking authorised in accordance with Direc- sector of the tive 2002/83/EC; C=Credit institution authorised in accordance with Directive counterparty 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 oc- cupational 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.”

7. Financial or “Indicate if the reporting counterparty is a “F=Financial Counterparty, N=Non-Financial Counterparty.” non-financial financial or non-financial counterparty in nature of the accordance with Article 2(8,9)of Regulation counterparty (EU) No 648/2012.” 8. Broker ID “In case a broker acts as intermediary for “Legal Entity Identifier (LEI) (20 alphanumerical digits), interim entity identi- the reporting counterparty without becoming fier (20 alphanumerical digits), BIC (11 alphanumerical digits) or a client a counterparty, the reporting counterparty code (50 alphanumerical digits).” shall identify this broker by a unique code. In case of an individual, a client code shall be used.”

9. Reporting “In case the reporting counterparty has “Legal Entity Identifier (LEI) (20 alphanumerical digits), interim entity identi- entity ID delegated the submission of the report to a fier (20 alphanumerical digits),BIC (11 alphanumerical digits) or a client third party or to the other counterparty, this code (50 alphanumerical digits).” 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.” 10. Clearing “In case the reporting counterparty is not a “Legal Entity Identifier (LEI) (20 alphanumerical digits), interim entity identi- member ID clearing member, its clearing member shall fier (20 alphanumerical digits), BIC (11 alphanumerical digits) or a client be identified in this field by a unique code. code (50 alphanumerical digits).” In case of an individual, a client code, as assigned by the CCP, shall be used.” Appendix: Table of fields to be reported under ESMA

11. Beneficiary ID “The party subject to the rights and obliga- “Legal Entity Identifier (LEI) (20 alphanumerical digits), interim entity identi- tions arising from the contract. Where the fier (20 alphanumerical digits), BIC (11 alphanumerical digits) or a client transaction is executed via a structure, such code (50 alphanumerical digits).” 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 Identifies whether the reporting counterparty “P=Principal, A=Agent.” capacity 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. 13. Counterparty “Identifies whether the contract was a buy “B=Buyer, S=Seller.” side 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.” 14. Contract Indicates whether the other counterparty is “Y=Yes, N=No.” with non-EEA domiciled outside the EEA. 8 counterparty 15. Directly linked “Information on whether the contract is “Y=Yes, N=No.” to commercial objectively measurable as directly linked to activity or the reporting counterparty’s commercial or treasury treasury financing activity, as referred to in financing 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.” 16. Clearing “Information on whether the reporting “Y=Above, N=Below.” threshold 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.” 17. Mark to “Mark to market valuation of the contract, “Up to 20 numerical digits in the format xxxx,yyyyy.” market value or mark to model valuation where applicable of contract under Article 11(2) of Regulation (EC) No 648/2012.” 18. Currency of “The currency used for the mark to market “ISO 4217 Currency Code, 3 alphabetical digits.” mark to market valuation of the contract, or mark to model value of the valuation where applicable under Article contract 11(2) of Regulation (EC) No 648/2012.” 19. Valuation date Date of the last mark to market or mark to ISO 8601 date format. model valuation. 20. Valuation time Time of the last mark to market or mark to UTC time format. model valuation. 21. Valuation type Time of the last mark to market or mark to M=mark to market / O=mark to model. model valuation. 22. Collateralisa- Whether collateralisation was performed. “U=uncollateralised, PC= partially collateralised, OC=one way collateralised tion or FC- fully collateralised.” Appendix: Table of fields to be reported under ESMA

23. Collateral “Whether the collateralisation was per- “Y=Yes, N=No.” portfolio formed 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” 24. Collateral “If collateral is reported on a portfolio Up to 10 numerical digits. portfolio code basis, the portfolio should be identified by a unique code determined by the reporting counterparty.” 25. Value of the “Value of the collateral posted by the report- “Specify the value the total amount of collateral posted; up to 20 numerical collateral ing counterparty to the other counterparty. digits in the format xxxx,yyyyy.” Where collateral is posted on a portfolio basis, this field should include the value of all collateral posted for the portfolio.” 26. Currency of the Specify the value of the collateral for field “Specify the currency of field 25; ISO 4217 Currency Code, 3 alphabetical collateral value 25. digits.”

SECTION 2 - COMMON DATA

FIELD DETAILS TO BE REPORTED APPLICABLE TYPES OF DERIVATIVE CONTRACT Section 2a - All contracts 9 Contract type 1. Taxonomy used The contract shall be identified by using a “Identify the taxonomy used: product identifier. U=Product Identifier [endorsed in Europe] I=ISIN/AII + CFI E=Interim taxonomy” 2. Product ID 1 The contract shall be identified by using a “For taxonomy = U: Product Identifier (UPI), to be defined For taxonomy = I: product identifier. 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” 3. Product ID 2 The contract shall be identified by using a “For taxonomy = U: Blank For taxonomy = I: CFI, 6 characters alphabetical product identifier. code For taxonomy = E: Derivative type: CD= Contracts for difference FR= Forward rate agreements FU= Futures FW=Forwards OP=Option SW=Swap OT= Other” 4. Underlying “The underlying shall be identified by using ISIN (12 alphanumerical digits); LEI (20 alphanumerical digits); Interim entity a unique identifier for this underlying. In identifier (20 alphanumerical digits); UPI (to be defined); B= Basket; I=Index. case of baskets or indices, an indication for this basket or index shall be used where a unique identifier does not exist.” 5. Notional cur- “The currency of the notional amount. In the “ISO 4217 Currency Code, 3 alphabetical digits.” rency 1 case of an interest rate derivative contract, this will be the notional currency of leg 1.” 6. Notional cur- “The currency of the notional amount. In the “ISO 4217 Currency Code, 3 alphabetical digits.” rency 2 case of an interest rate derivative contract, this will be the notional currency of leg 2.” 7. Deliverable The currency to be delivered. “ISO 4217 Currency Code, 3 alphabetical digits.” currency Section 2b - All contracts Details on the transaction 8. Trade ID “A Unique Trade ID agreed at the European Up to 52 alphanumerical digits. 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.” Appendix: Table of fields to be reported under ESMA

9. Transaction A unique identification number for the An alphanumeric field up to 40 characters reference transaction provided by the reporting entity number or a third party reporting on its behalf. 10. Venue of “The venue of execution shall be identified “ISO 10383 Market Identifier Code (MIC), 4 digits alphabetical. execution by a unique code for this venue. In case Where relevant, XOFF for listed derivatives that are traded off-exchange or of a contract concluded OTC, it has to be XXXX for OTC derivatives.” 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 Y = if the contract results from compression; N= if the contract does not compression exercise. result from compression. 12. Price / rate “The price per derivative excluding, where “Up to 20 numerical digits in the format xxxx,yyyyy.” applicable, commission and accrued interest.” 13. Price notation The manner in which the price is expressed. “VE.g. ISO 4217 Currency Code, 3 alphabetical digits, percentage.” 14. Notional Original value of the contract. “Up to 20 numerical digits in the format xxxx,yyyyy.” amount 15. Price multiplier “The number of units of the financial Up to 10 numerical digits. instrument which are contained in a trading lot; for example, the number of derivatives represented by one contract.”

10 16. Quantity “Number of contracts included in the report, Up to 10 numerical digits. where more than one derivative contract is reported.”

17. Up-front Amount of any up-front payment the report- “Up to 10 numerical digits in the format xxxx,yyyyy for payments made by the payment ing counterparty made or received. reporting counterparty and in the format xxxx,yyyyy for payments received by the reporting counterparty.” 18. Delivery type Indicates whether the contract is settled “C=Cash, P=Physical, O=Optional for counterparty.” physically or in cash. 19. Execution As defined in Article 1 (2). ISO 8601 date format / UTC time format. timestamp 20. Effective date Date when obligations under the contract ISO 8601 date format. come into effect. 21. Maturity date Original date of expiry of the reported ISO 8601 date format. contract. An early termination shall not be reported in this field. 22. Termination “Termination date of the reported contract. ISO 8601 date format. date If not different from maturity date, this field shall be left blank.” 23. Date of “Date of settlement of the underlying. If ISO 8601 date format. Settlement more than one, further fields may be used (e.g. 23A, 123B, 23C…).” 24. Master Agree- “Reference to the name of the relevant “Free Text, field of up to 50 characters, identifying the name of the Master ment type master agreement, if used for the reported Agreement used, if any.” contract (e.g. ISDA Master Agreement; Master Power Purchase and Sale Agreement; International ForEx Master Agreement; European Master Agreement or any local Master Agreements).” 25. Master Agree- “Reference to the year of the master agree- “Year, xxxx.” ment version ment version used for the reported trade, if applicable (e.g. 1992, 2002, ...).” Appendix: Table of fields to be reported under ESMA

Section 2c - All contracts Risk mitigation / Reporting 26. Confirmation “Date and time of the confirmation, as “ISO 8601 date format, UTC time format.” timestamp 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.” 27. Confirmation “Whether the contract was electronically “Y=Non-electronically confirmed, N=Non-confirmed, E=Electronically means confirmed, non-electronically confirmed or confirmed.” remains unconfirmed.” Section 2d – All contracts Clearing 28. Clearing “Indicates, whether the reported contract “Y=Yes, N=No.” obligation is subject to the clearing obligation under Regulation (EU) No 648/2012.” 29. Cleared “Indicates, whether clearing has taken “Y=Yes, N=No.” place.” 30. Clearing Time and date when clearing took place. ISO 8601 date format / UTC time format. timestamp 31. CCP “In case of a contract that has been cleared, “Legal Entity Identifier (LEI) (20 alphanumerical digits) or, if not available, the unique code for the CCP that has interim entity identifier (20 alphanumerical digits) or, if not available, BIC (11 cleared the contract.” alphanumerical digits).” 11

32. Intragroup “Indicates whether the contract was “Y=Yes, N=No.” entered into as an intra-group transaction, defined in Article 3 of Regulation (EU) No 648/2012.”

Section 2e “If a UPI is reported and contains all the Interest rate Interest Rates information below, this is not required to derivatives be reported.” 33. Fixed rate of “An indication of the fixed rate leg 1 used, if “Numerical digits in the format xxxx,yyyyy.” leg 1 applicable.” 34. Fixed rate of “An indication of the fixed rate leg 2 used, if “Numerical digits in the format xxxx,yyyyy.” leg 2 applicable.” 35. Fixed rate “The actual number of days in the relevant “Actual/365, 30B/360 or Other.” day count fixed rate payer calculation period, if applicable.” 36. Fixed leg pay- “Frequency of payments for the fixed rate “An integer multiplier of a time period describing how often the counterpar- ment frequency leg, if applicable.” ties exchange payments, e.g. 10D, 3M, 5Y.” 37. Floating rate “Frequency of payments for the floating rate “An integer multiplier of a time period describing how often the counterpar- payment leg, if applicable.” ties exchange payments, e.g. 10D, 3M, 5Y.” frequency 38. Floating rate “Frequency of floating rate leg resets, if “An integer multiplier of a time period describing how often the counterpar- reset frequency applicable.” ties exchange payments, e.g. 10D, 3M, 5Y.” 39. Floating rate “An indication of the interest rates used “The name of the floating rate index, e.g. 3M Euribor.” of leg 1 which are reset at predetermined intervals by reference to a market reference rate, if applicable.” 40. Floating rate “An indication of the interest rates used “The name of the floating rate index, e.g. 3M Euribor.” of leg 2 which are reset at predetermined intervals by reference to a market reference rate, if 159 applicable.” Appendix: Table of fields to be reported under ESMA

Section 2f – “If a UPI is reported and contains all the Currency Foreign Exchange information below, this is not required to derivatives be reported.” 41. Currency 2 “The cross currency, if different from the “ISO 4217 Currency Code, 3 alphabetical digits.” currency of delivery.” 42. Exchange The contractual rate of exchange of the “Up to 10 numerical digits in the format xxxx,yyyyy.” rate 1 currencies. 43. Forward Forward exchange rate on value date. “Up to 10 numerical digits in the format exchange 192 rate xxxx,yyyyy.” 44. Exchange rate Quote base for exchange rate. E.g. EUR/USD or USD/EUR. basis Section 2g - “If a UPI is reported and contains all the Commodity Commodities information below, this is not required to derivatives be reported unless to be reported according to Regulation (EU) No 1227/2011.” General 45. Commodity Indicates the type of commodity underlying “AG=Agricultural base the contract. EN=Energy FR=Freights ME=Metals IN= Index EV= Environmental 12 EX= Exotic” 46. Commodity Details of the particular commodity beyond “Agricultural details field 45. 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 Delivery points(s) of market area(s). “EIC code, 16 character alphanumeric code.” or zone 48. Interconnection Identification of the border(s) or border “Free text, field of up to 50 characters.” Point point(s) of a transportation contract. 49. Load type Repeatable section of fields 50-54 to Repeatable section of fields 50-54 to identify the product delivery profile; identify the product delivery profile which BL=Base Load PL=Peak Load OP=Off-Peak BH= Block Hours OT=Other correspond to the delivery periods of a day. 50. Delivery start Start date and time of delivery. ISO 8601 date format. date and time Appendix: Table of fields to be reported under ESMA

51. Delivery end End date and time of delivery. ISO 8601 date format. date and time 52. Contract Quantity per delivery time interval. “Free text, field of up to 50 characters.” capacity 53. Quantity Unit Daily or hourly quantity in MWh or kWh/d “10 numerical digits in the format xxxx,yyyyy.” which corresponds to the underlying commodity. 54. Price/time “If applicable, price per time interval “10 numerical digits in the format xxxx,yyyyy.” interval quantities quantities.” Section 2h - “If a UPI is reported and contains all the Contracts Options information below, this is not required to that contain be reported.” an option 55. Option type Indicates whether the contract is a call or “P=Put, C=Call.” a put. 56. Option style “Indicates whether the option may be “A=American, B=Bermudan, E=European, S=Asian.” (exercise) 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).” 57. Strike price The strike price of the option. “Up to 10 Numerical digits in the format xxxx,yyyyy.” (cap/floor rate) Section 2i - All contracts Modifications to 13 the report 58. Action type “Whether the report contains:”a derivative “N=New contract or post-trade event for the first M=Modify time, in which case it will be identified as E=Error, „new”; C=Cancel, ¤¤a modification of details of a previously Z=Compression, reported derivative contract, in which case V=Valuation update, it will be identified as „modify”; O=Other.” ¤¤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 Where field 58 is reported as „other” the “Free text, field of up to 50 characters.” action type details of such amendment should be specified here. 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 email to [email protected]. To learn about career opportunities at DTCC, please go to dtcc.com/careers.

Feb 2016 WWW.DTCC.COM P 11952 02 2016