A large capital markets bank with global operations faces regulatory reporting obligations to a dozen or more regulators simultaneously. A single interest rate swap executed between a UK bank and a US corporate counterparty may trigger reporting obligations under MiFID II (to the FCA), EMIR (to ESMA-registered trade repositories), and the CFTC's swap data reporting rules — each with different data requirements, different deadlines, and different submission mechanisms. Managing this ecosystem requires dedicated infrastructure, specialist teams, and governance frameworks that span the entire reporting landscape.

The Major Reporting Regimes

EMIR (EU and UK)

EMIR requires both counterparties to a derivative contract to report to a trade repository (TR). The EU and UK have separate but substantively similar regimes post-Brexit. Under EU EMIR, firms report to ESMA-registered TRs (DTCC, REGIS-TR, ICE Trade Vault). Under UK EMIR, firms report to FCA-registered TRs. A cross-border trade between a UK firm and an EU firm triggers obligations under both regimes. The EMIR Refit changes (2024) expanded the field set, mandated ISO 20022 XML format, introduced mandatory FC delegation for NFC- counterparties, and required use of the Unique Product Identifier (UPI).

MiFID II Transaction Reporting

MiFID II (and UK MiFID) requires investment firms that execute transactions in financial instruments admitted to trading on EU/UK venues to submit transaction reports to the relevant NCA — the FCA in the UK, the relevant NCA in the EU. Reports flow either directly or via an Authorised Reporting Mechanism (ARM). The reporting covers equities, bonds, ETFs, and most derivatives with a link to a listed instrument. The data set (65 fields in the current UK framework) covers counterparty identification, instrument identification, price and quantity, and the identity of decision makers and algorithms.

CFTC Reporting (United States)

The Commodity Futures Trading Commission mandates swap data reporting for all swap transactions involving US persons or executed on US markets. US-registered swap dealers must report to CFTC-designated swap data repositories (SDRs) — DTCC's DDR, ICE Trade Vault, and CME's SDR. Following a 2022 rewrite of Part 43 and Part 45 of the CFTC regulations, reporting now aligns more closely with the CPMI-IOSCO technical standards for UTI, UPI, and critical data elements, reducing (but not eliminating) the divergence with EMIR reporting requirements.

ASIC Reporting (Australia)

The Australian Securities and Investments Commission (ASIC) requires reporting of OTC derivatives to ASIC-licensed trade repositories. The ASIC regime applies to reporting entities that are financial entities, corporates above certain thresholds, and central counterparties. ASIC's reporting rules were substantially updated in October 2024 to align with the CPMI-IOSCO technical guidance, bringing the UTI, UPI, and data field requirements into line with global standards.

Other Regimes

Beyond EMIR, MiFID II, CFTC, and ASIC, a global bank may also face reporting obligations under JFSA (Japan Financial Services Agency) for yen derivatives, MAS (Monetary Authority of Singapore) for Singapore-booked or Singapore-entity transactions, HKMA (Hong Kong) requirements, and others. The cumulative compliance effort is substantial: a trade in an Asia-Pacific timezone can generate reporting obligations across multiple jurisdictions before the European morning begins.

The Identifier Alphabet: LEI, UTI, UPI

LEI (Legal Entity Identifier)

The LEI is a 20-character alphanumeric code that uniquely identifies a legal entity participating in financial transactions. Introduced as a G20 post-crisis reform to improve regulatory transparency, LEIs are now required in virtually every major reporting regime — EMIR, MiFID II, CFTC, ASIC, and many others. LEIs are issued by Local Operating Units (LOUs) accredited by the Global LEI Foundation (GLEIF). They must be renewed annually; a lapsed LEI cannot be used in regulatory reports. Banks must maintain current LEIs for themselves and monitor LEI status for their counterparties.

The LEI creates a globally consistent entity identification layer that allows regulators across jurisdictions to identify the same legal entity. Without it, a JP Morgan entity might appear in US reports as "JPMorgan Chase Bank NA" and in EU reports as a different string — regulators could not aggregate across jurisdictions. The LEI resolves this.

UTI (Unique Trade Identifier)

The UTI is a code that uniquely identifies a derivatives trade across both counterparty reports and across reporting jurisdictions. Its purpose is to allow regulators to match the two sides of a bilateral derivative. The CPMI-IOSCO Technical Guidance on UTI specifies: the UTI must be agreed between counterparties before reporting; the generation hierarchy determines who generates it (CCP for cleared trades; the reporting party or platform in the waterfall for uncleared); and the UTI must be communicated to the other party promptly via a dedicated communication channel.

The UTI has been one of the most operationally contentious aspects of EMIR and CFTC reporting. Mismatches — where the two counterparties report different UTIs for the same trade — are common and have been a persistent regulatory concern. The EMIR Refit and CFTC Part 45 rewrites both tightened the UTI generation and communication requirements to address this.

UPI (Unique Product Identifier)

The UPI identifies the derivative product type — the financial instrument being traded, distinct from the specific instance (which is identified by the UTI). UPIs are issued by the ANNA-DSB (Association of National Numbering Agencies — Derivatives Service Bureau) and are required in EMIR Refit reports, CFTC Part 45 reports, and ASIC reports. The UPI covers the product's key economic characteristics: asset class, underlying, payment type, delivery type, and option type. Reference data teams must obtain and maintain UPIs for all products their firm trades, adding a new data dependency to the reporting infrastructure.

The Reporting Infrastructure: ARMs and APAs

ARM (Authorised Reporting Mechanism)

Under MiFID II, an ARM is a third-party firm authorised by the NCA to receive transaction reports from investment firms and relay them to the NCA's data processing system. Major ARMs in the UK and EU market include DTCC's ARM service, LSE's UnaVista, and Tradeweb's DTCC ARM. Using an ARM does not transfer regulatory responsibility: if an ARM submits an erroneous report because the firm provided bad data, the firm is in breach. ARMs provide value-added services including data validation, enrichment, acknowledgement processing, and reconciliation tools that help firms identify and fix errors before they become regulatory problems.

APA (Approved Publication Arrangement)

APAs are distinct from ARMs. They are authorised to publish trade reports for post-trade transparency purposes under MiFID II. When an OTC derivatives transaction is required to be made public under the post-trade transparency regime, the investment firm submits the trade report to an APA, which publishes it on its platform. APAs are not involved in regulatory reporting to the NCA; they operate the public disclosure system. Major APAs include Bloomberg, TradeWeb, and MarkitServ.

Common Reporting Failures and Remediation

Regulatory reporting failures are common across all regimes. The most frequently cited categories include:

  • LEI failures: Reporting with a lapsed LEI, an incorrect LEI, or a missing LEI for the counterparty.
  • UTI mismatches: Both sides of a trade submitting different UTIs, preventing regulatory matching.
  • Field accuracy errors: Incorrect price notation, wrong currency, mismatched notional convention, or erroneous dates.
  • Completeness failures: Trades not reported (scope determination errors, system mapping failures) or duplicate reports submitted.
  • Valuation and collateral reporting inaccuracies: EMIR ongoing valuation and margin reports that do not reconcile with the firm's own systems.

Remediation typically follows a structured process: identify the population of erroneous reports through reconciliation, quantify the error (how many reports, over what period, of what severity), submit corrections to the trade repository or NCA, implement root cause fixes in the reporting infrastructure, and report to the regulatory compliance committee with a remediation plan. For significant failures, firms may need to self-report to the FCA or relevant NCA before the regulator discovers the issue through its own data analysis — self-reporting is consistently treated more favourably in enforcement than failures discovered through supervision.