Trade Repositories under European Markets Infrastructure Regulation will shortly become a reality once the European Securities and Markets Authority approves the registration application made by multiple trade repository aspirants.  European Securities and Markets Authority (ESMA) has published an updated version of its EMIR implementation timetable and as per this timetable trade repository registration approval expected by about 7th Nov 2013.

Trade Repositories

A trade repository is an entity that maintains a centralised electronic record (data base) of transaction data

By centralising the collection, storage, and dissemination of data, a well-designed TR that operates with effective risk controls can serve an important role in enhancing the transparency of information to relevant authorities and the public, promoting financial stability, and supporting the detection and prevention of market abuse

An important function is to provide information that supports risk reduction, operational efficiency, and cost savings for both individual entities and the market as a whole

TRs have emerged as a new type of Financial Markets Intermediary and have recently grown in importance, particularly in the OTC derivatives market. As market infrastructures continue to evolve, TRs are also developed for a variety of products and asset classes both within and across particular jurisdictions

Central banks, market regulators, and other relevant authorities for TRs have a responsibility to mutually support each other’s access to data in which they have a material interest as part of their regulatory, supervisory, and oversight responsibilities, consistent with the G20 Declaration at the 2010 Toronto Summit

Though the trade data are available at each bank even now, a centralised collection and storage of date is very much desired for the above. And the focus therefore is on trade repositories

European Market Infrastructure Regulation

The main obligations under EMIR are:

• Central Clearing for certain classes of OTC derivatives;
• Application of risk mitigation techniques for non-centrally cleared  OTC derivatives;
• Reporting to trade repositories;
• Application of organisational, conduct of business and prudential  requirements for CCPs;
• Application of requirements for Trade repositories, including the  duty to make certain data available to the public and relevant authorities

This post focuses on Trade Repositories and the reporting requirements to such trade repositories.

A counter party should be able to delegate the reporting of a contract to the other counterparty or to a third party

Counterparties should also be able to agree to delegate reporting to a common third party including Central Counter Party

The report should indicate that it is made on behalf of both counterparties.

To avoid inconsistencies in the Common Data Tables, each counter party to a derivative contract should ensure that the Common Data reported is agreed between both parties to the trade

A unique trade identifier will help with the reconciliation of the data in the case that the counterparties are reporting to different trade repositories.

To avoid duplicate reporting and to reduce the reporting burden, where one counterparty or CCP reports on behalf of both counterparties, the counterparty or CCP should be able to send one report to the trade repository containing the relevant information.

Valuation of derivative contracts is essential to allow regulators to fulfil their mandates, in particular when it comes to financial stability. The mark to market or mark to model value of a contract indicates the sign and size of the exposures related to that contract, and complements the information on the original value specified in the contract.

Gathering information on the collateral pertaining to a particular contract is essential to ensuring the proper monitoring of exposures. To enable this, counterparties that collateralize their transactions should report such collateralisation details on a transaction level basis.

Where collateral is calculated on the basis of net positions resulting from a set of contracts, and is therefore not posted on a transaction level basis but on a portfolio basis, counterparties should be able to report the portfolio using a unique code or numbering system as determined by the counterparty.

That unique code should identify the specific portfolio over which the collateral is exchanged where the counterparty has more than one portfolio and should also ensure that a derivative contract can be linked to a particular portfolio over which collateral is being held.

Where one counterparty reports the details of a contract to a trade repository on behalf of the other counterparty, or a third entity reports a contract to a trade repository on behalf of one or both counterparties, the details reported shall include the full set of details that would have been reported had the contracts been reported to the trade repository by each counterparty separately.

Where a contract is concluded in a trading venue and cleared by a CCP such that a counter party is not aware of the identity of the other counterparty, the reporting counterparty shall identify that CCP as its counterparty.

Where a counterparty does not collateralise on a transaction level basis, counterparties shall report to a trade repository collateral posted on a portfolio basis.

Where the collateral related to a contract is reported on a portfolio basis, the reporting counterparty shall report to the trade repository a code identifying the portfolio of collateral posted to the other counterparty related to the reported contract.

Reporting requirements

Reports to a trade repository under EMIR shall cover: (a) Table 1 –  the details which contains information relating to the counterparties to a contract; (b) Table 2 – the information which contains details pertaining to the derivative contract concluded between the two counterparties.

Table 1 – Counterparty Data

The table 1 will cover the following counterparty data elements

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 – 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
4. Name of the counterparty – Corporate name of the reporting counterparty. This field can be left blank in case the counterparty ID already contains this information
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
6. Corporate sector of the counterparty – Nature of the reporting counterparty’s company activities (bank, insurance company etc.) This field can be left blank in case the counterparty ID already contains this information
7. Financial or non financial nature of the counterparty – Indicate if the reporting counterparty is a financial or non financial counterparty
8. Broker ID – In case a broker acts as an intermediary for the reporting counterparty without becoming a counter party 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
10. Clearing member ID – In case the reporting counterparty is not a clearing member, its clearing member shall be identified by this field by a unique code. In case of an individual a client code as assigned by the CCP shall be used
11. 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 shall 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 – 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
13. Counterparty side – Identifies whether the contract was a buy or 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 with non EEA counterparty – Indicates whether the other counterparty is domiciled outside the EEA
15. Directly linked to a commercial activity or treasury financing – Information on whether the contract is objectively measurable as directly linked to the reporting counterparty’s commercial or treasury fianncing activity. This field shall be left blank in case the reporting counterparty is a financial counterparty
16. Clearing threshold – Information on whether the reporting counterparty is above the clearing threshold. This field shall be left blank in case the reporting counterparty is a financial counterparty
17. Mark to  market value of contract – Mark to market valuation of the contract, or mark to model valuation where applicable
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
19. 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 – Indicate whether valuation was performed mark to market or mark to model
22. Collaterlisation – When collaterlisation was performed
23. Collateral portfolio – 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
24. Collateral portfolio code – If the collateral is reported on a portfolio basis, the portfolio should be identified by a unique code determined by the reporting counterparty
25. Value of the collateral – 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
26. Currency of the collateral value – Specify the value of the collateral

Table 2 – Common data

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 identifer does not exist
5. Notional currency 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 currency 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

Details on the transaction

1. 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
2. Transaction Reference Number – A unique identification number for the transaction provided by the reporting entity or a third party reporting on its behalf
3. 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 bit traded OTC or not admitted to trading and traded OTC
4. Compression – identify whether the contract results from a compression exercise
5. Price / Rate – The price per derivative excluding, where applicable commission and accrued interest
6. Price notation – The manner in which the price is expressed
7. Notional amount – Original value of the contract
8. Price multiplier – The number of units of the financial instrument which are contained in a trading lot; for example the number of derivatives respresented by one contract
9. Quantity – Number of contracts included in the report, where more than one derivative contract is reported
10. Up front payment – Amount of any up front payment the reporting counterparty made or received
11. Delivery type – Indicates whether the contract is settled physically or in cash
12. Execution time stamp
13. Effective date – Date when obligations under the contract come into effect
14. Maturity date – Original date of expiry of the reported contract. An early termination shall nto be reported in this field
15. Termination date – Termination date of the reported contract. If not different from maturity date, this field shall be left blank
16. Date of settlement – Date of settlement of the underlying. If more than one further fields may be used
17. Master Agreement Type – Reference to the name of the relevant master agreement, if used for the reproted contract (e.g. ISDA Master Agreement; Master Power Purchase and Sale Agreement; International ForEx Master Agreement; European Master Agreement or any local Master Agreements)
18. Master Agreement Version – Reference to the year of the master agreement version used for the reported trade if applicable (e.g. 1992, 2002, etc

Risk Mitigation / Reporting

1. Confirmation time stamp – Date and  time of the confirmation, as defined under Commission Delegated Regulation indicating time zone in which the confirmation has taken place
2. Confirmation means – Whether the contract was electronically confirmed, non electronically confirmed or remains unconfirmed

Clearing

1. Clearing obligation – Indicates whether the reported contract is subject to the clearing obligation under Regulation
2. Cleared – Indicates, whether clearing has taken place
3. Clearing timestamp – Time and date when clearing took place
4. CCP – in case of a contract that has been cleared, the unique code for the CCP that has cleared the contract
5. Intragroup – Indicates whether the contract was entered into as an intragroup transaction

Interest Rates

1. Fixed rate of leg 1 – An indication of the fixed rate leg 1 used, if applicable
2. Fixed rate of leg 2 – An indication of the fixed rate leg 2 used, if applicable
3. Fixed rate day count – The actual number of days in the relevant fixed rate payer calcualtion period, if applicable
4. Fixed leg payment frequency – Frequency of payments for the fixed rate  leg, if applicable
5. Floating rate payment frequency – Frequency  of paymebts for the floating rate leg, if applicable
6. Floating rate reset frequency – Frequency of floating rate leg resets, if applicable
7. Floating rate of leg 1 – An indication of interest rates used which are reset at predetermined intervals by reference to a market reference rate, if applicable
8. Floating rate of leg 2 – An indication of interest rates used which are reset at predetermined intervals by reference to a market reference rate, if applicable

Foreign exchange

1. Currency 2 – The cross currency if different from the currency of delivery
2. Exchange rate 1 – The contractual rate of exchange of the currencies
3. Forward exchange rate – Forward exchange rate on value date
4. Exchange rate basis – Quote base for exchange rate

Commodities

1. Commodity base – Indicates the type of commodity underllying the contract
2. Commodity details – Details of the particular commodity beyond field 45

Energy

1. Delivery point or zone – Delivery point(s) of market area(s)
2. Interconnection point – identification of the border(s) or border point(s) of a transportion contract
3. Load type – Repeatable section of fields 50-54 to identify the product delivery type profile which correspond to the delivery periods of a day
4. Delivery start date and time – Start date and time of delivery
5. Delivery end date and time
6. Contract capacity – Quantity per delivery time interval
7. Quantity unit –  Daily or hourly quantity in MWh or kWh/d which corresponds to the underlying commodity
8. Price / time interval quantities – If applicable, price per time interval quantities

Options

1. Option type – Indicates whether the contract is a call or a put
2. 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)
3. Strike price (cap/floor rate) – Strike price (cap/floor rate)

Modifications to the report

1. Action Type – Whether the report cotains:

– a derivate 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’

       2. Details of action types – Where field 58 is reported as ‘other’ the details of such amendment should be specified here

Thus these regulations are expected to facilitate the regulatory supervisors in the management of high leverage, high level of customization, lack of transparency, high market concentration, high interconnection of large market participants and lack of regulation in the large volume OTC markets.

Related Articles