EMIR Reporting Requirements - What You File, When, and How to Get It Right

Last updated: March 2026

A single lapsed LEI can cascade into hundreds of rejected EMIR reports overnight. I have watched a team spend three days reconstructing and resubmitting trades that should have filed cleanly, all because one counterparty’s LEI renewal slipped through the cracks. That is the reality of EMIR reporting: the regulation itself is logical enough, but the operational details will find every gap in your process.

EMIR reporting applies to every entity that enters into a derivative contract in the EU. Banks, asset managers, insurance companies, pension funds, and corporates with material derivatives exposure all fall within scope. Since the EMIR Refit changes went live on 29 April 2024, the reporting framework is more structured and more demanding. The field count nearly tripled. The format shifted to ISO 20022 XML. And the legal liability for reporting NFC- trades moved squarely onto the financial counterparty.

This guide covers what compliance and operations teams need to know in practice: who reports, what goes into the report, how lifecycle events work, what the Refit actually changed, and where the process most commonly breaks down.

Related reading: MiFIR Transaction Reporting

Legal Basis

EMIR is Regulation (EU) No 648/2012 on OTC derivatives, central counterparties, and trade repositories. It entered into force in August 2012. The reporting obligation under Article 9 has applied since February 2014.

The regulation was amended by EMIR Refit, formally Regulation (EU) 2019/834, which simplified certain requirements for smaller counterparties while substantially tightening the reporting framework. The operational overhaul arrived on 29 April 2024, when revised reporting technical standards under Commission Delegated Regulation (EU) 2022/1855 (RTS on reporting) and Commission Implementing Regulation (EU) 2022/1860 (ITS on reporting) went live.

ESMA published extensive implementation guidance in its final report on Guidelines for Reporting under EMIR (reference ESMA74-362-2281), which is now the primary reference document for anyone building or validating an EMIR reporting process. In Luxembourg, the CSSF transposed these guidelines and added local supervisory expectations through Circular CSSF 23/846.

Who Must Report

Both counterparties to a derivative contract must report under Article 9(1). Every derivative, OTC or exchange-traded, must be reported to a registered or recognised trade repository. The reporting obligation is bilateral: each side reports independently, with its own submission to its chosen TR.

Financial Counterparties (FC)

Financial counterparties include credit institutions, investment firms, insurance and reinsurance undertakings, UCITS and their management companies, AIFs and their managers, IORPs, and CCPs. If your entity holds any authorisation under the relevant EU financial services directives, you are an FC for EMIR purposes.

FCs bear the heaviest reporting burden. They report all their own derivatives, and under the Refit rules they are also responsible and legally liable for reporting on behalf of NFC- counterparties. That second obligation caught several firms off guard when it went live.

Non-Financial Counterparties Above the Clearing Threshold (NFC+)

A non-financial counterparty that exceeds any of the clearing thresholds becomes an NFC+. The thresholds are calculated on a rolling 30-business-day average of gross notional positions in OTC derivatives that do not objectively reduce risk. The values set under Article 10(4)(b) and the related delegated acts are: EUR 1 billion for credit derivatives, EUR 1 billion for equity derivatives, EUR 3 billion for interest rate derivatives, EUR 3 billion for FX derivatives, and EUR 4 billion for commodity and other derivatives.

NFC+ entities carry reporting obligations equivalent to FCs. They report their own trades and cannot delegate the legal liability for accuracy. They can outsource the operational act of submission to a third party, but the legal responsibility stays with them.

Non-Financial Counterparties Below the Clearing Threshold (NFC-)

EMIR Refit made its biggest practical change here. Before the Refit, NFC- entities still had to report their own derivatives. After the Refit, the FC counterparty to an NFC- trade becomes responsible and legally liable for reporting on behalf of both sides.

The NFC- is not entirely off the hook. The regulation requires it to provide the FC with the data needed to file the report, and to verify the accuracy of the submission where it has access. But the filing burden shifts to the FC. In practice, most NFC- entities now rely entirely on their bank or broker to handle the submission.

I find the confusion persists most at this point. NFC- entities sometimes assume they have zero obligations after the Refit. That is not correct. They must provide data, verify reports, and critically, they must monitor whether they cross the clearing thresholds. Crossing a threshold changes an NFC- to an NFC+ overnight, and that triggers full reporting obligations.

What Gets Reported

EMIR reports are structured across three tables defined in the ITS on reporting. Not every field applies to every trade, but the total reportable field set post-Refit is approximately 203 fields.

Table 1: Counterparty Data

Table 1 covers the identification of both counterparties. It includes LEIs, corporate sector classification, nature of the counterparty (FC or NFC), clearing threshold status, the entity responsible for reporting, the report submitting entity, and broker or clearing member details where relevant. Approximately 27 fields.

The LEI is the gating requirement. Every counterparty must have a valid, renewed LEI at the time of submission. Lapsed LEIs trigger immediate rejections. I have seen firms waste entire mornings troubleshooting rejections that turned out to be nothing more than an expired LEI on the other side of the trade. Build an automated LEI expiry tracker into your process. The renewal cost is trivial. The cost of a rejection cascade is not.

Table 2: Common Data

Table 2 is the core of the report. It contains the Unique Transaction Identifier (UTI), the product identifier (using the UPI from the Derivatives Service Bureau post-Refit), notional amounts, currencies, settlement and maturity dates, price, and contract type. Approximately 129 fields, though many are conditional on the derivative type.

The UTI generation and sharing process is one of the most operationally complex parts of EMIR reporting. Under the Refit rules, the responsibility for generating the UTI follows a defined waterfall: CCPs generate for cleared trades. The FC generates when trading with an NFC. For FC-to-FC uncleared trades, the seller generates. If none of these apply, the counterparties agree bilaterally. Most firms pre-agree UTI generation responsibilities in their ISDA documentation or operational onboarding.

Table 3: Margin and Collateral Data

Table 3 covers collateralisation status, initial margin posted and received, variation margin posted and received, and excess collateral. It applies to both cleared and uncleared derivatives, though the detail level differs.

Margin reporting has been a consistent source of reconciliation breaks since EMIR reporting began. The timing of margin snapshots, the treatment of disputed margin, and currency conversion conventions all create opportunities for the two counterparties to report different numbers for the same trade. Most teams adopt end-of-day margin snapshots aligned to a single cut-off time to minimise discrepancies.

Lifecycle Events and Action Types

EMIR reporting is not a one-time filing. Every change to a derivative over its lifetime must be reported. The Refit standardised the action types that describe these changes.

Action Types Under the Refit

New: initial report of a derivative. Modify: a genuine economic change to the trade terms, such as a notional amendment or rate change. Correct: fix of a previously submitted report that contained errors. Terminate: early termination of a trade. Error: flagging a previously submitted report as submitted in error. Revive: reopening of a trade that was previously terminated in error. Margin update: change to collateral and margin data without affecting trade economics. Valuation update: update to the mark-to-market or mark-to-model valuation.

The distinction between Modify and Correct trips up more teams than any other reporting decision. A Modify reflects a real economic change. A Correct fixes a data entry mistake. If the notional changed because the trade was restructured, that is a Modify. If someone fat-fingered the original notional, that is a Correct. The trade repository tracks these differently, and using the wrong action type creates downstream reconciliation problems that compound over time.

Valuation Reporting

FCs and NFC+ entities must report mark-to-market or mark-to-model valuations. The largest firms report daily. Smaller FCs may report less frequently depending on their NCA’s expectations. NFC- entities are exempt from valuation reporting.

In practice, daily valuation reporting is the norm for any firm with a material derivatives book. Each counterparty reports its own valuation, not the other side’s number. This means two FCs will naturally file slightly different valuations for the same trade. That is expected, but the tolerance thresholds for reconciliation were tightened under the Refit, so what used to be acceptable drift may now trigger a break.

Trade Repositories

Reports go to a trade repository registered with ESMA under Article 55 of EMIR, or a third-country TR recognised under Article 77. As of 2026, the EU-registered TRs include DTCC Derivatives Repository (DDRL), Regis-TR, UnaVista (LSEG), KDPW, and ICE Trade Vault Europe.

The two sides of a trade do not need to use the same TR. ESMA aggregates data across all TRs for supervisory purposes. Most firms select one or two TRs and route by asset class or clearing venue.

Since the April 2024 go-live, the submission format is ISO 20022 XML exclusively. The old CSV and proprietary formats that individual TRs accepted previously are gone. Every reporting firm had to rebuild or significantly modify their reporting pipeline for the transition. The XML schema is more granular, which improves data quality but also means more fields to populate and more validation rules to satisfy before a report is accepted.

The EMIR Refit: What Actually Changed

The Refit (go-live 29 April 2024) changed the reporting regime in several material ways. These are the changes that hit operations teams hardest.

ISO 20022 XML Format

All reports now use the ISO 20022 XML schema. This replaced the varied formats that TRs previously accepted. The shift forced a complete rebuild of outbound report generation for firms that had been using legacy CSV or flat-file submissions. The XML schema is more structured and more machine-readable, but it also catches errors that the old formats silently accepted.

Expanded Field Set

The reportable fields expanded from approximately 85 to approximately 203. Many are conditional, but the validation logic became substantially more complex. New fields include the Unique Product Identifier (UPI), the event date, and the prior UTI for linked trades. Each of these required changes to upstream trade capture systems, not just the reporting layer.

Unique Product Identifier (UPI)

Every OTC derivative must now carry a UPI assigned by the Derivatives Service Bureau (DSB). The UPI replaced the freetext product taxonomy used previously. Firms had to map their internal product classifications to the DSB taxonomy and build a DSB lookup into the reporting pipeline. For standard products the lookup is straightforward. For bespoke structures, you may need to request a new UPI from the DSB, and that adds a step to the trade booking process.

Delegated Reporting for NFC-

FCs became responsible and legally liable for reporting on behalf of NFC- counterparties. This was a structural shift. Banks and investment firms had to build processes to collect NFC- data, generate reports on their behalf, and manage the accuracy of submissions they did not previously own.

Stricter Reconciliation

ESMA tightened the reconciliation requirements between TRs. More fields are subject to mandatory matching between the two sides of a trade, and the tolerance thresholds for numerical fields narrowed. Reconciliation break rates spiked in the months following the go-live as firms adjusted to the stricter regime. Most have stabilised by now, but margin data and valuation breaks remain persistent problem areas across the industry.

Deadlines and Reporting Timelines

Derivatives must be reported by T+1: the business day following execution, clearing, or a lifecycle event. This applies to new trades, modifications, terminations, and all other action types.

Valuation reports follow the same T+1 timeline for firms that report daily. For firms with less frequent valuation reporting, the NCA specifies the expected cadence.

Margin and collateral data must be reported by T+1 following the collateral exchange or margin call settlement.

For the Refit transition, ESMA allowed a 180-day window from 29 April 2024 for firms to re-report their outstanding stock of trades in the new format. Firms with thousands of outstanding derivatives treated this as a dedicated migration project, running parallel reporting in old and new formats, and using the window to clean up legacy data quality issues.

In practice, the T+1 deadline is tight for complex OTC trades where confirmations may not finalise until T+2 or later. Most teams file a preliminary report at T+1 with the best available data, then submit a Correct action type once the trade is fully confirmed. This approach is standard practice and preferable to a late submission.

Common Pain Points

UTI Sharing

Agreeing on who generates the UTI and communicating it to the other side before the T+1 deadline remains one of the biggest operational headaches. The waterfall logic is clear in the regulation, but implementing it across hundreds of counterparty relationships is a different matter. Some firms use bilateral agreements. Others rely on platform-level UTI generation via a CCP or trading venue. Many default to a generate-and-correct approach: each side submits with its own UTI and reconciles after.

Most large firms have automated UTI generation and sharing via SWIFT or proprietary messaging. Smaller firms typically rely on their dealer to provide the UTI.

LEI Management

A lapsed LEI causes immediate rejection. The counterparty’s LEI must be valid at the time of submission. Firms with large counterparty books run automated LEI validation checks before report submission. Some build this into their onboarding process as well, flagging counterparties whose LEIs are approaching expiry.

Reconciliation Breaks

Post-Refit reconciliation is stricter, and break rates are higher than under the old regime. The most common categories: different UTIs because one or both sides submitted before the shared UTI was agreed, different notional amounts due to rounding or currency conversion, different valuations from each side using its own model, and mismatched action types where one side filed a Modify while the other filed a Correct for the same event.

In practice, most compliance teams run a daily reconciliation dashboard pulling break data from their TR’s portal. Breaks are triaged by severity. UTI mismatches and missing reports get priority. Minor valuation differences are addressed in batches.

Multi-Jurisdiction Complexity

Firms operating across borders face overlapping reporting regimes. A derivative between an EU FC and a UK counterparty may need to be reported under both EU EMIR and UK EMIR (the onshored version). The field sets are similar but not identical. The TRs are separate. Managing dual reporting without duplication or gaps requires careful routing logic. I have seen teams build jurisdiction-specific report generators that share a common data layer but apply different field maps and validation rules per regime.

Luxembourg-Specific Considerations

The CSSF is the national competent authority for EMIR in Luxembourg. Circular CSSF 23/846 implements ESMA’s reporting guidelines and adds local supervisory expectations.

Luxembourg-based fund managers need particular attention to counterparty identification. When a management company or AIFM enters into a derivative on behalf of a fund, the fund itself (the UCITS or AIF) is the counterparty for classification purposes. The fund’s LEI goes in the counterparty field. The management company’s LEI appears in the entity responsible for reporting field or the report submitting entity field. Mixing these up is one of the more common errors I see in Luxembourg filings, and it creates reconciliation breaks with the counterparty on the other side who correctly identifies the fund.

The CSSF expects firms to maintain documented EMIR reporting procedures, to demonstrate accuracy and completeness on request, and to have remediation plans for known breaks. Post-Refit, the CSSF has been more active in following up on data quality issues flagged by ESMA or the TRs.

Penalties and Enforcement

EMIR Article 12 gives NCAs the power to impose administrative fines for reporting failures. In practice, enforcement has focused on systematic failures rather than individual field errors. A pattern of late reporting, persistent reconciliation breaks across an entire book, or missing reports will attract supervisory attention. A single misreported field on an otherwise clean book will not.

ESMA publishes annual data quality reports identifying systemic issues. Appearing in the outlier population on any metric typically leads to a follow-up from your NCA. In Luxembourg, the CSSF has issued individual letters to firms with persistent data quality shortcomings identified through ESMA’s cross-TR reconciliation exercises.

Beyond direct penalties, the reputational and operational cost of poor EMIR reporting is significant. Firms with known data quality problems face additional scrutiny on every other regulatory filing. Counterparties may question the reliability of your operational processes. And internal audit will eventually add EMIR reporting to its scope if it has not already.

Frequently Asked Questions

Do intragroup derivatives need to be reported?

Yes, unless both counterparties have obtained an intragroup exemption under Article 9(1) of EMIR. Both sides report until the exemption is formally granted. The derivative should be flagged as intragroup in field 2.37. In practice, many groups simply report all intragroup trades rather than manage the exemption process, because maintaining the exemption documentation carries its own operational cost.

Are trades between two desks of the same legal entity reportable?

No. Derivatives within the same legal entity (e.g., between two desks or two branches) are not reportable under EMIR because there are no two counterparties. The only exception is when a CCP temporarily assumes both sides of outstanding contracts following a clearing member default.

Who generates the UTI for cleared trades?

The CCP generates the UTI. For uncleared OTC trades between an FC and an NFC, the FC generates. For FC-to-FC uncleared trades, the seller generates. If none of these apply, the counterparties agree bilaterally. This waterfall is defined in the RTS on reporting.

What if we cannot obtain the UTI from our counterparty before T+1?

Submit the report with your own internally generated UTI by the T+1 deadline. Then, once the agreed UTI is available, submit a Correct to update the field. This is accepted practice. Most TRs and NCAs recognise that UTI sharing is an industry-wide timing challenge and prefer a timely report with a temporary UTI over a late submission.

Does an NFC- entity have any remaining obligations after the Refit?

Yes. The NFC- must provide its FC counterparty with the data needed to report on its behalf, and must verify accuracy where it has access to the submission. The NFC- is also responsible for its own classification. It must monitor whether it crosses any clearing threshold, because crossing a threshold changes it from NFC- to NFC+ and triggers full reporting obligations.

How do we handle the UPI lookup for bespoke OTC derivatives?

The Derivatives Service Bureau (DSB) assigns UPIs. For standard products, the UPI can be retrieved from the DSB database by product attributes. For genuinely bespoke structures, you may need to request a new UPI. Build the DSB lookup into your trade capture or reporting pipeline so it happens automatically. Manual lookups do not scale once your volume exceeds a handful of trades per day.

What is the relationship between EMIR reporting and MiFIR transaction reporting?

They are separate obligations with different scopes. MiFIR applies to investment firms executing transactions in financial instruments and is submitted to the NCA. EMIR applies to counterparties entering into derivative contracts and is submitted to trade repositories. A single derivative trade can trigger both an EMIR report and a MiFIR report, filed to different destinations with different field sets. One does not replace the other.

Can we delegate the operational reporting to a third party?

Yes. The act of submitting reports can be delegated to a bank, reporting hub, or vendor. But the counterparty or entity responsible for reporting retains legal liability for accuracy and completeness. Delegation does not transfer legal responsibility. Make sure your delegation agreement specifies data quality standards, error handling procedures, and breach notification timelines.

MiFIR Transaction Reporting – Covers the parallel transaction reporting obligation under MiFIR, including scope, field requirements, and how it differs from EMIR.
COREP Reporting Explained – A guide to prudential reporting for banks and investment firms, relevant for understanding the broader regulatory reporting ecosystem.
FINREP Reporting Explained – Financial reporting requirements that complement prudential and transaction reporting obligations.
COREP Reporting Errors – Common mistakes in regulatory reporting and how to avoid them, with lessons applicable to EMIR filings.
AML Reporting in Luxembourg – Luxembourg-specific reporting obligations that firms with EMIR exposure often also need to manage.

Key Takeaways

Both counterparties must report every derivative to a trade repository by T+1. Post-Refit, FCs are responsible and legally liable for reporting on behalf of NFC- counterparties.
Counterparty classification (FC, NFC+, NFC-) determines the reporting obligation and legal liability. NFC- entities retain data provision, verification, and threshold monitoring duties.
The April 2024 Refit moved all reporting to ISO 20022 XML, expanded the field count from roughly 85 to 203, and introduced the UPI requirement via the Derivatives Service Bureau.
UTI generation follows a defined waterfall. Automate UTI sharing in your onboarding process to avoid T+1 timing failures and reconciliation breaks.
Confusing the Modify and Correct action types is one of the most common causes of reconciliation issues. Modify reflects an economic change. Correct fixes a reporting error.
LEI validity is a gating requirement for report acceptance. Automate expiry monitoring for your entire counterparty book.
Luxembourg fund managers must correctly distinguish between the fund (counterparty) and the management company (entity responsible for reporting) in every filing.

Sources and References

Regulation (EU) No 648/2012 (EMIR) – Primary regulation on OTC derivatives, central counterparties, and trade repositories. EUR-Lex
Regulation (EU) 2019/834 (EMIR Refit) – Amending regulation that revised reporting obligations and introduced delegated reporting for NFC-. EUR-Lex
Commission Delegated Regulation (EU) 2022/1855 (RTS on reporting) – Technical standards specifying the details to be reported to trade repositories. EUR-Lex
Commission Implementing Regulation (EU) 2022/1860 (ITS on reporting) – Implementing standards specifying reporting formats and frequency. EUR-Lex
ESMA Guidelines for Reporting under EMIR (ESMA74-362-2281) – Full implementation guidance for the revised reporting framework.
CSSF Circular 23/846 – Luxembourg transposition of ESMA guidelines with local supervisory expectations. CSSF

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.