A client in Bucharest opens 0.4 lots of EURUSD at 09:14:22. Within the next thirty hours that single click has to appear in a structured file at the national competent authority under MiFIR, and in a second file at a trade repository under EMIR, with an identifier that the client's own counterparty record can be matched against. The trade took a hundred milliseconds. The paperwork behind it runs for years.
Two regimes asking two different questions
MiFIR transaction reporting exists to detect market abuse. The regulator wants to know who decided, who executed, in what capacity, at what price and at what microsecond, so that patterns of insider dealing or manipulation can be reconstructed after the fact. The obligation sits in Article 26 of MiFIR and applies to investment firms executing transactions in reportable instruments. It is a one sided report: the firm files, the client does not.
EMIR asks a systemic question instead. After 2008 supervisors wanted to know the size and shape of the derivatives book across the market, so both counterparties to a derivative contract report it to a registered trade repository, and they keep reporting it through its life with valuations and collateral updates. It is two sided by design, and the two sides are expected to agree.
A contract for difference is a derivative and it is also a financial instrument executed by an investment firm. That is why the same EURUSD position generates work under both regimes at once. Firms new to the EU perimeter frequently budget for one and discover the second during the authorisation interview. The wider obligations that sit around this are set out in the guide to MiFID II.
What has to be in the file
The content of a MiFIR transaction report is fixed by technical standards, and the field list runs past sixty items per transaction. Most are mechanical: instrument identifier, quantity, price, venue, currency, timestamp to the required precision. The ones that cause trouble are the identity fields.
Legal entity clients must be identified by a Legal Entity Identifier, and the code has to be current. The industry shorthand for this is blunt: no LEI, no trade. If a corporate client lets its LEI lapse, the firm cannot lawfully report the transaction it just executed, which means it should not have executed it. Natural persons are identified by a national identifier built to a per country priority order, and for many countries that is a concatenation of date of birth and characters from the legal name. Nicknames, transliterated surnames and a passport typed in from a blurred scan all fail here.
Then there are the fields describing the decision itself. Who inside the firm made the investment decision, who executed it, whether the firm dealt on own account or matched principal or in any other capacity, whether a short sale was involved, whether the order was transmitted from another firm. These describe the firm's own conduct and they connect directly to best execution obligations, because the same timestamps prove what price was available when the order arrived.
Underneath all of it sits clock synchronisation. Reporting to the microsecond means nothing if the trading server drifts, so the standards impose a divergence limit from coordinated universal time and require firms to be able to evidence it. That is an infrastructure requirement, not a compliance memo.
EMIR, and the reconciliation nobody plans for
The EMIR file goes to a trade repository rather than the regulator directly, and it carries a Unique Trade Identifier that both counterparties must use for the same contract. The repository attempts to pair the two submissions. When the broker says the notional is 40,000 EUR and the counterparty says 40,000 USD, the trade sits unpaired, and unpaired volumes are visible to supervisors as a data quality metric attached to the firm's name.
The 2024 refit of the EMIR standards moved reporting to a common ISO 20022 XML format, added product identifiers and expanded the field set, which retired a lot of homemade CSV pipelines. Firms with retail clients also inherit delegated reporting: where the client is a small non financial counterparty, the financial counterparty reports for both sides and carries responsibility for the accuracy of the client's leg. Retail clients under MiFID are not reporting anything themselves, so in practice the broker owns the data.
The parts that actually break
- Rejections nobody reads. The reporting mechanism returns a rejection file. If no person owns that file every morning, a mapping error can run unnoticed for months and then requires back reporting of the entire period.
- Onboarding data collected for the wrong purpose. A KYC process built to satisfy anti money laundering checks often stores a scanned document rather than the structured national identifier the report needs. The two requirements overlap but they are not the same, as the guide to KYC verification levels sets out.
- Corrections treated as edits. A wrong report is cancelled and replaced, not quietly overwritten in the database. Regulators expect the audit trail to show both.
- Instrument reference data. Reports are validated against the reference data the venues themselves publish. A symbol traded on your platform that does not resolve to a valid instrument identifier will be rejected regardless of how correct everything else is.
- Group structures. An offshore entity executing for EU clients through an EU branch does not escape the obligation. Where the perimeter falls is a legal question worth paying for before launch, not after.
Reporting is a data problem long before it is a legal one. The identifiers, timestamps and capacity flags all originate in the trading platform and the client record, so the shape of that record decides whether reporting is a nightly job or a permanent firefight. A broker CRM that stores structured identifiers and an immutable event log makes the file easy to build; one that stores free text does not.
Build the plumbing before the licence arrives
Firms preparing an application in Cyprus, Malta or Ireland tend to treat reporting as a post authorisation task and pick a reporting mechanism in month nine. The better order is the reverse. Decide who reports and through which channel, get the LEI for the entity, confirm that the platform can emit the required timestamps, and run test files against the mechanism's validation before the business plan is filed. The regulator reviewing a CySEC application will ask how the firm intends to meet Article 26, and an answer naming the mechanism and the data flow is worth more than a paragraph of intent.
None of this is optional at scale, and none of it is glamorous. It is also the part of the operation that supervisors can measure precisely, from the outside, without visiting the office.
"Nobody fails a supervisory review because they misread the regulation. They fail because a date of birth was typed two different ways in two systems, and the rejection file sat unopened for a year."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- MiFIR reporting is one sided and aimed at market abuse; EMIR reporting is two sided and aimed at systemic exposure, and a CFD trade usually triggers both.
- Identity fields cause most failures: a lapsed LEI blocks a corporate trade, and national identifiers must follow a fixed per country format.
- Rejection files need a named owner every morning, because unnoticed mapping errors turn into months of back reporting.
- Choose the reporting channel and test the data flow during the licence application, not after the first client trades.
Frequently Asked Questions
Who has to submit MiFIR transaction reports?
Investment firms authorised in the EU that execute transactions in reportable financial instruments file transaction reports with their competent authority. A firm may submit directly, through an approved reporting mechanism, or through the trading venue whose system it used. Firms authorised outside the EU are outside the MiFIR obligation, but their EU branches and any EU entity in the group are usually caught.
What is the difference between MiFIR transaction reporting and EMIR trade reporting?
MiFIR transaction reporting is a market abuse surveillance tool. One side, the investment firm, sends a report to its regulator describing an executed transaction and the people behind the decision. EMIR reporting is a systemic risk tool. Both counterparties to a derivative send reports to a trade repository, covering the life of the contract including valuations and collateral. A CFD broker in the EU normally has to do both for the same trade.
How quickly do transaction reports have to be filed?
The MiFIR deadline is the close of the working day following execution, commonly written as T+1, and EMIR reporting works to the same next working day standard. Firms that batch reports overnight therefore have a single window to detect and correct rejections. Errors found later still have to be corrected and resubmitted, and repeated late or inaccurate filing is treated by regulators as a supervisory issue in its own right.