EMIR REFIT: Notification to NCAs on Data Quality Issues

In the second edition of our EMIR Refit review, we look at another significant reporting requirement introduced by ESMA and that is the Notification to NCAs on Data Quality Issues.

We are already familiar with this requirement under MIFIR, where firms are also required to inform their NCA, of any significant issues or omissions encountered during their transaction reporting process.

ESMA provides comprehensive guidance in the RTS/ITS and in the Final Report, regarding this Notification which highlights ESMA’s focus on data quality under EMIR REFIT. It is our understanding that ESMA wishes to complement the rejection and reconciliation statistics provided by the TRs to NCAs, with this Notification to NCAs on Data Quality Issues.

As indicated in Article 9 of the ITS, ESMA expects the following under EMIR REFIT:

The entity responsible for reporting shall notify its competent authority and, if different, the competent authority of the reporting counterparty of any of the following instances:

1. any misreporting caused by flaws in the reporting systems that would affect a significant number of reports;
2. 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;
3. 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

​​Also included in the validation rules recently published by EMSA, is the common template and the declaration that will need to be completed by the entity responsible for reporting under the Notification.

In the Final Report on the Guidelines for reporting under EMIR, specifically, chapter 4.29 Ensuring data quality by counterparties it outlines the information that will need to be provided in this Notification, which includes the following:

• The scope of the affected reports
• The type of errors or omissions
• The reasons for the errors or omissions
• Steps taken or planned to resolve the issue
• The date of the occurrence
• The timeline for resolution of the issue and data submission or correction.

ESMA has also provided the key metrics and clarifications for assessing the scope of notifications. Specifically providing clarifications and examples for the “significant number of reports” under point a. and “significant issue” under point c.

It also explains the significant number of reports should also be assessed separately into the following categories per Action type of the report:

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

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

ESMA provided the following buckets and thresholds based on the average monthly number of submissions:

 
ESMA also clarifies that cases under Article 9(1)(b) pertain to the complete inability to send any records to the TRs, while data quality issues under Article 9(1)(a) affect only a subset of reported records.

The significant issues under Article 9(1)(c), ESMA provides us with a list of examples of these issues:

1. Non-reporting or over-reporting of a derivative due to an erroneous assessment of its portability;
2. Incorrect or inconsistent interpretation of the number of reports to be reported for a specific derivative (e.g. in dispute with the other counterparty);
3. Incorrect or inconsistent interpretation of the content of the fields (e.g. in dispute with the other counterparty);
4. Reporting of non-standard derivatives for which the fields are not fully suited;
5. Errors and omissions that pertain to
   1. Incorrect data in the parties identification: fields 1.2 to 1.16, 1.20, 2.33, 2.37;
   2. Incorrect trade details: fields 1.17 to 1.19, 2.1 to 2.12, 2.38 to 2.41;
   3. Incorrect details on underlying: fields 2.13 to 2.18 – in particular when the basket is not complete;
   4. Amounts and currencies in all related fields (notional, valuation, collateral, price, strike …);
   5. Dates/timestamps: execution, event confirmation, expiration;
   6. Clearing fields 2.30 to 2.32;
   7. Incorrect report details: fields 2.151, 2.152 and 2.154;
   8. Collateral portfolio code: field 3.9;
   9. Errors in valuation methods result in incorrect reporting of valuation.