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

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 reporting framework became applicable on 29 April 2024, the regime 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 is organised around the three questions reporting teams actually search for: the EMIR transaction reporting obligation itself (who reports, which trades, and what goes in the report), the mechanics of reporting to a trade repository (submission, deadlines, reconciliation, and error handling), and the regulatory and supervisory context (how national competent authorities and ESMA use the data). Each is a separate discipline, and most reporting failures live in the seams between them.

Related reading: MiFIR Transaction Reporting

EMIR Transaction Reporting: Who Reports, Which Trades, and What You File

The transaction reporting obligation is the core of EMIR for most firms. It defines which counterparties must report, which contracts are in scope, and what data has to reach a trade repository. Get the classification wrong and every downstream step inherits the error.

The reporting obligation and its 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 technical standards under Commission Delegated Regulation (EU) 2022/1855 (the RTS on reporting) and Commission Implementing Regulation (EU) 2022/1860 (the ITS on reporting) became applicable. ESMA published its Guidelines on reporting under EMIR REFIT (reference ESMA74-362-2281) as the primary implementation reference for anyone building or validating a reporting process.

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, and the details must be reported no later than the working day following the conclusion, modification, or termination of the contract.

Who must report: dual-sided and delegated reporting

Counterparty classification decides both the reporting obligation and where the legal liability sits. The table below summarises the three classes and who carries responsibility for each; the operational detail follows.

Counterparty class	Who it covers	Reporting responsibility and legal liability
Financial counterparty (FC)	Credit institutions, investment firms, insurers and reinsurers, UCITS and their management companies, AIFs and their managers, IORPs, and CCPs	Reports its own derivatives. Under the Refit, also responsible and legally liable for reporting on behalf of its NFC- counterparties.
Non-financial counterparty above the clearing threshold (NFC+)	An NFC whose positions exceed a clearing threshold under Article 10(4)(b)	Obligations equivalent to an FC. Reports its own trades and retains legal liability for accuracy. Submission may be outsourced, but liability cannot be delegated.
Non-financial counterparty below the clearing threshold (NFC-)	An NFC below all clearing thresholds	Its FC counterparty reports on its behalf and holds the legal liability. The NFC- must still provide the data, verify accuracy where it has access, and monitor its own threshold status.

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 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 3 billion for commodity and other derivatives. The calculation methodology was refined by EMIR 3, and ESMA’s February 2026 final report on the clearing thresholds regime has proposed higher values for several of these categories, submitted to the European Commission for adoption and expected to apply later in 2026; confirm the values in force before relying on this list close to that date. Our guide to the EMIR 3 clearing thresholds and active account requirement covers the changes.

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.

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: the three tables

EMIR reports are structured across three tables defined in the technical standards. Only a subset of fields applies to any single trade, and 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.

The LEI is the gating requirement. Every counterparty must have a valid, renewed LEI at the time of submission. Lapsed LEIs trigger immediate rejections. Firms routinely waste entire mornings troubleshooting rejections that turn 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, with many fields conditional on the derivative type. The UTI generation waterfall and its operational headaches are covered under trade repository mechanics below.

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. For the initial margin fields specifically, see our note on EMIR initial margin reporting.

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 continues for the life of the derivative. 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.

EMIR Reporting to Trade Repositories: Submission, Reconciliation, and Error Handling

Once you know what to report, the second discipline is getting it into a trade repository cleanly, on time, and matched against the other side. This is where most day-to-day operational effort actually goes.

Registered 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, four trade repositories are registered with ESMA to receive EMIR derivative reports:

DTCC Data Repository (Ireland) PLC, established in Ireland
REGIS-TR S.A., established in Luxembourg
LSEG Regulatory Reporting B.V. (formerly UnaVista TRADEcho B.V.), established in the Netherlands
KDPW (Krajowy Depozyt Papierow Wartosciowych S.A.), established in Poland

ESMA maintains the authoritative register of registered TRs on its website. Registrations can be extended to cover other regimes, or withdrawn, so confirm the current list against ESMA before onboarding a repository. A common trap is to onboard a UK entity of the same brand: after Brexit, the UK repositories sit under the UK EMIR regime and are not registered with ESMA for EU reporting.

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

Submission format: the ISO 20022 XML transition

Since the 29 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 its 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 schema is also less forgiving than the formats it replaced. It catches structural errors that legacy CSV and flat-file submissions silently accepted, which is why firms that treated the change as a simple format swap found their rejection rates spiking in the first weeks after go-live.

Reporting deadlines and timelines

Derivatives must be reported by T+1: the working day following execution, clearing, or a lifecycle event. The table below sets out the operative deadlines, including the one-off Refit transition milestones.

Reporting obligation	Deadline
New derivative (conclusion)	T+1: no later than the working day following conclusion
Modification, correction, termination, and other lifecycle events	T+1: the working day following the event
Valuation update (FC and NFC+; NFC- exempt)	T+1, and daily in practice for firms with a material book
Margin and collateral update (FC and NFC+)	T+1 following the collateral exchange or margin settlement
EMIR REFIT reporting framework becomes applicable	29 April 2024
Re-reporting of outstanding derivatives to the REFIT standards	180-calendar-day transitional window after 29 April 2024, ending 26 October 2024

For the transition itself, firms with thousands of outstanding derivatives treated the re-reporting window as a dedicated migration project, running parallel reporting in the 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.

UTI generation and sharing

Under the Refit rules, responsibility for generating the UTI follows a defined waterfall: CCPs generate for cleared trades, and the venue of execution generates for centrally-executed but uncleared trades. The FC generates when trading with an NFC, and the NFC above the clearing threshold generates when trading with an NFC below it. For all other cases, including ordinary FC-to-FC uncleared trades, the counterparties agree bilaterally on who generates the UTI; if they cannot agree, the counterparty whose LEI sorts first when its characters are reversed is responsible. Most firms pre-agree UTI generation responsibilities in their ISDA documentation or operational onboarding.

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. Large firms typically automate UTI generation and sharing via SWIFT or proprietary messaging; smaller firms 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 and error handling

Post-Refit reconciliation is stricter, and break rates are higher than under the old regime. ESMA expanded the set of fields subject to mandatory matching between the two sides of a trade, and narrowed the tolerance thresholds for numerical fields. The most common break 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.

Error handling runs through the action types. A report submitted in error is flagged with Error; a genuine data fix uses Correct; a trade wrongly terminated is reopened with Revive. 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, while minor valuation differences are addressed in batches.

Multi-jurisdiction reporting

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 overseen by the Bank of England and the FCA. Our note on UK EMIR reporting under the Bank of England and FCA covers the divergence. The field sets are similar but not identical, and the TRs are separate. Some teams build jurisdiction-specific report generators that share a common data layer but apply different field maps and validation rules per regime.

EMIR Regulatory and Supervisory Reporting: How NCAs and ESMA Use the Data

The third discipline is the one firms think about least: what supervisors do with the data once it is filed. Understanding that context explains why reconciliation and data quality matter so much, and where enforcement attention actually lands.

How supervisors use EMIR data

EMIR data feeds the supervisory picture of systemic risk in derivatives markets. Under Article 81 of EMIR, a trade repository must give ESMA, the ESRB, the authority supervising the relevant CCPs, the authority supervising the trading venues of the reported contracts, and the other authorities listed in Article 81(3) direct and immediate access to the derivative data they need. A TR must also publish aggregate positions by class of derivative, and retain records for at least ten years under Article 80(3).

ESMA aggregates data across all registered TRs and runs cross-TR reconciliation. The Refit added explicit inter-TR reconciliation duties under Article 78, so that the two sides of a trade reported to different repositories can be matched. For a reporting firm, the practical consequence is that your submission is compared against your counterparty’s submission and against market aggregates. Outliers surface, and a persistent outlier position on any metric typically leads to a follow-up from your NCA. ESMA’s own transaction-reporting workstream is now also looking at simplification across regimes, as our note on ESMA’s transaction-reporting simplification estimate discusses.

What the EMIR REFIT changed, and what came after

The Refit was the largest reporting change since EMIR reporting began. The current standards are Commission Delegated Regulation (EU) 2022/1855 (RTS) and Commission Implementing Regulation (EU) 2022/1860 (ITS), applicable from 29 April 2024 and read alongside the ESMA Guidelines on reporting under EMIR REFIT (ESMA74-362-2281). The scope of the change was:

Format: all reports moved to ISO 20022 XML, replacing the varied CSV and proprietary formats TRs previously accepted.
Field set: the reportable fields expanded from 129 to approximately 203 (204 in the UK regime), spread across the three tables, with far more complex validation logic. New fields include the Unique Product Identifier (UPI), the event date, and the prior UTI for linked trades.
Product identification: every OTC derivative must now carry a UPI assigned by the Derivatives Service Bureau (DSB), replacing the freetext product taxonomy used previously.
Delegated reporting: FCs became responsible and legally liable for reporting on behalf of NFC- counterparties, a structural shift in where liability sits.
Reconciliation: ESMA widened the set of reconciled fields and narrowed numerical tolerances, and added inter-TR reconciliation duties under Article 78.

The UPI change had a longer operational tail than most teams expected. Firms had to map internal product classifications to the DSB taxonomy and build a DSB lookup into the pipeline. For standard products the lookup is straightforward; for bespoke structures, a new UPI may need to be requested from the DSB, which adds a step to trade booking. LEI and UPI together are now the two identifiers that gate acceptance: a report with a lapsed LEI or an unmapped UPI will not clear validation.

The clearing side of EMIR then moved again with EMIR 3, Regulation (EU) 2024/2987, which revised the clearing threshold calculation and introduced the active account requirement. That change sits on the clearing side, but it feeds counterparty classification, which in turn drives the reporting obligation. Our guide to the EMIR 3 clearing thresholds and active account requirement sets out the detail.

Luxembourg-specific supervisory 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 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 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 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 engaged with firms showing 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, in most cases. EMIR provides a narrow reporting exemption for intragroup derivatives under Article 9(1), but only where at least one counterparty is, or would qualify as, a non-financial counterparty, both counterparties are included in the same full consolidation with centralised risk management, and the group’s parent undertaking is not a financial counterparty. Financial-counterparty-to-financial-counterparty intragroup trades under a financial parent do not qualify and must always be reported. Where the exemption applies, counterparties notify their competent authorities of their intention to rely on it, and it is valid unless the authorities object within three months. The derivative should still be flagged as intragroup in the report. In practice, many groups simply report all intragroup trades rather than manage the exemption process, because maintaining the exemption documentation and monitoring for group changes carries its own operational cost.

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

No. Derivatives within the same legal entity (for example, 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 most other cases, including ordinary FC-to-FC uncleared trades, the counterparties agree bilaterally on who generates the UTI; if they cannot agree, the counterparty whose LEI sorts first when its characters are reversed is responsible. This waterfall is defined in the ITS 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.

Which trade repositories can we report to under EMIR?

You report to a trade repository registered with ESMA under Article 55, or a third-country TR recognised under Article 77. Four TRs are currently registered with ESMA for EMIR: DTCC Data Repository (Ireland) PLC, REGIS-TR S.A., LSEG Regulatory Reporting B.V. (formerly UnaVista TRADEcho B.V.), and KDPW. The two sides of a trade do not have to use the same TR. Always confirm the live list against ESMA’s register before onboarding, and do not assume a UK entity of the same brand is registered for EU reporting.

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.
EMIR 3 Clearing Thresholds and Active Account Requirement – How EMIR 3 revised the clearing thresholds and introduced the active account requirement that feeds counterparty classification.
EMIR Initial Margin Reporting – A closer look at the margin and collateral fields in Table 3 and the reconciliation issues they create.
UK EMIR Reporting under the Bank of England and FCA – The onshored UK regime and how dual EU and UK reporting is managed.
AML Reporting in Luxembourg – Luxembourg-specific reporting obligations that firms with EMIR exposure often also need to manage.

Key Takeaways

EMIR transaction reporting, trade repository mechanics, and the supervisory context are three separate disciplines. Most reporting failures live in the seams between them.
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.
Four trade repositories are currently registered with ESMA for EMIR: DTCC Data Repository (Ireland) PLC, REGIS-TR S.A., LSEG Regulatory Reporting B.V. (formerly UnaVista TRADEcho B.V.), and KDPW. Confirm the live register before onboarding, and do not mistake a UK entity for an EU-registered one.
The 29 April 2024 Refit moved all reporting to ISO 20022 XML, expanded the field count from 129 to approximately 203, and introduced the UPI via the Derivatives Service Bureau. EMIR 3 (Regulation (EU) 2024/2987) then revised the clearing thresholds.
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 and a mapped UPI are the two gating requirements for report acceptance. Automate expiry and mapping monitoring for your entire counterparty book.
Under Article 81, TRs give ESMA, the ESRB, and NCAs direct access to the data; your submission is reconciled against your counterparty’s and against market aggregates, and outliers surface to your supervisor.

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, frequency, and methods. EUR-Lex
Regulation (EU) 2024/2987 (EMIR 3) – Revised clearing thresholds and the active account requirement. EUR-Lex
ESMA Guidelines on reporting under EMIR REFIT (ESMA74-362-2281) and the ESMA EMIR reporting page, including the registered trade repositories register. ESMA
CSSF Circular 23/846 – Luxembourg transposition of ESMA guidelines with local supervisory expectations. CSSF

Getting EMIR Reporting Right Across All Three Disciplines

The firms that report cleanly treat EMIR as three linked disciplines. They fix classification first, because it drives everything downstream. They industrialise the trade repository mechanics, so that identifiers, deadlines, and reconciliation are automated instead of chased by hand. And they keep the supervisory context in view, because the data they file is matched, aggregated, and compared, and a persistent outlier is what brings the NCA to the door.

Last updated: July 2026

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.