Skip to content
EMIRExample / Demo Content

EMIR

Derivatives reporting obligations in the EU: who reports, what is reported, and how submissions are validated and reconciled at trade repositories.

Last reviewed 1 Sep 2026

Jump to section (13)
  1. Overview
  2. Reporting Obligation
  3. Data Fields
  4. UTI
  5. UPI
  6. LEI
  7. Trade Repository
  8. Lifecycle Events
  9. Validation Rules
  10. Reconciliation
  11. Common Rejections
  12. Implementation Questions
  13. Regulatory Sources

Overview

EMIR introduced a requirement to report derivative contracts to registered trade repositories. The reporting framework was substantially revised under the REFIT programme, which expanded and restructured the reportable data and moved submissions to ISO 20022 XML.

This page is a navigational summary. Always read the underlying regulation, technical standards and guidelines for authoritative requirements.

Reporting Obligation

Counterparties to derivative contracts are subject to the reporting obligation, with specific provisions on which entity is responsible for reporting in certain cases and on delegation of reporting to a third party.

Delegating submission does not by itself transfer every responsibility; firms typically maintain oversight controls over delegated reports.

Data Fields

Reportable fields are organised into counterparty data, common data and specific sections such as margins and valuations. Field definitions, formats and allowable values are set out in the technical standards.

UTI

A Unique Transaction Identifier links both sides of a reported transaction. Guidance sets out which counterparty is responsible for generating the UTI and the expectation that it is shared in a timely way.

UPI

The Unique Product Identifier describes the product traded, using attributes defined by the UPI service provider's templates.

LEI

Counterparties and other entities in a report are identified using Legal Entity Identifiers. Validation typically checks both format and registration status.

Trade Repository

Trade repositories receive submissions, apply validation rules, return feedback to reporting parties, and perform inter-TR reconciliation.

Lifecycle Events

Changes to a reported derivative are reported using a combination of action type and event type, for example a modification following a partial termination. Correct sequencing matters because validation can depend on the previously reported state.

Validation Rules

ESMA publishes validation rules that trade repositories apply to submissions. Rules include format checks, conditional presence checks and consistency checks with previously reported data.

Reconciliation

Where both counterparties report, trade repositories attempt to pair and match the two sides, and reconciliation tolerances apply to specified fields.

Common Rejections

Practitioner-reported themes include missing or inconsistent UTIs on lifecycle events, action types that do not fit the trade's reported state, and invalid or lapsed LEIs. These are community observations, not an official list.

No citations — this section summarises community practice and is not a regulatory statement.

Implementation Questions

Open implementation questions from the community are linked from the discussions tagged EMIR. Reviewed answers are promoted into this section over time.

No citations — this section summarises community practice and is not a regulatory statement.

Regulatory Sources

Primary documents referenced on this page are listed below with their publisher and link to the official source.