ESMA published a revised set of Q&As on EMIR on 11 February, the eve of the EMIR transaction reporting go-live date. They include updates and new guidance in several areas, including transaction reporting.
This Client Alert pulls together the relevant new/modified sections from the latest Q&As (available at: http://www.esma.europa.eu/content/QA-VI-EMIR-Implementation) applicable to the 12 February EMIR reporting start date. We have reproduced those sections below with added commentary. The aim is to assist those who will need to ensure that their reporting set-up incorporates this new guidance to focus on the main points of relevance to them.
Our commentary is in dark red – for ease of reference. Pages 69 to 71 of the Q&As also include transaction reporting scenarios applicable to OTC trades. We have not reproduced them here.
There is a statement on ESMA's website mentioning the new Q&As saying that "ESMA appreciates that it will require a certain amount of time for both reporting firms and TRs to properly incorporate this further guidance." See http://www.esma.europa.eu/news/ESMA-provides-further-details-trade-reporting-updated-EMIR-QA?t=326&o=home.
- TR Question 4(b): Reporting of outstanding positions following the entry into force of EMIR (Backloading)
Commentary: This is a modification as opposed to a new question and reflects a clarification of previous guidance. It is reflective of what we and many others in the market had understood to be the position in any event. Nevertheless, it provides an additional degree of comfort that this common understanding was correct. The underlined language reflects the modification.
Q: Should information on valuation and collateral be reported for contracts entered into from 16 August 2012?
A: OTC derivatives transactions that are still outstanding on the date when the reporting obligation for this information comes into force (i.e. 180 days after the reporting start date) will need to include the information on valuation and collateral as from the date of the reporting obligation and not for all the days from 16 August 2012 to the date of the application of the reporting obligation pursuant to Article 5 of Commission Implementing Regulation (EU) No 1247/2012 of 19 December 2012 laying down implementing technical standards with regard to the format and frequency of trade reports to trade repositories according to Regulation (EU) No 648/2012 of the European Parliament and of the Council on OTC derivatives, central counterparties and trade repositories. Similarly, contracts that were terminated before the reporting obligation starts applying should not include the information on collateral and valuation.
- TR Question 10(d) – Codes: LEI (Legal Entity Identifier)
Commentary: This may make it difficult for European entities to enter into reportable EMIR trades with counterparties in jurisdictions where local law or regulation prevents information about that counterparty from being reported.
Q: If a counterparty is established in a third country whose legal framework prevents the disclosure of its identity by the European counterparty subject to the reporting obligation, how should the European counterparty fill the counterparty field?
A: Article 9(5) EMIR provides that at least the identities of the parties to the derivative contracts should be reported to trade repositories. This requirement cannot be waived. Therefore, a European counterparty dealing with counterparties that cannot be identified because of legal, regulatory or contractual impediments, would not be deemed compliant with Article 9(5) of EMIR.
- TR Question 18 – Article 9 of EMIR – Reporting to TRs: UTI construction
Commentary: As a matter of practicality it seems likely that most market participants would use either method 1 or method 2 to generate a UTI (Unique Trade Identifier), but ESMA prescribes certain alphanumerical characters as pre-defined prefixes dependent upon which method is used. You may have already had similar information if, and to the extent that, you have been told this by your TR (Trade Repository), but it is worthwhile highlighting this where you will be responsible for generating UTIs as this is the first time these methods have been set out by ESMA in its guidance on trade reporting.
The use of "should be allowed to be used" in the first paragraph below suggests that it is not mandatory to use the same trade identifier where the same trade is subject to two reporting obligations in different jurisdictions. Similarly, the use of "could" in the second last sentence suggests that Unique Swap Identifiers under Dodd-Frank can be, but are not required to be, used where a trade is reportable under both regimes.
The requirement to agree which form of a Unique Trade ID they will use (i.e. which generation method) before reporting a derivative contract may lead to some consternation and last minute emails between counterparties. Taking a pragmatic approach, if parties have already entered into reporting delegation agreements or have agreed which of them will be responsible for generating the UTI, then the policy aim behind this (i.e to avoid competing methods being used) should be achieved. If an agreement gives the generating party or the delegate a wide discretion then this may suffice as agreement to abide by the decision of that generating party as to which generation method is used. As a matter of good housekeeping, parties who generate UTIs on this basis may want to inform their counterparties which method they are using and that they have decided to use it in exercise of their agreed discretion.
Q: How to construct a Unique Trade ID?
A: Commission Delegated Regulation (EU) No 148/2013 specifies that in the absence of a Trade ID agreed at the European Level, a unique code should be generated and agreed with the other counterparty (Table 2, field 8). This means that only one Trade ID should be applicable to any one derivative contract that is reported to a trade repository under EMIR and that the same Trade ID is not used for any other derivative contract. It is also acknowledged that contracts reported under EMIR rules might also be reported under the rules of other jurisdictions. Hence, the same Trade ID should be allowed to be used in both those jurisdictions for reporting the given contract in order to facilitate the reconciliation among all the data sets.
Commission Implementing Regulation (EU) No 1247/2012 specifies that the Trade ID can have up to 52 characters. Therefore a Trade ID that is less than 52 characters in length is permissible provided that it meets the other criteria laid out here. There is no requirement to pad out Trade ID values to make them 52 characters long.
As an illustration, ESMA considers that any of the methods provided in the following list of Trade ID construction would be deemed to meet the requirements for reporting under EMIR. ESMA reserves the initial three character sequences 'E00' to 'E99' inclusive for these purposes. The Trade ID should be formed by the concatenation (without separators) of the three elements in each case.
a. The characters 'E01'. The characters '000' will also be permitted but only for derivative contracts executed before 12 February 2015.
b. The MIC code (ISO 10383) of the applicable trading venue.
c. A unique code generated by that trading venue or by a CCP used by that trading venue to clear the derivative contract. If the CCP generates the code and if derivative contracts executed on that trading venue could be cleared by more than one CCP, then measures should be put in place to avoid different CCPs generating the same value.
a. The characters 'E02'.
b. The (20 character) Legal Entity Identifier of the generating entity (normally one of the parties to the trade).
c. A unique code generated by the Unique Trade ID generating entity.
a. The characters 'E03'.
b. A unique code generated independently by both counterparties based on the pre-agreed set of information about the trade in such a way that both counterparties will arrive at the same code and that it would be unique with respect to any other report. The two counter-parties are responsible for providing the same code. The information used should include Common Data from Table 2 of the Commission Delegated Regulation (EU) No 148/2013 and the Legal Entity Identifiers of the two counterparties.
Note that ESMA considers this approach as sub-optimal and therefore intends to maintain it as a possibility only for derivative contracts that have been or will be entered into before 12 February 2015:
a. The characters 'E04' or '000'.
b. An identifier of the generating entity other than the full Legal Entity Identifier (normally one of the parties to the trade).
c. A unique code generated by the Unique Trade ID generating entity.
For derivative contracts that are also reportable under the provisions of the Dodd-Frank Act, the same value as would be reported under the Dodd-Frank Act, i.e. the Unique Swap Identifier, could be used.
Counterparties should agree which form of a Unique Trade ID they will use before reporting the derivative contract. This therefore includes determining the approach that they will use to define which entity generates the Unique Trade ID.
- TR Question 19 – Article 9 of EMIR – Reporting to TRs: UTI generation
Q: What criteria should be applied by the two counterparties to determine the one that would generate the Unique Trade ID?
A: ESMA would like to stress the importance of
the general obligation according to which the counterparties need
to agree the report's contents before submitting it to TRs.
This obligation stems from the requirement of Article 9(1) of EMIR,
'counterparties and CCPs shall ensure that the details of their
derivative contracts are reported without duplication' and is
specified in the European Commission's Frequently Asked
Questions document Section II Question 5:
At the same time, ESMA believes that there might be merits to suggest a non-binding approach that could be followed by counterparties in case of disagreement on the responsibility to generate a Unique Trade ID. This approach is suggested without prejudice to other arrangements on the generation of a Unique Trade ID that counterparties might agree on.
The generation and communication of the Unique Trade ID should occur at the earliest possible stage in the trade flow.
The following order of preference could be suggested for generation and communication of the Unique Trade ID:
- For centrally executed and cleared trades the code could be
- by execution venue for its member or
- at the point of clearing by the CCP for the clearing member. Subsequently, the Unique Trade ID could be generated by the clearing member for its counterparty (e.g. MiFID investment firm).
- For centrally confirmed and cleared trades – at the point of clearing by the CCP for the clearing member.
- For centrally confirmed but not cleared trades – at the point of confirmation (by the confirmation platform).
- For other trades, the following hierarchy could be followed:
- Financial counterparty generating the Unique Trade ID for their non-financial counterparty;
- Non-financial counterparty above the clearing threshold generating the Unique Trade ID for their non-financial counterparty below the clearing threshold;
- Within the same group of entities in case of disagreement the seller generates the Unique Trade ID.
TR Question 20 – Article 9 of EMIR – Reporting to TRs:
ESMA has said it appreciates time will be required for parties to fully comply with this updated guidance. Nevertheless, if parties are able to incorporate this part of the guidance into their transaction reports at an early stage, it may save them having to go back and complete these fields in reports they have already submitted if ESMA requires all submitted reports to follow this format.
Q: Are all fields specified in the Annex of the Commission Delegated Regulation (EU) No 148/2013 mandatory?
A: In general, all fields specified in the RTS are mandatory. Nevertheless, two different instances need to be acknowledged, namely:
1. The field is not relevant for a specific type of contract/trade, for example:
- settlement date field where the underlying is an index,
- commodity underlying field in case of equity derivatives,
- Domicile of the Counterparty in case of coverage by LEI.
2. The field is relevant for a given type of contract/trade, however:
a. there is a legitimate reason why the actual value of this field is not being provided at the time the report is being submitted, or
b. none of the possible values provided for in the Annex of the Commission Implementing Regulation (EU) 1247/2012 for a given field apply to the specific trade (e.g. in the case of report submitted by the CCP, field No 7 in the Table 1 Counterparty Data).
In order to enable the TRs distinguishing between the two instances above and allow them to comply with requirements of Article 19 of the Commission Delegated Regulation (EU) 150/2013 (in particular to verify the compliance of the reporting counterparty or submitting entity with the reporting requirements), a different approach should be envisaged when it comes to population of the not-relevant and relevant fields.
In the first case, since the field is not relevant for a given trade, it should be left blank.
In the second case, the mandatory relevant field should not be left blank and should include the NA value instead.
- TR Question 21 – Article 9 of EMIR – Reporting to TRs: UPI taxonomy
Commentary: Although most of this is unlikely to be news to most reporting parties, it is worth bearing in mind the clarification in point 4 that proprietary classification identifiers provided by TRs should not be used to complete data fields 2 and 3 of the Common Data section of a transaction report.
Q: In the absence of a Unique Product Identifier taxonomy endorsed in Europe, what identifiers should be used for derivative contracts for which neither ISIN nor AII codes are available?
A: According to Article 4(3) of the Commission Implementing Regulation (EU) No 1247/2012 in cases where a unique product identifier does not exist and a derivative contract cannot be identified by using the combination of ISIN or AII with the corresponding CFI code, the type of derivative contract shall be identified through the Interim taxonomy on the following basis:
1. The derivative class (field No 2 in the Table 2 Common data) shall be identified as one of the following:
c. foreign exchange;
e. interest rate;
2. The derivative type (field No 3 in the Table 2 Common data) shall be identified as one of the following:
a. contract for difference;
b. forward rate agreement;
3. In case of derivative contracts not falling into a specific derivative class or type, the report shall be made on the basis of the derivative class or derivative type that the counterparties agree the derivative contract most closely resembles.
4. In the absence of UPI taxonomy endorsed in Europe, no other taxonomy, classification or code should be used to populate these fields (i.e. Fields No 2 and 3 in the Table 2 Common data). If the Trade Repository offers a proprietary classification or taxonomy it could be used to populate other additional fields provided for by the given Trade Repository, but it should not be used for population of Fields No 2 and 3 referred to above.
- TR Question 22 – Article 9 of EMIR – Reporting to TRs: Venues with AII codes
Q: How to determine whether a particular contract has to be identified by the ISIN code or by the AII codes?
A: Derivative contracts traded on trading venues in the European Union and classified as the AII venues should be identified by the combination of the AII and CFI codes. The full list of such regulated markets (flagged as the AII venues in the 'Instrument Identifier' column) can be found in the MiFID Data Base (in the 'Regulated Markets' section) published on the ESMA website: http://mifiddatabase.esma.europa.eu/Index.aspx?sectionlinks_id=23&language=0&pageName=REGULATED_MARKETS_Display&subsection_id=0. Note that only the AII and CFI codes should be used for AII venues to ensure consistent reporting. For options and futures traded on MTFs the involved MTF should be consulted.
Derivative contracts traded on any other venues should be identified either by the ISIN code if available or, where ISIN code is not available, the Interim taxonomy as specified in Article 4(3) of the Commission Implementing Regulation (EU) No 1247/2012.
- TR Question 23 – Article 9 of EMIR – Reporting to TRs: AII code
Q: How to populate field No 2 (Product ID 1) in the Table 2 Common Data for the AII derivative contracts?
A: Field No 2 should be populated with the Exchange Product Code assigned by the Regulated Market. At the same time field No 10 (Venue of execution) in the Table 2 Common Data should be populated with the MIC code of the venue of execution and not with 'XOFF' or 'XXXX'.
- TR Question 24 – Article 9 of EMIR – Reporting to TRs: Buy/Sell indicator for swaps
Q: How should the field No 13 (Counterparty side) in the Table 1 Counterparty data be populated for the Equity, Debt and Dividend swaps?
A: As a general principal, the buyer of the
Equity Swap should be the Fixed Rate Payer (the buyer is the one
who receives the equity performance).
In case of Equity Swap – the buyer of the Equity Swap is the one who gets the risk of the price movement of the underlying (the Fixed Rate Payer and Equity Amount Receiver). So the seller is the Equity Amount Payer and Fixed Rate Receiver.
In case of the Equity Swap with two equity legs – the buyer of the Equity Swap is the one who gets the risk of the price movement of the underlying.
In case of Debt Swap – the buyer of the Debt Swap is the one who gets the risk of the price movement of the bond. So the seller is the Bond Performance Amount Payer and Fixed Rate Receiver.
In case of Dividend Swap – the buyer of the Dividend Swap is the one who receives the equivalent actual dividend payments, so the seller is the Dividend Payer and Fixed Rate Receiver.
- TR Question 25 – Article 9 of EMIR – Reporting to TRs: Decimal values in fields No 15 and 16
Q: Are decimal values allowed in the fields No 15 (Price multiplier) and 16 (Quantity) in the Table 2 Common data?
A: Yes, the specified format of up to 10 numerical digits should be understood as also allowing for the decimal values.
- TR Question 26 – Article 9 of EMIR – Reporting to TRs: Complex Contracts
Q: How the following cases should be reported:
a. A contract stemming from another contract (e.g. option on a future)
b. Trading strategies (e.g. Straddle or butterfly trades)
c. A transaction with 2 legs
a. If the first contract ceases to exist before giving rise to the second one which is materially different from the first one, the two contracts should be reported separately. Therefore, even though the two contracts are connected in the way they come into existence, they should be reported in two separate reports.
b. The two (or more) derivative contracts related to the same trading strategies should be reported separately.
c. Both legs of the contract should be reported in one report, where the combination of fields in the Annex of the Commission Delegated Regulation (EU) No 148/2013 provides for this. Otherwise, a report per leg should be submitted.
- TR Question 27 – Article 9 of EMIR – 'Leg 1' and 'Leg 2' fields
Q: Which leg of the transaction should be assigned to the 'Leg 1' field and which one to the "Leg 2"?
A: As these fields are included in the Table 2
as Common data, counterparties are expected to agree a consistent
approach to assigning each leg to the respective field in the
report. Lack of agreement would lead to reconciliation problems at
the TR level.
The obligation to agree the reports content stems from the requirement of Article 9(1) of EMIR, 'counterparties and CCPs shall ensure that the details of their derivative contracts are reported without duplication' and is specified in the European Commission's Frequently Asked Questions document Section II Question 5: http://ec.europa.eu/internal_market/financial-markets/docs/derivatives/emir-faqs_en.pdf.
Client Alert 14-048
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.