MiFIR transaction reporting — how a report is built

Most MiFIR reporting failures are not field errors. They are scope errors — reporting something that is not a transaction, or missing something that is. Delegated Regulation (EU) 2017/590 answers both questions directly: Article 2 defines what a transaction is for Article 26 purposes, and Article 15 sets out the control mechanisms a reporting arrangement must contain. Read together, they are a specification for the reporting system itself, not merely for the file.

1. What counts as a transaction

For the purposes of Article 26 of Regulation (EU) No 600/2014, the conclusion of an acquisition or disposal of a financial instrument constitutes a transaction. Both limbs are then defined, and each contains a derivatives case that is easy to miss:

Article 2(4) adds a case that has no economic movement at all: a simultaneous acquisition and disposal of a financial instrument where there is no change in ownership, but post-trade publication is required under Articles 6, 10, 20 or 21 of MiFIR. That is a transaction for reporting purposes even though nothing changed hands.

2. What is excluded — and the boundary that matters

Article 2(5) lists what a transaction is not, and the first exclusion draws the most important boundary in the whole transaction-reporting landscape: securities financing transactions as defined in Article 3(11) of Regulation (EU) 2015/2365 are not MiFIR transactions.

They are reportable — but under the securities financing transactions regime, not under MiFIR. A firm that reports an SFT under MiFIR has both over-reported in one regime and, quite possibly, under-reported in the other. Getting the boundary right is a scoping decision taken once in the reporting logic, not a judgement made per trade.

3. The seven mechanisms Article 15 requires

This is the provision that turns transaction reporting from a file into a controlled process. The methods and arrangements by which reports are generated and submitted must include:

• Security and confidentiality systems for the data reported;
• mechanisms for authenticating the source of the report;
• precautionary measures enabling timely resumption of reporting after a failure of the reporting system;
• mechanisms for identifying errors and omissions within reports;
• mechanisms to avoid duplicate reports, including where a firm relies on a trading venue to report transactions executed through the venue’s systems under Article 26(7) of MiFIR;
• mechanisms ensuring a venue only submits for firms that chose to rely on it;
• mechanisms to avoid reporting where there is no obligation under Article 26(1).

Three of those seven are about not reporting: no duplicates, no reports for firms that did not delegate, and no reports where no obligation exists. Over-reporting is treated as a control failure on the same footing as under-reporting, which is not how most firms instinctively think about it.

4. How the pipeline is actually assembled

Facts: a firm executes on venue and off venue, uses a reporting mechanism for submission, and has some transactions reported on its behalf by a trading venue.

What the rules require of the design: a single decision layer that answers, per event, three questions in order — is this a transaction under Article 2; is it excluded under Article 2(5); and is it already being reported by someone else. Only events surviving all three become reports.

What the practitioner does: builds the duplicate-avoidance logic as a positive register of which flows are delegated to a venue, rather than as a downstream de-duplication step. De-duplicating after generation catches exact matches and misses near-matches; deciding upfront which flows the firm reports is deterministic and auditable.

The error-and-omission mechanism deserves the same treatment. A daily reconciliation between the population of executed transactions and the population of accepted reports — in both directions — is what satisfies that limb, and it is the control that detects a scope error before the regulator’s own matching does.

5. The resumption requirement

Article 15(c) requires precautionary measures enabling timely resumption of reporting in the case of a failure of the reporting system. This is an availability obligation embedded in a reporting rule, and it is frequently overlooked because it has no field in the file.

In practice it means a documented contingency: what happens if the submission route is unavailable on a reporting day, who decides to invoke it, and how the backlog is cleared once service resumes — including how ordering and completeness are preserved across the gap. Firms that discover they have no such plan generally do so during the first outage.

FAQ

Related: MiFIR, EMIR and SFTR compared · ESMA’s report once plan · MiFIR reporting in France