Resource center · Structured Data & Messaging

EMIR reporting: what a trade repository submission contains.

EMIR is dual-sided reporting into a repository that then reconciles your report against your counterparty’s. That single design choice explains almost every operational difficulty the framework creates.

Guide EMIR · European Union and United Kingdom · derivative trade reporting REGREP Regulatory Team · Reviewed 2026-05-14

The shape of the obligation

Article 9 of Regulation (EU) No 648/2012 requires counterparties to report the details of any derivative contract they have concluded, and of any modification or termination of it, to a registered trade repository. The revised technical standards — Delegated Regulation (EU) 2022/1855 for the content and Implementing Regulation (EU) 2022/1860 for the standards, formats and methods — replaced the earlier ones and moved the framework onto internationally agreed data elements.

Two features distinguish EMIR from most reporting. It is dual-sided: both counterparties report the same trade, and the repository compares the two. And it is event-driven: the population is not a period-end snapshot but every conclusion, modification and termination, reported by the following working day.

Who reports, and for whom

Both counterparties to a derivative contract carry the obligation, but responsibility can sit with one of them. Where a financial counterparty faces a non-financial counterparty that is under the clearing thresholds, the financial counterparty is solely responsible and legally liable for reporting on behalf of both. There is also a reporting exemption for intragroup derivatives in defined circumstances involving such a non-financial counterparty.

Delegation is not transfer of liability in general. Outside the case where the regulation itself assigns responsibility, a counterparty that delegates reporting to a broker, an administrator or its own group entity remains answerable for what is reported. The delegation arrangement should say what the delegate reports, from what data, and how errors are notified back.

The three tables

Report content
Table	Carries
Counterparty data	Who the parties are and what they are: the reporting counterparty, the other counterparty, the entity responsible for reporting, the report submitting entity, the broker, the clearing member and the beneficiary, together with corporate sector, nature and clearing threshold status.
Common trade data	What the contract is: product identification, contract type and asset class, the economic terms, the venue, clearing status and central counterparty, valuation, and the dates that bound the contract’s life.
Margin data	Collateral posted and received, initial and variation margin, and excess collateral — reported separately from the trade itself.

The margin table is the one most often underestimated. It draws on the collateral management function rather than the trading systems, which means a second data source, a second owner and a second reconciliation.

The identifiers that hold it together

Unique transaction identifier. The single value that lets a repository pair your report with your counterparty’s. It follows the international standard and must be agreed between the parties, or generated by whichever of them the tie-breaker rules designate.
Unique product identifier. Identifies the product for over-the-counter derivatives, replacing bespoke product taxonomies with a common reference.
Legal entity identifier. Identifies every entity in the counterparty table. A lapsed identifier is a rejection, not a warning.
Report tracking number. Links the reports that relate to the same original transaction where it passes through several stages.

The unique transaction identifier is the one that decides whether an implementation succeeds. It has to be generated or received before the reporting deadline, shared with the counterparty, and stored so that every later lifecycle event quotes the same value. Firms that treat it as an output of the reporting process rather than an input to it spend the following year on reconciliation breaks.

Action types and the lifecycle

A contract is not reported once. It is reported as a sequence of events, each carrying an action type that says what the event does — a new trade, a modification of terms, a correction of previously reported data, a termination, an error to be nullified, a revival, a valuation update, or a position component. The event type and the action type are reported together so the repository can distinguish a genuine amendment from the repair of a mistake.

Two disciplines follow. Every event must quote the same unique transaction identifier as the original. And a correction is not a modification: reporting a data repair as a business event misstates the contract’s history, which is exactly what a supervisor reconstructing a market episode will be reading.

Pairing, matching and reconciliation

Because both sides report, the repository performs two steps. Pairing finds the two reports that describe the same trade, using the unique transaction identifier and the counterparty identifiers. Matching then compares the reported values field by field, within tolerances set out in the standards, and produces a reconciliation status.

A report can therefore be individually valid and still fail: accepted by the repository, paired with the counterparty’s, and mismatched on a dozen fields. Treating repository acceptance as the finish line is the most common reason a firm believes it is compliant while its reconciliation statistics say otherwise. The working measure is the proportion of reports paired and matched, not the proportion accepted.

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 on OTC derivatives, central counterparties and trade repositories (EMIR), Article 9EUR-Lex · Regulation · the reporting obligation
Commission Delegated Regulation (EU) 2022/1855 with regard to regulatory technical standards specifying the minimum details of the data to be reported to trade repositoriesEUR-Lex · Delegated Regulation · report content and the three tables
Commission Implementing Regulation (EU) 2022/1860 with regard to the standards, formats, frequency and methods and arrangements for reportingEUR-Lex · Implementing Regulation · formats and the unique transaction identifier standard
European Securities and Markets Authority — Guidelines for reporting under EMIR, with the accompanying validation rules and reporting instructionsESMA · the primary implementation reference · consult the current version

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

Obligation: Report the details of derivative contracts concluded, modified or terminated, to a registered trade repository.
Legal basis: Article 9 of Regulation (EU) No 648/2012, with the revised technical standards in Delegated Regulation (EU) 2022/1855 and Implementing Regulation (EU) 2022/1860.
Who: Both counterparties, with financial counterparties carrying the obligation for non-financial counterparties that fall under the clearing thresholds.
Structure: Three tables — counterparty data, common trade data and margin data.
Timing: By the working day following conclusion, modification or termination.