EMIR Refit Reporting: What Changed and How to Stay Compliant

Since 29 April 2024, EMIR derivative reporting in the EU has run on a rewritten standard. CSV is gone; reports must be submitted in ISO 20022 XML. The field set expanded to 203 fields, and the Unique Product Identifier (UPI) became mandatory. More than a year in, the firms still getting rejections are usually wrestling with the same handful of issues. This is a practical guide to what changed and where to focus.

What actually changed

• ISO 20022 XML only. The previous CSV submission formats are no longer accepted. Reports and the messages your trade repository sends back (acknowledgements, reconciliation, rejections) are all XML.
• 203 fields. The EMIR Refit schema carries 203 reportable fields — 74 more than before. Around 89 are new, 15 were removed, and of the fields that carried over, roughly 81 changed in format or content.
• UPI is mandatory. Every reportable OTC derivative needs a Unique Product Identifier, validated against the ANNA DSB. The UPI sits alongside (not instead of) the ISIN and the unique transaction identifier (UTI).
• More collateral and margin detail. The collateral and valuation fields expanded, increasing the data you must source from your treasury and collateral systems.

Where reports break

UTI generation and pairing

Both sides of a dual-sided trade must report the same UTI. If the agreed UTI-generation logic (who generates, in what format, communicated how) is not airtight with each counterparty, you get pairing failures. This is the most common source of unresolved reconciliation breaks.

UPI sourcing

Firms that did not build a reliable path to obtain and store UPIs from the ANNA DSB end up with missing or stale identifiers. The UPI should be sourced and cached as part of product reference data, not looked up ad hoc at reporting time.

Lifecycle and valuation events

Refit sharpened the expectations on reporting lifecycle events (modifications, terminations, corrections) and daily valuations and collateral. Many breaks trace back to lifecycle events that were never reported or were reported with the wrong action type.

Reconciliation is now the main event

The trade repositories run extensive pairing and matching, and the tolerance for unmatched data is low. A compliant firm is not one that simply submits a file — it is one that submits, monitors the feedback, and resolves breaks inside the reconciliation cycle. If you do not have a daily process to triage rejections and reconciliation results, you have a reporting gap regardless of how clean your submissions look on the way out.

Delegated reporting does not transfer accountability

Many smaller firms delegate reporting to a dealer or a service provider. That is fine operationally, but the regulatory responsibility for accurate and timely reporting stays with you. You still need oversight: visibility of what was reported on your behalf, the reconciliation results, and a way to evidence that you are monitoring it. "Our broker handles EMIR" is not a control.

What is next: EMIR 3.0

The EMIR 3.0 review brings further change, with a continued policy push toward clearing in the EU and active-account requirements for certain counterparties. The reporting framework is relatively settled after Refit, but the strategic clearing picture is not — firms with material derivatives activity should keep this on the radar rather than assume Refit was the end of the road.

If EMIR reporting is on your desk, our advisory and the EMIR Refit Reporting Pack cover field mapping, UTI/UPI logic, and reconciliation. It pairs naturally with DNB XBRL reporting for firms reporting on multiple fronts.