MiFIR requires a wide range of data in respect of transaction reporting. ESMA’s revised validation rules commenced on 31 May 2022.
What’s changed in ESMA’s update?
The updated rules which commenced on 31 May 2022 contain minor amendments and clarifications including:
- the date of birth fields of the Buyer/Seller;
- Buyer/Seller decision must not be later than the trade date;
- the MIC must be valid in the reference data on the transaction date; and
- the ‘EntityStatus’ must be active on trading date for Buyer/Seller and Buyer/Seller Decision Maker ID codes; and
- Investment decision within firm should be left blank if Buyer decision maker and Seller decision maker are left blank.
UK MiFIR Validation Rules
FCA’s MiFIR will not be changing the current validation rules used. The UK version of MIFIR will remain with the existing schema validation which will therefore be different from the EU version of MiFIR post 31 May 2022 – the first major divergence in the regime.
What is data validation?
Data validation, the process of ensuring that inputs match requirements as closely as possible so that the data will be considered valid by the Approved Reporting Mechanism (ARM), is covered by ESMA and FCA’s Data Validation Rules for Transaction Reporting (Validation File). The Validation File specifies rules to determine the data inputs that will be acceptable and the errors that can result if information is not reported correctly.
Why is data validation difficult?
There are several intricacies and variations involved in the population of MiFIR data fields that make the task far from clear. RTS 22, the standards to supplement MiFID II and MiFIR, provides generic formats and standards for inputs into reporting fields. However, the actual inputs accepted by ARMs may be more technically specific than the regulation. Therefore, it’s important to consider the data and IT components of the inputs in conjunction with the regulatory requirements.
Identifiers for Natural Persons
The requirement to identify natural persons as part of the transaction reporting obligation is not without its challenges. This information, typically collected during client onboarding procedures, is often not easily accessible for use in transaction reporting and/or the information itself may not be suitable from a transaction reporting perspective. For example, where a firm collects a client’s passport information but the passport is not one of the methods of identification stipulated within Annex II of RTS 22, the investment firm (IF) must request alternative identifiers from the client for the purpose of transaction reporting.
The extent to which a firm should go in verifying and validating the data supplied by a natural person is somewhat clarified by the MiFIR Transaction Reporting Guidelines which state the following:
“In order to ensure fulfilment of this requirement, investment firms could, among others, ask the natural person to prove the correctness and validity of the identifier by providing official documents. Where no identifier is provided by the client, the investment firm would not be able to comply with this detail of the transaction reporting requirements”.
An example is the case of citizens of countries within the EU that do not have the ‘CONCAT’ code (which is a concatenation of country code, date of birth, first name and surname) listed as a natural person identifier. For citizens of these countries, IFs will need to request identification documents such as a passport.
See our more detailed guide on natural person identifiers.
Legal Entity Identifier Codes for Corporate Counterparties
Since 4 July 2018, IFs have not been able to provide services triggering transaction reporting obligations to non-individual clients who do not have a Legal Entity Identifier (LEI). This is commonly referred to as the ‘No LEI, No Trade’ rule.
The ESMA and FCA Validation Rules state that when identifying the buyer or seller where an LEI is used, this field needs to be populated with a valid LEI that is included in the GLEIF database. The status of the LEI needs to be one of the following:
- “Issued”,
- “Lapsed”,
- “Pending transfer” or
- “Pending archival”.
So, whilst an IF is required to make sure their corporate counterparties have a valid LEI prior to trading, the LEI can be in a lapsed state. There is no requirement under Article 13(3) for an IF to ensure that the LEI of a client or a counterpartyhas been renewed.
In contrast, IFs must ensure that their own LEI is renewed according to the terms of any of the accredited Local Operating Units of the Global Legal Entity Identifier Foundation (GLEIF) systems pursuant to Article 5(2) of RTS 22.
If you would like to discuss the above or need assistance validating your MiFIR data, please contact us.
