Transaction reporting under MiFID II is one of the most operationally intensive regulatory obligations a capital markets firm carries. Every day, thousands of reports flow from investment firms to national competent authorities (NCAs) — or to authorised reporting mechanisms (ARMs) that relay them — covering virtually every trade in financial instruments admitted to trading on EU and UK venues. The purpose is market surveillance: regulators use this data to detect insider trading, market manipulation, and other forms of market abuse. Getting it right is not optional. The FCA alone has fined firms tens of millions of pounds for reporting failures.

Who Must Report

The reporting obligation falls on investment firms that execute transactions in financial instruments. Under MiFID II Article 26, a firm must report when it executes a transaction — meaning when it acts as principal, agent, or matched principal. The obligation is not limited to transactions on-exchange; OTC trades are equally in scope provided the instrument is admitted to trading on an EU or UK trading venue or is otherwise within scope.

Systematic internalisers (SIs) — firms that deal on own account when executing client orders outside a regulated market — have the same reporting obligation. Buy-side firms that route orders through an investment firm are typically exempt from direct reporting, as the executing broker reports on their behalf. However, where a buy-side firm executes directly — for example, via direct market access — it may itself become the reporting counterparty.

Post-Brexit, the UK retained MiFID II transaction reporting through onshored legislation. UK-authorised firms report to the FCA. EU firms report to their home NCA. A firm active in both jurisdictions must satisfy both regimes, which have diverged slightly over time.

What Instruments Are in Scope

Scope is broader than many firms initially assume. The key test is whether the financial instrument is admitted to trading on a trading venue — a regulated market, multilateral trading facility (MTF), or organised trading facility (OTF) — anywhere in the EU or UK. This means that even a bespoke OTC derivative is in scope if its underlying or a related instrument is listed. Equities, bonds, ETFs, listed derivatives, and a wide range of OTC derivatives (interest rate swaps, credit default swaps, FX options, commodity derivatives) all fall within scope.

Instruments that are entirely bespoke OTC with no connection to listed instruments are typically out of scope, but the analysis must be done carefully. Compliance teams maintain instrument reference data tables that map ISINs and CFI codes to scope determinations.

The Data Fields: What Must Be Reported

The original MiFID II template specified 65 data fields. These cover four broad categories: counterparty information, instrument identification, transaction details, and flags.

Counterparty Fields

The reporting firm is identified by its Legal Entity Identifier (LEI). The counterparty is also identified — by LEI where it is a legal entity, or by a national identifier (National Insurance number in the UK, passport number elsewhere) where it is a natural person. This counterparty identification requirement was one of the most demanding aspects of MiFID II implementation: firms had to build client onboarding workflows that captured the right identifier for every client type in every jurisdiction.

Where the transaction is executed on behalf of a client, the firm must also identify the investment decision maker (which may differ from the client entity itself — for example, a fund manager acting for a pension fund) and the person or algorithm responsible for the execution decision.

Instrument Identification

Every instrument must be identified by ISIN (International Securities Identification Number) where one exists. For instruments without an ISIN — certain OTC derivatives — a workaround exists using the instrument's underlying components, but the data quality challenges here are substantial.

Additional instrument fields include the CFI (Classification of Financial Instruments) code, the venue of execution (MIC code), and the trading date and time (to millisecond precision for algorithmic trading, microsecond where technically feasible).

Transaction Details

Price, quantity, and notional must be reported in the currency of the transaction. Price notation varies by instrument type: for bonds, price is expressed as a percentage of par; for equities, as a price per share; for derivatives, as the relevant premium or rate. The quantity field captures the number of units or nominal amount depending on the asset class.

The transaction also requires a buy/sell flag, a short-selling indicator, a waiver indicator where post-trade transparency waivers apply, and — for derivatives — the maturity date and leg details of the instrument.

Algorithm and Decision Maker Fields

MiFID II introduced explicit requirements to identify whether a human or an algorithm made the investment decision, and whether execution was algorithmic. Firms must assign short codes to their traders and algorithms and include the relevant code in the report. This was operationally demanding for banks with large trading floors and dozens of algorithms, requiring a short code registry maintained by compliance and operations.

Reporting Deadlines: T+1

Transaction reports must be submitted by the close of the following working day (T+1). For a trade executed on Monday, the report must reach the NCA by end of business Tuesday. In practice, most firms aim to submit on the evening of the trade date itself, using automated feeds from their order management systems (OMS) or execution management systems (EMS) into their reporting infrastructure.

Late reporting — even by hours — constitutes a breach. Firms with systematic late reporting have faced supervisory letters, remediation plans, and ultimately fines. The FCA's supervisory approach is data-driven: it compares submission timestamps against execution timestamps and flags outliers automatically.

How Reports Reach the NCA: ARM vs Direct Reporting

Firms have two routes to submit transaction reports. The first is direct reporting to the NCA — firms submit reports directly to the FCA's Market Data Processor (MDP) in the UK, or to the relevant NCA's portal in the EU. This requires firms to build and maintain direct connectivity, which is technically demanding and operationally intensive.

The second, and far more common, route is via an Authorised Reporting Mechanism (ARM). ARMs are FCA- or NCA-authorised third parties that collect reports from firms and relay them to the NCA. The ARM market in the UK and EU is dominated by a small number of providers: DTCC (through its Approved Reporting Mechanism), London Stock Exchange's UnaVista, and Tradeweb's DTCC Derivatives Repository. These ARMs provide connectivity, data validation, error notification, and reconciliation services.

Using an ARM does not transfer regulatory responsibility. The obligation remains with the investment firm. If the ARM submits an erroneous report because the firm provided bad data, the firm is in breach — not the ARM. This distinction matters enormously for governance: firms must have controls over the data they send to their ARM, not merely an SLA with the ARM itself.

Common Errors and Regulatory Scrutiny

Regulators have published data on the most frequent transaction reporting failures. The most common categories include:

  • LEI failures: Reporting with a lapsed, incorrect, or missing LEI — either for the firm itself or for the counterparty. LEIs must be renewed annually, and a firm's LEI registry must be kept current.
  • ISIN mapping errors: Using the wrong ISIN for an instrument, or failing to apply the correct ISIN where one exists.
  • Price and notional errors: Reporting price in the wrong currency, using the wrong price notation for the asset class, or confusing nominal with notional.
  • Timestamp errors: Reporting execution time in UTC when local time was used, or failing to report to the required precision for algorithmic trades.
  • Short code mismatches: Submitting trader or algorithm short codes that are not registered with the NCA, or using codes that do not match the actual decision maker.
  • Duplicate or missing reports: Submitting the same transaction twice, or failing to submit for transactions that fall within scope but were incorrectly mapped as out of scope.

The FCA conducts periodic transaction reporting supervisory reviews, sampling firms' reports and comparing them against expected data. Firms with high error rates receive supervisory engagement that can escalate to formal enforcement. The largest fine in this area — imposed on a major investment bank — ran to over £34 million for systematic failures over several years.

Reconciliation and Quality Controls

Best practice requires firms to operate a transaction reporting reconciliation process: comparing the trades captured in their OMS against the reports submitted via the ARM, and separately comparing against NCA acknowledgements. Any gap — a trade in the OMS not matched to a report, or a report rejected by the NCA — must be investigated and remediated promptly.

Most large banks run daily automated reconciliations, with a dedicated transaction reporting team in operations or compliance handling breaks and rejections. The governance framework typically includes monthly reporting to a compliance oversight committee on key metrics: submission volumes, rejection rates, late reports, and open breaks.