MiFIR Transaction Reporting: PART 2

The new Markets in Financial Instruments Regulation (2014/600/EU) (MiFIR) is set to introduce a new and highly comprehensive, complex, and onerous regulatory reporting framework throughout the European Union (EU) for financial services firms in January 2018. In this four part series of blogs we aim to identify the complexities and challenges that the new MiFIR transaction reporting will introduce. In PART 1 we will set out an overview of the transaction reporting framework. In PART 2 we will set out the detailed operational requirements for firms. In PART 3 we will set out the challenges and complexities of MiFIR transaction reporting, and in PART 4 we will set out the reasons why firms should delegate their MiFIR reporting obligations.

An Overview of MiFIR Operational Requirements

The very broad definition of ‘Financial Instruments’ means that almost all financial instruments will fall within the Markets in Financial Instruments Directive (2014/65/EU) (MiFID II) and MiFIR regulatory compliance framework (e.g. cash equities, bonds, indexes, equity derivatives). The MiFIR reporting framework requires investment firms to provide data at a highly granular level for 65 data fields. Investment firms must report transactions to National Competent Authorities (NCAs) by the close of the following working day.

Under MiFIR, investment firms retain responsibility for the completeness, accuracy, and timeliness of submitted transaction reports. However, where they report transactions via an Approved Reporting Mechanism (ARM), firms devolve themselves of this responsibility. Nevertheless, they must take reasonable steps to verify the completeness, accuracy and timeliness of the transaction reports which were submitted on their behalf.

The data that is required to be populated in transaction reports and submitted to NCAs includes a very broad range of data that most likely pertains to a wide range of internal and external data sources. For example, it includes:

(1) the identity of the buyer (i.e. identification (ID) code, branch country, first name, surname, date of birth);

(2) the buyer decision maker (i.e. ID code, first name, surname, date of birth);

(3) transmission details (i.e. transmission of order indicator, transmitting firm ID codes for buyer and seller);

(4) transaction details (i.e. trading date, time, capacity, quantity price, price currency, net amount, venue);

(5) investment decision maker and executor (i.e. investment decision within firm, execution within firm);

(6) general fields (i.e. report status, transaction reference number);

(7) seller (i.e. seller ID code);

(8) seller decision maker (i.e. seller decision maker code);

(9) instrument details (i.e. instrument ID code, classification, notional currency);

(10) flags (i.e. waiver, short selling, over-the-counter (OTC) post-trade, commodity derivative, and securities financing transaction indicators).

The sheer breadth of data required to be submitted via transaction reports is likely to prove highly challenging for investment firms in practice. Indeed, the United Kingdom’s Financial Conduct Authority (FCA) has already questioned firms’ ability to meet these new and highly onerous transaction reporting obligations in its Market Watch 50. It noted that not only were firms submitting transaction reports late, but that inaccurate transaction reports also impacted the work of other users such as other competent authorities, the Bank of England, the Takeover Panel, and the Prudential Regulatory Authority.

The new MiFIR transaction reporting obligations will clearly require firms to review their existing systems in order to identify whether or not such systems will be able to provide the data needed to populate transaction reports in an accurate and timely manner. Given that firms are required to identify clients, and also identify individuals responsible for execution (i.e. Trader ID) and any computer algorithms responsible for the investment decision (i.e. Algo ID), this may prove to be particularly challenging for firms in practice.

If you would like to receive further information about our MiFID II expertise and solutions please email DataTracks at: enquiry@datatracks.eu.

Schedule A Demo

Schedule A Demo


















    Cancel