Data input for MiFID II / MiFIR transaction reporting is not necessarily straightforward, so you should make sure that you are collecting the correct information from clients. Quinn Perrott, General Manager of regulatory and compliance solutions provider TRAction Fintech, explains.
Quinn Perrott, TRAction Fintech
MiFIR introduces many requirements in respect of transaction reporting, including the requirement to report a wider range of data. We explored some of these requirements in depth in our articles covering LEIs and CFI and ISIN codes. In this article we explain some of the intricacies and difficulties of procuring and validating data and how these can be overcome.
Data validation – what is it?
At first glance, it may seem like population of data fields is straightforward, but in fact there are many intricacies and variations 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. The actual inputs accepted by Approved Reporting Mechanisms (“ARM”) may be more technically specific than the regulations. Ultimately, the regulatory requirements are executed through the IT requirements and therefore it’s important to consider the data and IT components in conjunction with the regulatory requirements.
Data validation, the process of ensuring that inputs match requirements as closely as possible so that the data will be considered valid by the ARM is covered by ESMA’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.
Identifiers for natural persons
The requirement to identify natural persons as part of the transaction reporting obligation is not without its challenges. Typically, proof of identification will be collected when a client is onboarded as part of a firm’s KYC protocols. However, this information may not be stored in such a way as to be easily accessible for use in a transaction reporting (e.g. many of our clients had previously just kept scanned copies of identification documents and did not store the details such as passport numbers in a database) or indeed 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 will have to 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;
Given that identifiers of natural persons are among the details of the report pertaining to a given transaction, the requirement to report correct and accurate details equally applies to natural person identifiers. 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 e.g. Italy, Spain. For citizens of these countries, investment firms struggling to obtain the requisite identifier before the MiFID II implementation date will need to request identification documents such as a passport.
Legal Entity Identifier (“LEI”) codes for corporate counterparties
ESMA has issued a statement announcing that for six months after the implementation of MiFID II / MiFIR on 3 January 2018, investment firms may provide a service which is subject to MiFIR transaction reporting requirements to a client who has not been issued with an LEI, provided that the investment firm obtains all the necessary information from the client to apply on its behalf for an LEI code. After 4 July 2018, investment firms will not be able to provide services triggering transaction reporting obligations to clients who do not have an LEI, i.e. the “No LEI, No Trade” rule will apply.
The ESMA Validation Rules state that when identifying the buyer or seller “if LEI is used, this field shall be populated with a valid LEI included in the GLEIF database maintained by the Central Operating Unit. The status of the LEI shall be “Issued”, “Lapsed”, “Pending transfer” or “Pending archival”.” So whilst an investment firm is required to make sure their corporate counterparties have a valid LEI prior to trading – “No LEI, No Trade” – the LEI can be in a lapsed state.
While executing investment firms should ensure that their LEI is renewed according to the terms of any of the accredited Local Operating Units of the Global Entity Identifier systems pursuant to Article 5(2) of RTS 22, there is no requirement under Article 13(3) to ensure that an LEI for a client or a counterparty has been renewed. Accordingly, the onus is on investment firms to make sure all their corporate customers have LEIs, however there is no ongoing requirement for the investment firm to monitor whether or not their client is renewing their LEI in a timely fashion.
If you would like to discuss the above or learn about how the identification and data validation requirements apply to you, please contact TRAction Fintech on +44 20 8050 1317.