improving the functioning of the otc derivatives

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.

1

INTRODUCTIONThe 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 ob-ligations 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 infor-mation to be provided to relevant regulatory bodies to enable systemic risk analysis.

KEY CONSIDERATIONS IN THE DEVELOPMENT OFESMA STANDARDS & REQUIREMENTSESMA makes reference to industry data standards in order to achieve consistency between the EU and its in-ternational 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 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 ESMAThe 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.

2

ESMA REPORTING OBJECTIVESESMA 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 instru-ment 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 EMIREMIR 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.

3

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 pos-sible 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 ensur-ing 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

4

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.

Counterparties and CCPs have been given 6 months after the reporting start date of respective asset classes to imple-ment 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 REPORTSThe 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 counter-party (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

5

WHEN TO REPORTUnder 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 en-tered into on or after 16 August 2012 and are not outstanding on or after the reporting start date of the respec-tive 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).

http://www.esma.europa.eu/page/European-Market-Infrastructure-Regulation-EMIR

6

WHO DO WE CONTACT WITH QUESTIONS ABOUT THE REPOSITORY?Europe and Middle East

[email protected] +44 207 650 1545

Asia-Pacific

[email protected] +81 3 6721 8876Singapore +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]

ESMA has published answers to FAQs on 20 March 2013 and 6 June 2013 on the esma.europa.eu web page.

mailto:[email protected]

mailto:GTR-Americas%40dtcc.com?subject=

mailto:[email protected]

http://www.esma.europa.eu/page/Post-trading-documents

7

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

ISO 8601 date format / UTC time format.

2. Counterparty ID “Unique code identifying the reporting counterparty. In case of an individual, a client code shall be used.”

“Legal Entity Identifier (LEI) (20 alphanumerical digits), interim entity identi-fier (20 alphanumerical digits), BIC (11 alphanumerical digits) or a client code (50 alphanumerical digits).”

3. ID of the other counterparty

“Unique code identifying the other coun-terparty 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.”


4. Name of the counterparty

Corporate name of the reporting counter-party. This field can be left blank in case the counterparty ID already contains this information.

100 alphanumerical digits or blank in case of coverage by Legal Entity Identi-fier (LEI).

5. Domicile of the counterparty

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

500 alphanumerical digits or blank in case of coverage by Legal Entity Identi-fier (LEI).

6. Corporate sector of the counterparty

“Taxonomy: A=Assurance undertaking authorised in accordance with Direc-tive 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 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 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/2012.”

“F=Financial Counterparty, N=Non-Financial Counterparty.”

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


9. Reporting entity 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.”

“Legal Entity Identifier (LEI) (20 alphanumerical digits), interim entity identi-fier (20 alphanumerical digits),BIC (11 alphanumerical digits) or a client code (50 alphanumerical digits).”

10. Clearing member ID

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


Appendix: Table of fields to be reported under ESMA

8

11. Beneficiary ID “The party subject to the rights and obliga-tions 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 benefi-ciary 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

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.

“P=Principal, A=Agent.”

13. Counterparty side

“Identifies whether the contract was a buy or a sell. In the case of an interest rate de-rivative contract, the buy side will represent the payer of leg 1 and the sell side will be the payer of leg 2.”

“B=Buyer, S=Seller.”

14. Contract with non-EEA counterparty

Indicates whether the other counterparty is domiciled outside the EEA.

“Y=Yes, N=No.”

15. Directly linked to commercial activity or treasury financing

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

“Y=Yes, N=No.”

16. Clearing threshold

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

“Y=Above, N=Below.”

17. Mark to market value of contract

“Mark to market valuation of the contract, or mark to model valuation where applicable under Article 11(2) of Regulation (EC) No 648/2012.”

“Up to 20 numerical digits in the format xxxx,yyyyy.”

18. Currency of mark to market value of the contract

“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/2012.”

“ISO 4217 Currency Code, 3 alphabetical digits.”

19. Valuation date Date of the last mark to market or mark to model valuation.

ISO 8601 date format.

20. Valuation time Time of the last mark to market or mark to model valuation.

UTC time format.

21. Valuation type Time of the last mark to market or mark to model valuation.

M=mark to market / O=mark to model.

22. Collateralisa-tion

Whether collateralisation was performed. “U=uncollateralised, PC= partially collateralised, OC=one way collateralised or FC- fully collateralised.”


9

23. Collateral portfolio

“Whether the collateralisation was per-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”

“Y=Yes, N=No.”

24. Collateral portfolio code

“If collateral is reported on a portfolio basis, the portfolio should be identified by a unique code determined by the reporting counterparty.”

Up to 10 numerical digits.

25. Value of the collateral

“Value of the collateral posted by the report-ing 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 the total amount of collateral posted; up to 20 numerical digits in the format xxxx,yyyyy.”

26. Currency of the collateral value

Specify the value of the collateral for field 25.

“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

All contracts

1. Taxonomy used The contract shall be identified by using a product identifier.

“Identify the taxonomy used:U=Product Identifier [endorsed in Europe]I=ISIN/AII + CFIE=Interim taxonomy”

2. Product ID 1 The contract shall be identified by using a product identifier.

“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”

3. Product ID 2 The contract shall be identified by using a product identifier.

“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”

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

ISIN (12 alphanumerical digits); LEI (20 alphanumerical digits); Interim entity identifier (20 alphanumerical digits); UPI (to be defined); B= Basket; I=Index.

5. Notional cur-rency 1

“The currency of the notional amount. In the case of an interest rate derivative contract, this will be the notional currency of leg 1.”


6. Notional cur-rency 2

“The currency of the notional amount. In the case of an interest rate derivative contract, this will be the notional currency of leg 2.”


7. Deliverable currency

The currency to be delivered. “ISO 4217 Currency Code, 3 alphabetical digits.”

Section 2b - Details on the transaction

All contracts

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

Up to 52 alphanumerical digits.


10

9. Transaction reference number

A unique identification number for the transaction provided by the reporting entity or a third party reporting on its behalf.

An alphanumeric field up to 40 characters

10. Venue of execution

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

“ISO 10383 Market Identifier Code (MIC), 4 digits alphabetical.Where relevant, XOFF for listed derivatives that are traded off-exchange or XXXX for OTC derivatives.”

11. Compression Identify whether the contract results from a compression exercise.

Y = if the contract results from compression; N= if the contract does not result from compression.

12. Price / rate “The price per derivative excluding, where 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 amount

Original value of the contract. “Up to 20 numerical digits in the format xxxx,yyyyy.”

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


16. 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 report-ing counterparty made or received.

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

18. Delivery type Indicates whether the contract is settled physically or in cash.

“C=Cash, P=Physical, O=Optional for counterparty.”

19. Execution timestamp

As defined in Article 1 (2). ISO 8601 date format / UTC time format.

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

“Termination date of the reported contract. If not different from maturity date, this field shall be left blank.”


23. Date of Settlement

“Date of settlement of the underlying. If more than one, further fields may be used (e.g. 23A, 123B, 23C…).”


24. Master Agree-ment type

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

“Free Text, field of up to 50 characters, identifying the name of the Master Agreement used, if any.”

25. Master Agree-ment version

“Reference to the year of the master agree-ment version used for the reported trade, if applicable (e.g. 1992, 2002, ...).”

“Year, xxxx.”


11

Section 2c - Risk mitigation /Reporting

All contracts

26. Confirmation timestamp

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

“ISO 8601 date format, UTC time format.”

27. Confirmation means

“Whether the contract was electronically confirmed, non-electronically confirmed or remains unconfirmed.”

“Y=Non-electronically confirmed, N=Non-confirmed, E=Electronically confirmed.”

Section 2d – Clearing

All contracts

28. Clearing obligation

“Indicates, whether the reported contract is subject to the clearing obligation under Regulation (EU) No 648/2012.”

“Y=Yes, N=No.”

29. Cleared “Indicates, whether clearing has taken place.”

“Y=Yes, N=No.”

30. Clearing timestamp

Time and date when clearing took place. ISO 8601 date format / UTC time format.

31. CCP “In case of a contract that has been cleared, the unique code for the CCP that has cleared the contract.”

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

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

“If a UPI is reported and contains all the information below, this is not required to be reported.”

Interest rate derivatives

33. Fixed rate of leg 1

“An indication of the fixed rate leg 1 used, if applicable.”

“Numerical digits in the format xxxx,yyyyy.”

34. Fixed rate of leg 2

“An indication of the fixed rate leg 2 used, if applicable.”

“Numerical digits in the format xxxx,yyyyy.”

35. Fixed rate day count

“The actual number of days in the relevant fixed rate payer calculation period, if ap-plicable.”

“Actual/365, 30B/360 or Other.”

36. Fixed leg pay-ment frequency

“Frequency of payments for the fixed rate leg, if applicable.”

“An integer multiplier of a time period describing how often the counterpar-ties exchange payments, e.g. 10D, 3M, 5Y.”

37. Floating rate payment frequency

“Frequency of payments for the floating rate leg, if applicable.”


38. Floating rate reset frequency

“Frequency of floating rate leg resets, if applicable.”


39. Floating rate of leg 1

“An indication of the interest rates used which are reset at predetermined intervals by reference to a market reference rate, if applicable.”

“The name of the floating rate index, e.g. 3M Euribor.”

40. Floating rate of leg 2

“An indication of the interest rates used which are reset at predetermined intervals by reference to a market reference rate, if 159 applicable.”

“The name of the floating rate index, e.g. 3M Euribor.”


12

Section 2f – Foreign Exchange


Currency derivatives

41. Currency 2 “The cross currency, if different from the currency of delivery.”


42. Exchange rate 1

The contractual rate of exchange of the currencies.


43. Forward exchange rate

Forward exchange rate on value date. “Up to 10 numerical digits in the format192xxxx,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 accord-ing to Regulation (EU) No 1227/2011.”

Commodity derivatives

General

45. Commodity base

Indicates the type of commodity underlying the contract.

“AG=AgriculturalEN=EnergyFR=FreightsME=MetalsIN= IndexEV= EnvironmentalEX= Exotic”

46. Commodity details

Details of the particular commodity beyond field 45.

“AgriculturalGO= Grains oilseedsDA= DairyLI= LivestockFO= ForestrySO= SoftsEnergyOI= OilNG = Natural gasCO= CoalEL= ElectricityIE= Inter-energyMetalsPR= PreciousNP = Non-preciousEnvironmentalWE=WeatherEM= Emissions”

Energy “Information to be reported according to Regulation (EU) No 1227/2011, if ap-plicable.”

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 50-54 to identify the product delivery profile which correspond to the delivery periods of a day.

Repeatable section of fields 50-54 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.


13

51. Delivery end date and time

End date and time of delivery. ISO 8601 date format.

52. Contract capacity

Quantity per delivery time interval. “Free text, field of up to 50 characters.”

53. Quantity Unit Daily or hourly quantity in MWh or kWh/d which corresponds to the underlying com-modity.

“10 numerical digits in the format xxxx,yyyyy.”

54. Price/time interval quantities

“If applicable, price per time interval quantities.”

“10 numerical digits in the format xxxx,yyyyy.”

Section 2h - Options


Contracts that contain an option

55. Option type Indicates whether the contract is a call or a put.

“P=Put, C=Call.”

56. Option style (exercise)

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

“A=American, B=Bermudan, E=European, S=Asian.”

57. Strike price (cap/floor rate)

The strike price of the option. “Up to 10 Numerical digits in the format xxxx,yyyyy.”

Section 2i - Modifications to the report

All contracts

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 „valua-tion update”; ¤ any other amendment to the report, in which case it will be identified as „other.”

“N=NewM=ModifyE=Error,C=Cancel,Z=Compression,V=Valuation update,O=Other.”

59. Details of action type

Where field 58 is reported as „other” the details of such amendment should be specified here.

“Free text, field of up to 50 characters.”


WWW.DTCC.COM

P 11

952

02 2

016

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

improving the functioning of the otc derivatives

Documents