MiFIR, EMIR and SFTR — where the boundaries fall
Three EU regimes collect transaction-level data, they overlap in places, and the boundaries between them are drawn by explicit exclusions rather than by intuition. Getting them wrong produces the two worst outcomes simultaneously: reporting something in the wrong regime, and therefore not reporting it in the right one. The good news is that the boundaries are written down.
1. What each regime captures
| Regime | Captures | Reported by |
|---|---|---|
| MiFIR transaction reporting | Acquisitions and disposals of financial instruments under Article 26 of Regulation (EU) No 600/2014 | Investment firms and trading venues, to the competent authority |
| EMIR | Derivative contracts — conclusion, modification and termination | Both counterparties, to a trade repository |
| SFTR | Securities financing transactions under Regulation (EU) 2015/2365 | Both counterparties, to a trade repository |
2. The MiFIR–SFTR boundary is explicit
This one is settled in the text rather than left to interpretation. Article 2(5) of Delegated Regulation (EU) 2017/590 provides that a transaction for MiFIR Article 26 purposes does not include securities financing transactions as defined in Article 3(11) of Regulation (EU) 2015/2365.
So the same economic activity cannot be a MiFIR transaction and an SFT. The scoping decision is binary and belongs in the reporting logic once, not in per-trade judgement — and a firm reporting SFTs under MiFIR is simultaneously over-reporting in one regime and under-reporting in the other.
3. Where an instrument can hit two regimes
Derivatives are the genuine overlap. A derivative traded on a venue can generate a MiFIR transaction report and an EMIR report, because the two regimes are asking different questions about the same event: MiFIR asks who acquired or disposed of what, for market-abuse surveillance; EMIR asks what contracts are outstanding, for systemic-risk monitoring.
That is not duplication in the sense Article 15 of RTS 22 prohibits — the duplicate-avoidance mechanisms there are about not reporting the same thing twice within MiFIR. Across regimes, dual reporting is the design.
What that means practically is that the reporting decision layer has to be multi-valued: for each event, which of the three regimes apply, independently. A pipeline that routes each event to exactly one regime will systematically under-report derivatives.
4. Three differences that change the build
- Single-sided versus dual-sided. MiFIR is reported by the executing firm. EMIR and SFTR are reported by both counterparties, which means your report is matched against someone else’s — and a mismatch is a finding even where your own data is right.
- Lifecycle. MiFIR reports a transaction event. EMIR and SFTR track a contract over its life, with modification and termination events. That is a state-management problem rather than an event-emission problem, and it needs a persistent record keyed to a trade identifier.
- Identifiers. Dual-sided reporting depends on both parties using the same identifiers for the same trade. Identifier discipline is therefore a shared-reference-data problem, not an internal one.
5. Where this is heading
The fragmentation is recognised. ESMA’s report once work proposes a single integrated template to replace the three regimes’ separate reporting, with near-term measures ahead of a longer horizon.
That has a planning consequence today: architectural decisions taken now should assume convergence. Building three independent reporting stacks optimised separately is the pattern that ages worst; building one event model that can be rendered into three regimes is the pattern that survives a merge — because a merged template will be a fourth rendering of the same events, not a fourth pipeline.
FAQ
Can one trade be reported under two regimes?
Yes — a venue-traded derivative can generate both a MiFIR transaction report and an EMIR report, because the regimes ask different questions about the same event.
Can an SFT be a MiFIR transaction?
No. RTS 22 expressly excludes securities financing transactions as defined in Article 3(11) of Regulation (EU) 2015/2365 from the MiFIR meaning of transaction.
What is the main build difference?
MiFIR is single-sided and event-based; EMIR and SFTR are dual-sided and lifecycle-based, which introduces matching against a counterparty’s report and a persistent contract state.
Should we build three separate pipelines?
No — one event model rendered into three regimes ages far better, particularly given the direction of travel towards an integrated template.
6. Scoping it once, properly
The practical deliverable is a routing matrix: for each event type the firm generates, which of the three regimes apply, with the provision that decides each answer. It is a small document and it settles arguments that otherwise recur every time a new instrument or venue is added.
Two columns make it durable. A reason column, citing the provision — so a future reader can see that SFTs are outside MiFIR because RTS 22 Article 2(5) says so, rather than because someone decided it. And a reviewed-on column, because the boundaries move: instruments get reclassified, venue arrangements change, and a matrix with no review date quietly becomes folklore.
Related: How a MiFIR report is built · ESMA’s report once plan · MiFIR reporting in Italy
