Resource center · Structured Data & Messaging

EMIR and MiFIR: why they are not one project.

They are named together, they cover overlapping trades, and they are routinely scoped as one programme. That decision is the single most reliable predictor of a remediation exercise eighteen months later.

Q & A EMIR · MiFIR · European Union and United Kingdom REGREP Regulatory Team · Reviewed 2026-08-04

The pairing test

A useful test for whether two reporting obligations can be run as one: do they share the same population, the same filing destination and the same dataset? Frameworks that pass all three can be built once. CRS and the crypto-asset framework pass it comfortably. EMIR and MiFIR fail all three.

Population. EMIR captures derivative contracts and their whole life. MiFIR captures executed transactions in reportable financial instruments, most of which are not derivatives, and ignores the contract’s subsequent life entirely.
Destination. EMIR goes to a registered trade repository. MiFIR goes to a competent authority, directly or through an approved reporting mechanism.
Dataset. EMIR reports contract economics, valuation and collateral. MiFIR reports execution details and attribution to the person or algorithm responsible.

Compared, dimension by dimension

EMIR and MiFIR compared
Dimension	EMIR	MiFIR
Purpose	Systemic risk monitoring	Market abuse detection and market supervision
Sidedness	Dual-sided, with pairing and matching between counterparties	Single-sided — no counterparty report to reconcile against
Unit	The contract, across its whole life	The executed transaction, at a point
Lifecycle	Modifications, valuations, collateral and terminations all reported	Only cancellations and amendments of the report itself
Key identifier	Unique transaction identifier, agreed with the counterparty	Instrument identifier from reference data, plus person and algorithm identifiers
Reporting party	Both counterparties, with responsibility assigned in defined cases	The investment firm, with the chain deciding which one
Success measure	Proportion paired and matched	Completeness and accuracy against the authority’s own checks
Failure mode	Accepted but unmatched — invisible without reconciliation reporting	Missing, duplicated or misattributed reports — usually a scope or chain error

The case for one programme is not baseless — it is just narrower than it looks. What shares well:

Entity reference data. Legal entity identifiers, their currency and their lifecycle serve both, and are worth building once.
Instrument reference data. Both need it, from the same external sources, with the same staleness problem.
The trade capture feed. One extraction from the front office can supply both, provided it carries the union of the fields rather than the intersection.
Control framework. Completeness and accuracy testing, breach logging and governance can be one discipline over two streams.

What does not share: scope logic, field mapping, identifier generation, submission, exception handling and reconciliation. That is most of the build.

What combining them actually costs

The failure is rarely dramatic. It looks like a single scope engine with a growing set of framework-specific exceptions, a shared field model where half the fields are populated for one framework and null for the other, and an exception queue where two unrelated classes of break are triaged by one team that understands one of them well. The cost surfaces as reconciliation statistics that do not improve, and as a remediation programme that has to separate the two before it can fix either.

Scope them together, build them separately. One assessment of which entities and which flows are caught by each framework is genuinely efficient. One codebase for both is not.

Official sources

Primary instruments only. Each is named in full so the reference remains traceable even if a link moves.

Regulation (EU) No 648/2012 (EMIR), Article 9EUR-Lex · Regulation · the trade reporting obligation
Regulation (EU) No 600/2014 (MiFIR), Article 26EUR-Lex · Regulation · the transaction reporting obligation
Commission Delegated Regulation (EU) 2022/1855 and Commission Delegated Regulation (EU) 2017/590EUR-Lex · the two technical standards that define the respective datasets

Questions, answered

A derivative trade is caught by both. Do we report it twice?

Yes, to two different recipients, with two different datasets and two different deadlines. The trade repository receives the contract and its life; the competent authority receives the execution and its attribution. Neither discharges the other.

Can one vendor or one platform cover both?

It can, and several do. The question to ask is whether the two are separate pipelines inside it or one pipeline with conditional logic. The first is fine; the second accumulates exceptions until it needs rebuilding.

We already report EMIR. How much of that helps with MiFIR?

The entity and instrument reference data, and the trade capture feed if it carries enough fields. The scope logic, the mapping and the exception handling do not carry across, because the two frameworks are asking different questions of the same trade.

Which one should we fix first if both are weak?

Usually MiFIR, because its failure mode is silent gaps that grow, whereas EMIR failures surface continuously as reconciliation breaks. But the honest answer depends on which produces the larger unreported population, and that is worth measuring before choosing.

REGREP is an independent software provider. This record explains a reporting framework in plain language and is not legal, tax or regulatory advice. Confirm scope, thresholds and submission dates with your competent authority before you file.

At a glance

Shared: Some of the same derivative trades, and some of the same source systems.
Not shared: Population, destination, dataset, timing model, identifier set and failure mode.
EMIR asks: What contracts exist, who holds them and what collateral supports them — systemic risk.
MiFIR asks: Who decided, who executed and on what terms — market abuse detection.
Practical answer: Two implementations sharing an upstream data layer, not one implementation with a switch.