Q&As
What is the new XML message standard that will apply from 29 April 2024?
For submissions of EMIR reports to the EU trade repositories – ISO 20022 XML EMIR REFIT outgoing message standard that is available here.
For response files and status report files from the EU trade repositories – ISO 20022 XML EMIR REFIT incoming message standard that is available here.
The validation rules document sets out detailed technical rules on how the trade repositories should verify the completeness and accuracy of the reported data as well as the conditions and thresholds to be applied to determine whether the values reported by both counterparties match or not.
What are the new fields “Report submitting entity ID” and “Entity responsible for reporting” used for?
ESMA introduced a new field “Report submitting entity ID” (RSE). This field should be populated with the LEI of a third party or the counterparty in the case the entity responsible for reporting has delegated the submission of the EMIR report to a third party or to the other counterparty. In case there is no delegation in place, the entity responsible for reporting should be identified in this field.
ESMA introduces a new field “Entity responsible for reporting”(ERR). This field should be populated with the LEI of the relevant company that is solely responsible and legally liable for the EMIR reporting.
The definition is the following:
“Where a financial counterparty is solely responsible, and legally liable, for reporting on behalf of both counterparties in accordance with Article 9(1a) of Regulation (EU) No 648/2012 of the Parliament and of the Council (1) and the non-financial counterparty does not decide to report itself the details of its OTC derivative contracts with the financial counterparty, the unique code identifying that financial counterparty.
Where a management company is responsible, and legally liable, for reporting on behalf of an Undertaking for Collective Investment in Transferable Securities (UCITS) in accordance with Article 9(1b) of that Regulation, the unique code identifying that management company.
Where an Alternative Investment Fund Manager (AIFM) is responsible, and legally liable, for reporting on behalf of an Alternative Investment Fund (AIF) in accordance with Article 9(1c) of that Regulation, the unique code identifying that AIFM.
Where an authorised entity that is responsible for managing and acting on behalf of an IORP is responsible, and legally liable, for reporting on its behalf in accordance with Article 9(1d) of that Regulation, the unique code identifying that entity. This field is applicable only to OTC derivatives.
This field is applicable only to OTC derivatives.”
Please note that mandatory delegation covers OTC derivative and the relevant company can opt out from the mandatory delegation. There is no mandatory delegation for ETDs.
ESMA provides the table below:
Population of the fields pertaining to counterparties, report submitting entity and entity responsible for reporting
Scenario Report submitting entity (RSE), field 1.2 Entity responsible for reporting (ERR), field 1.3 Counterparty 1, field 1.4 Counterparty 2, field 1.9
FC reporting on behalf of NFC- in accordance with Article 9(1a), OTC derivatives Leg 1 FC LEI FC LEI FC LEI NFC- LEI
Leg 2 FC LEI FC LEI NFC- LEI FC LEI
FC reporting on behalf of NFC- in accordance with Article 9(1a), OTC derivatives and FC delegating to RSE Leg 1 RSE LEI FC LEI FC LEI NFC- LEI
Leg 2 RSE LEI FC LEI NFC- LEI FC LEI
NFC- opting out from FC reporting on their behalf in accordance with Article 9(1a) Leg 1 FC LEI FC LEI FC LEI NFC- LEI
Leg 2 NFC- LEI NFC- LEI NFC- LEI FC LEI
NFC- opting out from FC reporting on their behalf in accordance with Article 9(1a) FC delegating to RSE, NFC delegating to RSE2 Leg 1 RSE LEI FC LEI FC LEI NFC- LEI
Leg 2 RSE2 LEI NFC- LEI NFC- LEI FC LEI
NFC+ delegating to FC Leg 1 FC LEI FC LEI FC LEI NFC+ LEI
Leg 2 FC LEI NFC+ LEI NFC+ LEI FC LEI
NFC+ delegating to FC and FC subdelegating to RSE Leg 1 RSE LEI FC LEI FC LEI NFC+ LEI
Leg 2 RSE LEI NFC+ LEI NFC+ LEI FC LEI
Management company / AIFM (IFM) reporting on behalf of the fund under Article 9(1c) Leg 1 LEI IFM LEI IFM LEI fund LEI CPT
Leg 2 LEI CPT LEI CPT LEI CPT LEI fund
Management Company / AIFM (IFM) reporting on behalf of the fund under Article 9(1c) and delegating to the CPT Leg 1 LEI CPT LEI IFM LEI fund LEI CPT
Leg 2 LEI CPT LEI CPT LEI CPT LEI fund
Management Company / AIFM (IFM) reporting on behalf of the fund under Article 9(1c) and delegating to a RSE (third party) Leg 1 LEI RSE LEI IFM LEI fund LEI CPT
Leg 2 LEI CPT LEI CPT LEI CPT LEI fund
FC trading with NFC- and the contract is an ETD Leg 1 FC LEI FC LEI FC LEI NFC- LEI
Leg 2 NFC- LEI NFC- LEI NFC- LEI FC LEI
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.
ESMA maintains an updated List of third-country markets considered as equivalent to a regulated market in the Union for the purposes of the definition of OTC derivatives. In case the contracts are listed contracts executed on the exchanges in the list, they are considered as ETDs, otherwise they are considered OTC derivatives.
What are the new rules for Unique Trade Identifier (UTI) under EMIR REFIT?
The Unique Trade Identifier (UTI) is a unique code of a derivative between two counterparties. A pair of counterparties should use a specific UTI for one single derivative, and not reuse that same UTI to report any other derivative under EMIR.
The same principle applies to the UTIs generated for the derivatives reported at a position level. The UTI must be identical in the reports of both counterparties entering into a derivative.
According to the Guidelines issued by ESMA timely generation and communication of the UTI is crucial to ensure that counterparties can comply in a timely manner with their reporting obligation. Where one of the counterparties is responsible for the generation of the UTI, both counterparties should make the necessary arrangements in order for the generating counterparty, to timely generate the UTI, use it in its own reporting and communicate it to the other counterparty, and for the receiving counterparty, to ingest the UTI and use the same UTI (without alteration or truncation) in its own reporting. As a best practice, the manual intervention in the process of sharing the UTI should be avoided and digital means should be favoured.
The 10:00 am deadline for UTI generation and communication applies to all derivatives, including the derivatives reported at position level. In case the generating party fails to generate or communicate the UTI in due time, which is 10:00 am UTC on T+1, in order to meet the reporting deadline, the receiving party should contact the generating party and enquire about the process instead of reporting using an UTI generated on its own.
Please find below the UTI generation flowchart published by ESMA – art. 7(3) of EMIR REFIT ITS.
Alternatively, according to art. 7(5) of EMIR REFIT ITS, generation of the UTI may be delegated to an entity different from that determined in accordance with paragraph 3. The entity generating the UTI shall comply with the requirements set out in paragraphs 2 and 4.
The requirements in paragraph 2 are referring to the UTI’s elements: “The UTI shall be composed by the LEI of the entity which generated that UTI followed by a code containing up to 32 characters which is unique at the level of the generating entity.”
The requirements in paragraph 4 are “The counterparty generating the UTI shall communicate the UTI to the other counterparty in a timely manner and no later than 10:00 a.m. Coordinated Universal Time of the working day following the date of the conclusion of the derivative.”
What is Unique Product Identifier (UPI) and when it should be used?
As specified in the ITS on reporting, the derivatives that are:
(i) admitted to trading or traded on a trading venue or
(ii) are traded on a systematic internaliser and their underlying is admitted to trading or traded on a trading venue or is an index or basket composed of instruments traded on a trading venue;
should be identified in field 2.7 (“International Securities Identification Number (ISIN)”) using an ISO 6166 International Securities Identification Number (ISIN) code.
The remaining derivatives should be identified in field 2.8 (“Unique product identifier (UPI)”) using an ISO 4914 Unique Product Identifier (UPI) code.
In the specific case of derivatives traded on exchange in a third country, the identification of the product is not required if both ISIN and UPI are not available.
In this way the relevant derivative products can be uniquely identified, while the counterparties are required to provide only one way of identification for a given product and consistency with MiFIR reporting requirements is retained.
The UPIs will be issued by ANNA DSB. Currently the UAT environment of ANNA DSB is available at uat.anna-dsb.com and the product definitions are available here.
The validation rules for field “Unique product identifier (UPI)” are:
1. If the field 2.7 (ISIN) is populated, this field shall be left blank.
2. If the field 2.7 (ISIN) is blank and the field 2.41 (Venue of execution) is not populated with a MIC of a third-country organised trading platform, this field shall be populated.
3. If the field 2.7 (ISIN) is blank and the field 2.41 (Venue of execution) is populated with a MIC of a third-country organised trading platform, this field is optional.
4. When populated, this field shall contain a valid UPI included in the UPI database maintained by the ANNA DSB. 12 alphanumerical characters, including a check digit.
In case this field is populated with data, the trade repositories will check whether this is a valid value. The field UPI is reconcilable and there is no tolerance. In order to avoid any reconciliation breaks, please make sure that both counterparties use the same UPI for the relevant derivative contract.
How the new field “Event Type” should be populated in combination with field “Action Type”?
The new field “Event type” is providing information about the type of business event that triggers a given report.
The table below specifies the allowable combinations of action types and event types, as well as sets out whether they apply at trade level, position level or both. The last column of the table indicates when a given action type can be reported without an event type.
More information is available on p. 126 of the Guidelines for reporting under EMIR.
Notifications to the National Competent Authority for misreporting, obstacles and significant issues
According to the Article 9(1e) of EMIR, the counterparties should report correctly and without duplication.
Further requirements for ensuring the data quality on the counterparty side are set out in Article 9 of the ITS on reporting and Article 1 and 3 of the RTS on data quality.
Article 9 of the ITS on reporting – Methods and arrangements for reporting:
1. The entity responsible for reporting (ERR) shall notify its competent authority and, if different, the competent authority of the reporting counterparty of any of the following instances:
(a) any misreporting caused by flaws in the reporting systems that would affect a significant number of reports;
(b) any reporting obstacle preventing the report submitting entity from sending reports to a trade repository within the deadline referred to in Article 9(1) of Regulation (EU) No 648/2012;
(c) any significant issue resulting in reporting errors that would not cause rejection by a trade repository in accordance with Commission Delegated Regulation (EU) 2022/1858 (7).
The entity responsible for reporting shall promptly notify any of those instances, as soon as it becomes aware of them.
The notification shall indicate at least the type of the error or omission, the date of the occurrence, scope of the affected reports, reasons for the errors or omissions, steps taken to resolve the issue and the timeline for resolution of the issue and corrections.
It is important that the companies are able to correctly categorize the issue, i.e., whether it falls under (a), (b) or (c).
Each identified data quality issue should be provided within a separate notification, unless several data quality issues are identified where these issues are closely related, e.g., induced by a common cause, with coinciding resolution timelines or common bug-fixes, or otherwise interlinked and impossible to separate into individual notifications. In such case it is possible to provide single notification for all these related data quality issues.
The assessment of significance should be performed as soon as the scope of the misreporting is identified and the number of records affected by the reporting issue is determined. The notification to NCAs should be sent without undue delay after the assessment is concluded and all the relevant information is gathered. If after the first assessment more affected records are identified, another assessment should be performed and the NCAs should be notified with an update. Since the assessment will be mostly executed on an ad-hoc basis, ESMA does not expect the ERRs to provide the notifications to competent authorities on regular basis.
Under Article 9(1)(a) of the ITS on reporting any misreporting caused by flaws in the reporting systems that would affect a significant number of reports should be notified. The requirement pertains to any flaw in the reporting systems on either ERR or RSE side, or at any other third-party reporting system if outsourcing is utilized. This scenario includes for example cases of technical problems excluding a large percentage of records from submission, systematic omission of certain fields in the reports, systematic reporting of incorrect or abnormal values in the reports (e.g. system errors in orders of numerical fields). Since the requirement to notify the authorities pertains to the ERR, RSE or any other third party involved in reporting should inform all the relevant ERRs if they experience system failures or identify any other flaw in their reporting systems. The RSE should send the notification to NCAs only if it is ERR for some or all of the counterparties on whose behalf it reports. Otherwise, if the RSE or any other third party involved in reporting is experiencing data quality issues, it should only inform the relevant ERRs about the details of the issue so that the ERRs are able to perform the assessment of significance of the issue. ERRs and RSEs are expected to have in place sufficient controls at the level of data reporting processes such that any of the above-mentioned issues are timely identified, reported to authorities and permanently remedied.
Significant number of reports should be assessed separately for each of the following categories:
Category 1 – reports with action types ‘New’, ‘Modify’, ‘Correct’, ‘Terminate’, ‘Error’, ‘Revive’, ‘Position component’,
Category 2 – reports with action type ‘Valuation’,
Category 3 – reports with action type ‘Margin update’.
If the number of reports affected by the reporting issue is significant in at least one of the categories, the competent authorities should be notified of the reporting issue.
Number of reports affected by misreporting is significant if it exceeds the following threshold:
NumOfAffReports / AverageMonthNum > Y% and
NumOfAffReports > X, i.e. NumOfAffReports >= Threshold = max {X; Y% of AverageMonthNum},
where X and Y are calibration constants, and AverageMonthNum is the average monthly number of submissions calculated on the day of assessment as
(NumOfReportsMonth-12 + NumOfReportsMonth-11 + … + NumOfReportsMonth-2 +
NumOfReportsMonth-1) / 12 = NumOfReportsLast12Months / 12
using the actual numbers of reports submitted during the last 12 months.
More information is available from page 183 of the Guidelines.
The Notification template is available at the validation rules published by ESMA, sheets Notifications_Declarations, Notifications_Instructions, Notifications_Template, Notifications_UTIs and Notifications_Examples.