Q&As

Which entities does the definition “authorised or registered AIFMs” cover?

The definition of a financial counterparty provided in Article 2(8) of EMIR includes AIFs (Alternative Investment Funds) which are managed by authorised or registered AIFMs (Alternative Investment Fund Manager). The definition of a financial counterparty should be understood as covering the following entities:

 

    1. EU AIFs managed by authorised EU AIFMs.
    2. EU AIFs managed by registered EU AIFMs.
    3. Non-EU AIFs managed by authorised EU AIFMs.
    4. Non-EU AIFs managed by registered EU AIFMs.
    5. EU AIFs managed by authorised non-EU AIFMs (subject to extension of the passport).
    6. Non-EU AIFs managed by authorised non-EU AIFMs (subject to extension of the passport).

 

Non-EU AIFs marketed in the Union by non-EU AIFMs (both below and above the thresholds of Article 3(2) of the AIFMD) under Article 42 of the AIFMD should be considered as third-country entities because they are neither undertakings established in the Union nor are they managed by authorised or registered AIFMs. EU AIFs marketed in the Union without a passport by non-EU AIFMs (both below and above the thresholds of Article 3(2) of the AIFMD) under Article 42 of the AIFMD should be considered as non- financial counterparties because they are undertakings established in the Union and they are not man- aged by authorised or registered AIFMs.

If CFDs are without maturity date how they can be reported under EMIR?

According to the Q&As from ESMA each opening of a new contract should be reported by both of the counterparties to the trade repository (TR) as a new entry, i.e. field CD58 (Action Type) to be “N” for “New”. Once the contract is closed, both of the counterparties should send a termination report to the initial entry, completing the field “Termination date”.

If the contract is closed partially, counterparties send a modification report to the initial entry, reducing only its “Notional amount” (remaining volume is equal to the not yet terminated volume). If there is another partial close, yet another modification report is sent – until the contract is finally closed in whole. Then, the counterparties send a termination report marked as “cancelled”, completing the field “Termination date”. In these cases, the opening price of the contract is reported only in the first report (new) and it is not updated in the following modification reports.

Partial closes might be reported in a slightly different way by the different trade repositories. For example UnaVista requires the partial closes for cleared trades to be reported through a Cancel action type followed by a New action type. The termination date will be populated on the Cancel entry, and Execution timestamp will show the date and time of the original trade. The New trade will have a new UTI, a new notional amount and the Execution Timestamp will be populated with the new trade date.

 

What is the definition of OTC derivatives under EMIR?

The definition of OTC derivatives provided for in Article 2 of EMIR is the following: ‘OTC derivative’ or ‘OTC derivative contract’ means a derivative contract the execution of which does not take place on a regulated market as within the meaning of Article 4(1)(14) of Directive 2004/39/EC or on a third- country market considered as equivalent to a regulated market in accordance with Article 19(6) of Directive 2004/39/EC. The definition is relevant for a number of provisions in EMIR, including the positions of OTC derivatives that an NFC shall calculate for the purpose of determining whether it has reached a clearing threshold (Article 10), and the OTC derivative classes that NCAs shall notify to ESMA (Article 5). Consequently:

  • Derivative contracts traded on MTFs are OTC derivatives in the context of EMIR.
  • The definition explicitly refers to the place of execution (‘a derivative contract the execution of which does not take place on a regulated market’). The characteristics that these contracts have in common with exchange traded derivatives are therefore not relevant for the purpose of the definition of OTC derivatives.
  • Derivative contracts executed on non-EU exchanges that are equivalent to a regulated market in accordance with Article 19(6) of MiFID do not count for the purpose of the determination of the clearing threshold. Derivatives traded in other non-EU exchanges will count for the deter- mination of the clearing threshold. Article 19(6) states that the European Commission shall publish a list of those exchanges that are to be considered as equivalent. To date, there is no publicly available list of non-EU exchange equivalent to a regulated market, as envisaged under Article 19(6) of MiFID. In the absence of this list, all derivative contracts executed on non EU exchanges should be counted for the purpose of the determination of the clearing threshold.
  • Derivatives transactions, such as block trades, which are executed outside the trading platform of the regulated market, but are subject to the rules of the regulated market and are executed in compliance with those rules, including the immediate processing by the regulated market af- ter execution and the clearing by a CCP, should not be regarded as OTC derivatives transac- tions. Therefore, these transactions should not be considered for the purpose of the clearing obligation and the calculation of the clearing threshold by NFC that only relates to OTC derivatives.
  • Derivatives transactions that do not meet the conditions listed in the first paragraph of this sub- answer (d) should be considered OTC. For example, derivatives contracts that are not executed on a regulated market and are not governed by the rules of an exchange at the point of execution should be considered OTC even if after execution they are exchanged for contracts traded in a regulated market. However, the replacement contract itself may be considered ex- change traded if it meets the relevant conditions.

How should the information on collateral be reported to the trade repositories (TRs)?

As specified in Article 3 of Commission Delegated Regulation (EU) No 148/2013 (RTS on reporting to TR), collateral can be reported on a portfolio basis. This means the reporting of each single executed transaction should not include all the fields related to collateral, to the extent that each single transaction is assigned to a specific portfolio and the relevant information on the portfolio is reported on a daily basis (end of day).

The collateral should be reported at the total market value that has been posted by the Counterparty responsible for the report. Therefore any haircuts or similar used by the receiver of the collateral and any fees or similar amounts should all be ignored.

Should a collateral portfolio with multiple currency values be reported in one base currency?

There is only one collateral value field (Table 1, Field 25) and an associated currency field (Table 1, Field 26) on a report by a Counterparty. Therefore all collateral for a single portfolio should be reported in one single currency value. The reporting counterparty is free to decide which currency should be used as base currency as long as the base currency chosen is one of the major currencies which represents the greatest weight in the pool and is used consistently for the purpose of collateral reporting for a given portfolio.

How should non-cash collateral be reported?

According to the latest Q&As published by ESMA the non-cash collateral should be reported as its current cash equivalent as evaluated at the moment of posting/amending the collateral. ESMA does not provide further guidelines or requirements about the calculation method.

What to be included in the collateral amount?

ESMA gives further guidance in the Q&As that the collateral should be the sum of any initial margin (or similar) posted by the reporting counterparty and any variation margin (or similar) also posted by the reporting counterparty. Note that there is no obligation to report collateral received (to avoid double-counting) and therefore if the variation margin is flowing in the opposite direction to the initial margin, it would be the other counterparty that would have to report the variation margin on their report.

If the collateral amount is covering the exposures in transactions that are outside EMIR how to proceed?

The collateral reported should be just the collateral that covers the exposure related to the reports made under EMIR. However ESMA allows that in cases when this is impossible for the counterparties to distinguish within a pool of collateral the amount which relates to derivatives reportable under EMIR from the amount which relates to other transactions, the collateral reported can be the actual collateral posted covering a wider set of transactions.

Shall change in the amount of collateral be reported as modification (M) or as valuation update (V) in Table 2 field No. 58?

Valuation update (V) in field No. 58 refers to any change in fields 17 to 26 of table 1. Therefore, changes in the amount of collateral should be reported as a (V) in field 58. In case a correction of the amount of collateral should be submitted to a TR, the TR considers as a valid amount the last amount received by the reporting entity. In all cases the valuation update (V) should be used.

How should information on valuation be reported to the trade repositories (TRs)?

With reference to transactions cleared by a CCP, the fields on the contract valuation should be reported on a daily basis at position level, as maintained and valued by the CCP in accordance with Article 3 (5) of Commission Delegated Regulation (EU) No 148/2013. This does not mean that the report should be made by the CCP. The CCP may make data available to counterparties so that the latter report. The use of CCP valuation data does not mean duplication of reporting.

To the extent that counterparties of reported transactions are subject to the requirement to daily mark-to-market/mark-to-model them, changes in mark-to-market or mark-to-model valuations on already reported transactions need to be reported on a daily basis (end of day).

Should the variation margin be taken into account for the calculation of the mark to market value?

No, it is not permissible to report zero in the field 17, table 1 exclusively on the grounds that there is no market risk because variation margin has been paid. Any margin paid would be reflected in Counterparty Data field 25 and not in this field.

Which price should be considered for the purpose of calculating the mark-to-market value of contract to be reported in Table 1, Field 17?

The mark to market value (Table 1, Field 17) should be based on the End of Day settlement price of the market (or CCP) from which the prices are taken as reference. If an End of Day settlement price is not available, then the mark to market value should be based on the closing mid-price of the market concerned. Counterparties should use a mark-to-market or mark-to-model price as referred to in Article 11(2) of EMIR. For transactions cleared by a CCP, counterparties should use the CCP‘s valuation in accordance with Article 3 (5) of Commission Delegated Regulation (EU) No 148/2013.

How should the mark to market value be calculated?

The mark to market value should represent the absolute value of the contract.

Should the counterparties have to agree on the valuation reported (for non-cleared OTC derivative)?

Since the valuation is part of the Counterparty data, in the case of a derivative not cleared by a CCP, counterparties do not need to agree on the valuation reported.

How should the Collateral portfolio code be populated?

ESMA gives freedom to the Counterparty making the report to determine what unique value to put in the Collateral portfolio code (Table 1, Field 24). This field should only be populated if the Collateral portfolio (Table 1, Field 23) has the value “Y”.

It is, for example, permissible to use a value in this field that is supplied by the CCP, but this is not required and other values could be used.

How to construct a Unique Trade Identifier (UTI)?

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 (UTI) should be applicable to any one derivative contract that is reported to a trade repository under EMIR and that the same Trade ID (UTI) is not used for any other derivative contract. It is also acknowledged that contracts reported under EMIR rules might also 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 UTI 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 (UTI) should be formed by the concatenation (without separators) of the three elements in each case.

 

Method 1:

  • The characters “E01”. The characters “000” will also be permitted but only for derivative contracts executed before 12 February 2015.
  • The MIC code (ISO 10383) of the applicable trading venue.
  • 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.

 

Method 2:

  • The characters “E02”.
  • The (20 character) Legal Entity Identifier of the generating entity (normally one of the parties to the trade).
  • A unique code generated by the unique Trade ID generating entity. The characters “E03”.

 

Method 3:

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

 

Method 4:

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:

  • The characters “E04” or “000”.
  • An identifier of the generating entity other than the full Legal Entity Identifier (normally one of the parties to the trade).
  • 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 Identifier8, 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 (UTI).

How the two counterparties determine which one of them would generate the UTI?

Due to the low pairing rates within the trade repositories ESMA has tightened the rules about the UTI generation and in the latest Q&A’s has determined additional requirements. ESMA has underlined 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:

and in recital (2) of the Commission Delegated Regulation (EU) No 148/2013. On this basis, the latter Regulation states the general rule which applies in the absence of a UTI agreed at the European Level. According to this rule the UTI must be agreed with the other counterparty (see Table 2, field 8 of the Regulation). The generation and communication of the UTI should occur at the earliest possible stage in the trade flow.

Should counterparties fail to agree on the responsibility to generate a UTI, the following approach to UTI generation should be followed:

1. For centrally executed and cleared trades the UTI should be generated either:

  • by execution venue for its member or
  • at the point of clearing by the CCP for the clearing member. Subsequently, the UTI should be generated by the clearing member for its counterparty (e.g. MiFID investment firm).

2. For centrally confirmed and cleared trades – at the point of clearing by the CCP for the clearing member.

3. For centrally confirmed but not cleared trades – at the point of confirmation (by the confirmation platform).

4. For other trades, the following hierarchy should be followed:

  • Financial counterparty generating the UTI for their non-financial counterparty;
  • Non-financial counterparty above the clearing threshold generating the UTI for their non- financial counterparty below the clearing threshold;
  • Within the same group of entities in case of disagreement the seller generates the UTI.

 

Are all fields in the Annex of the Commission Delegated Regulation No 148/2013 (EMIR) mandatory?

ESMA has explain that 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:

  • 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
  • none of the possible values provided for in the Annex of the Commission Implementing Regu- lation (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 differ- ent 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 Not Available (NA) value instead.

TRs should apply validation rules to ensure that reporting is performed according to the EMIR regime, including the specifications of the Technical Standards. Accordingly, reporting counterparties or submitting entities should comply with the reporting requirements specified in the Validation table which can be found on ESMA‘s website. This includes the possible NA/Blank values of certain fields. In order to be compliant with the requirements of Article 19 of the Commission Delegated Regulation (EU) 150/2013, TRs should reject the reports which are not submitted in line with the reporting requirements specified in this Validation table.