MiFIR Transaction Reporting: Complete Guide to Article 26 Compliance

ByOfficer

Last updated: March 2026

What Is MiFIR Transaction Reporting and Why It Matters

MiFIR transaction reporting is one of the most operationally demanding requirements in European financial regulation. Every day, thousands of investment firms, trading venues, and systematic internalisers in the EU submit transaction data to national competent authorities (NCAs) under MiFIR Article 26. If you work in post-trade operations, compliance, or regulatory reporting, you already know this: the data is complex, the deadlines are tight, and the rules keep evolving.

MiFIR transaction reporting exists for one core reason: to give regulators a complete, accurate picture of who traded what, when, and at what price. That visibility is how NCAs detect market abuse, monitor systemic risk, and enforce conduct rules. Article 26 reporting is how market transparency happens at scale across Europe.

For reporting entities, this is a compliance obligation with teeth. Miss a deadline, submit incomplete data, or fail to identify your counterparty correctly, and you face regulatory findings, fines, or enforcement action. This article walks through what MiFIR transaction reporting actually is, who has to do it, what data goes into a report, how you submit it, and where practitioners commonly stumble.

Legal Basis and Scope

MiFIR Article 26 and RTS 22

The core legal requirement lives in MiFIR Article 26 (Regulation (EU) No 600/2014, as amended by Regulation (EU) 2024/791). It requires investment firms executing transactions in financial instruments to report details to their NCA.

The technical detail is in Commission Delegated Regulation (EU) 2017/590, commonly known as RTS 22. RTS 22 defines:

  • The 65+ data fields that must be reported
  • Timing and format requirements
  • Which instruments fall within scope
  • How to handle corrections and cancellations

Note: RTS 22 is distinct from RTS 25 (Commission Delegated Regulation (EU) 2017/574), which deals with clock synchronisation requirements. The two are sometimes confused but cover different obligations.

Important: The MiFIR review (Regulation (EU) 2024/791) entered into force on 28 March 2024 and introduces changes to Article 26, including revised scope for OTC derivatives reporting. However, the existing transaction reporting rules under the pre-amendment Article 26 and RTS 22 continue to apply until the new delegated acts are adopted and enter into force. ESMA consulted on revised RTS 22 in October 2024 and published final draft standards. Monitor ESMA publications for the effective date of the revised transaction reporting regime.

RTS 22 is prescriptive. A field is either mandatory, conditional, or optional. There is no “close enough” in transaction reporting.

Reportable Instruments Under Article 26

MiFIR Article 26(2) defines which instruments are in scope. Under the current regime (pre-revision RTS 22), reporting is required for transactions in financial instruments that are traded on a trading venue (TOTV), where the underlying is traded on a trading venue, or where the underlying is an index or basket composed of financial instruments traded on a trading venue.

Equities: Shares and depositary receipts admitted to or traded on a trading venue, or for which a request for admission has been made. ETFs listed on a trading venue are also reportable.

Debt instruments: Bonds admitted to trading on a trading venue. Government bonds, corporate bonds, structured bonds, and other securitised debt are in scope if TOTV.

Derivatives: Derivatives where the underlying instrument is TOTV or is an index/basket of TOTV instruments – including equity options and futures, bond futures, interest rate derivatives, credit derivatives, and CFDs on reportable underlyings.

Commodity derivatives: Commodity derivatives traded on a trading venue are reportable. The treatment of OTC commodity derivatives depends on whether the underlying is TOTV.

Emission allowances: EU ETS emission allowances and derivatives thereon are reportable.

What’s changing under the MiFIR review: The revised Article 26(2) extends transaction reporting to derivatives subject to the new post-trade transparency requirements under Article 8a(2), regardless of whether they are traded on a trading venue. This is a significant scope expansion for OTC derivatives, but it will only take effect once the new delegated acts are adopted.

Who Reports Under Article 26

Reporting Entities

MiFIR Article 26 imposes reporting obligations on:

1. Investment firms: Any firm authorised under MiFID II that executes transactions in reportable instruments must report. This includes market makers, brokers, investment advisers executing on behalf of clients, banks with investment services arms, and proprietary traders.

2. Trading venues: Regulated markets, MTFs, and OTFs may report on behalf of the investment firm. When a trading venue reports on behalf of firms, the firm is relieved of the obligation (Article 26(5)).

3. Systematic internalisers: SIs must report transactions executed in their capacity as SI.

4. Branches of non-EU firms: A branch of a third-country firm established in the EU must report if it would be required to do so as an EU firm.

Who Reports What

The investment firm that executes the transaction is the reporting entity. For a broker executing a client order, the broker reports. When a trading venue reports on behalf of firms (as many do), the venue submits the report. For SI trades, the SI reports.

Where an investment firm transmits an order to another firm for execution, the transmitting firm may rely on the executing firm to report – but only under specific conditions (Article 26(4) transmission agreements). The transmitting firm must ensure the executing firm has all necessary information and agrees to report.

What Gets Reported: The Data Elements

A transaction report comprises more than 65 fields, specified in RTS 22 Annex I. Each field maps to a specific aspect of the trade.

Core Mandatory Fields

Transaction identifiers: Transaction reference number (unique to each report), trading venue transaction identification code (if on-venue), execution timestamp (date and time to the granularity specified in RTS 25 on clock synchronisation – at least one second, microsecond for high-frequency trading), trading date/time, and reporting timestamp.

Instrument identification: ISIN of the financial instrument. If no ISIN exists (e.g., certain OTC derivatives), the complete set of identifier fields must be populated (instrument classification, underlying ISIN, notional currency, maturity, strike price, option type, etc.).

Buyer and seller details: Buyer identifier (LEI for legal entities; national client identifier for natural persons) and seller identifier. This is where errors cluster. Clients without LEIs must be identified by national ID. Firms often hold incomplete client data.

Quantity and price: Quantity, price, price currency, notional amount (for derivatives and bonds), up-front payment amount where applicable.

Venue and execution: Venue MIC code (if on-venue; “XOFF” for off-venue OTC trades), executing firm LEI, counterparty identifiers.

Decision maker and executor: Identification of the natural person who made the investment decision and the person responsible for execution within the firm. For algorithm-driven trades, the algorithm identifier. These natural person fields vary by NCA – Luxembourg’s CSSF accepts CSSF-assigned dealer numbers, while other NCAs require national ID numbers or passport numbers.

Flags and indicators: Short selling indicator, waiver indicator (for certain pre-trade transparency waivers), commodity derivative indicator, securities financing transaction indicator.

Client classification: Investment decision within firm or transmission of order indicator.

Conditional Fields

Many fields are conditional – required only in specific scenarios:

  • ISIN alternatives: If ISIN does not exist, the complete instrument identifier fields must be populated
  • Counterparty LEI: Required if counterparty is a legal entity
  • Algorithm identifier: Required only if the trade was executed by an algorithm
  • Notional amount: Required for derivatives and bonds; not applicable for equities
  • Short selling fields: Only if short selling occurred
  • Up-front payment: Only for certain derivative types

Reporting systems must handle conditional logic correctly. Omit a mandatory field and the report fails validation. Populate a field that should be blank and you may trigger queries.

Timing and Deadlines

The reporting deadline is T+1 – by the close of the next working day in the relevant NCA’s jurisdiction. For Luxembourg, a Friday trade must be reported by end of Monday (if Monday is a working day).

In practice, many firms report well within the T+1 window. Near-real-time reporting is increasingly common for firms using automated systems.

The reporting timestamp (when the report is submitted to the NCA or ARM) must be recorded separately from the execution timestamp (when the trade was executed). Confusing these two is a common error.

Failure to report by deadline is a breach of Article 26. NCAs enforce consistently.

Approved Reporting Mechanisms (ARMs)

An Approved Reporting Mechanism is a service provider that collects transaction reports from firms and submits them to the NCA on the firm’s behalf. Under the MiFIR review, ESMA now has direct supervisory authority over ARMs and other data reporting service providers (previously this was an NCA responsibility).

Large reporting entities use ARMs because they handle technical connectivity, file formatting, validation, audit trails, and correction workflows. Common ARMs include services from major financial data providers.

When a firm reports via an ARM, the ARM submits the report to the NCA. The firm remains responsible for data accuracy. The ARM does not relieve the reporting obligation – it is a submission channel, not a compliance shield.

Firms that do not use an ARM can report directly to their NCA via the NCA’s technical submission interface (typically SFTP or web portal).

MiFIR vs. EMIR: The Overlap

A derivative trade can trigger both MiFIR and EMIR reporting obligations. Understanding the distinction is important:

  • MiFIR reports to the NCA and covers transaction details (who traded, what, when, at what price). The purpose is market abuse detection and conduct supervision.
  • EMIR reports to a registered Trade Repository and covers derivative contract details, valuations, and collateral. The purpose is systemic risk monitoring and OTC derivatives transparency.

Example overlaps:

  • An equity option traded on a venue: MiFIR reportable (to NCA, by the venue or the firm) and EMIR reportable (to TR, by the counterparties).
  • A Bund future on Eurex: MiFIR reportable by the venue. EMIR reporting depends on clearing status.
  • An FX spot trade: Not MiFIR reportable (FX spot is not a financial instrument under MiFID II). Not EMIR reportable (FX spot is not a derivative).
  • An OTC interest rate swap between two banks: Currently MiFIR reportable if the underlying is TOTV. EMIR reportable in all cases.

Firms must maintain parallel reporting streams. The data elements differ, the recipients differ, and the deadlines differ.

Reference Data Challenges

The biggest operational challenge in transaction reporting is reference data completeness and accuracy.

Client Identification

Every client must be identified. Legal entities use their LEI (20-character alphanumeric code, validated via the GLEIF database). Natural persons use national client identifiers, which vary by country and nationality:

  • The identifier type is determined by the client’s nationality (not residence), using the CONCAT approach specified by ESMA
  • First priority: national passport number
  • Second priority: national ID card number
  • Third priority: tax identification number or other national identifier

Firms often have incomplete client data. A client onboarded years ago may lack LEI. A client in multiple jurisdictions may have identifiers in several systems. Data quality management is an ongoing operational task.

Instrument Identification

Every equity and bond should have an ISIN. The ISIN must be accurate – a single wrong character is a rejection. For OTC derivatives without ISIN, the complete alternative identifier must be constructed from underlying ISIN, instrument classification (CFI code), notional currency, maturity date, strike price, and other fields. This is error-prone.

Firms rely on reference data providers (Bloomberg, LSEG/Refinitiv, SIX, ANNA DSB) for instrument data. The ANNA DSB issues ISINs for OTC derivatives.

Natural Person Identification

Every trade must identify the natural person who made the investment decision and the person responsible for execution within the firm. The identification method is specified in RTS 22 and ESMA Guidelines, using the CONCAT approach based on the person’s nationality.

Luxembourg’s CSSF accepts national identifiers following ESMA’s CONCAT methodology. Firms must maintain accurate internal registries mapping traders and decision-makers to their identifiers.

The challenge: large firms with hundreds of traders across jurisdictions must maintain accurate registries across systems. This remains a common error source.

Common Reporting Errors

Every NCA publishes periodic data quality reports. The most frequent errors:

1. Missing or Invalid ISINs

Trades submitted without ISIN or with incomplete alternative instrument identifiers. Especially common for newly issued bonds (ISIN not yet available), OTC derivatives (alternative fields not fully populated), and instruments where the ISIN has been updated or retired.

2. Incorrect Buyer/Seller LEI

Client identified by incorrect, expired, or malformed LEI. Common causes: typographical error in the 20-character code, LEI lapsed and firm did not update, client merged/acquired and LEI changed, client has no LEI but firm submitted blank instead of national ID.

3. Missing Natural Person Identifiers

Decision maker or executor not identified or identified with wrong ID type or format. Especially problematic for firms reporting to multiple NCAs.

4. Timestamp Errors

Execution timestamp in wrong format (must be ISO 8601 / UTC), missing time zone designation, or insufficient granularity. Reporting timestamp confused with execution timestamp.

5. Short Selling Indicator Not Populated

For equity trades, the short selling indicator must be populated. If a short sale was executed, the indicator must be “SELL” with the short selling flag set. Firms often omit or populate incorrectly when lacking clear short sale data from prime broker or inventory systems.

6. Conditional Fields Missing or Over-Populated

Notional amount required for derivatives but omitted. Counterparty LEI populated when counterparty is a natural person (should use national ID). Algorithm identifier populated when trade was not algorithmically executed. Systems must enforce conditional logic at validation.

MiFIR Transaction Reporting in Luxembourg

CSSF Requirements

Luxembourg, as a major financial centre, has significant MiFIR reporting volumes. The CSSF is the NCA.

Key Luxembourg specifics:

  • Natural person identification: CSSF follows ESMA’s CONCAT methodology. Firms must register dealers and maintain accurate registries.
  • Reporting channels: Via ARM or directly to CSSF. CSSF provides technical specifications for direct submission.
  • Deadlines: T+1 by close of business (CET).
  • Scope: CSSF follows EU MiFIR and has issued clarifications on specific scenarios including intra-group trades and OTC derivatives treatment.

Cross-Border Reporting

A Luxembourg firm executing trades with clients in other EU member states reports to the CSSF (home state NCA). NCAs share transaction data among themselves via ESMA’s TREM (Transaction Reporting Exchange Mechanism), so the relevant host-state NCA also receives the data.

Large multi-jurisdictional firms may have branch-specific reporting obligations to the host-state NCA as well, depending on whether the branch executes transactions.

Recent and Upcoming Changes

The MiFIR Review (Regulation (EU) 2024/791)

The MiFIR review entered into force on 28 March 2024. Key changes affecting transaction reporting include:

  • Revised OTC derivatives scope: Article 26(2) now extends transaction reporting to OTC derivatives subject to post-trade transparency under the new Article 8a(2), regardless of TOTV status. This takes effect when the new delegated acts are adopted.
  • ESMA supervisory role over ARMs: ESMA now directly supervises data reporting service providers including ARMs, replacing NCA-level supervision.
  • Potential extension to AIFMs and UCITS managers: The European Commission was mandated to assess extending Article 26 reporting to AIFMs and UCITS management companies by 29 March 2025.
  • Revised RTS 22: ESMA consulted on comprehensive revisions to RTS 22 in October 2024, including new fields, revised scope, and alignment with the MiFIR review changes. Final draft standards are expected to be submitted to the Commission in 2025, with the new regime applying once the delegated acts are adopted and enter into force.

Until the revised delegated acts take effect, the existing Article 26 transaction reporting rules and RTS 22 continue to apply. Monitor ESMA’s MiFIR review page for updates on implementation dates.

Technology and Automation

Reporting technology has evolved significantly. Cloud-based solutions, APIs, and automated validation are now common. Firms invest in automation to reduce error and improve timeliness. Near-real-time reporting is becoming standard rather than end-of-day batch processing.

Coming Soon: Template-by-Template Deep Dives

We’re building detailed, template-level guides for each reporting framework covered on RegReportingDesk. Whether you need a field-by-field walkthrough of specific reporting scenarios, data element mappings, or best practices, these guides are on the way. Bookmark this page and check back soon.

Frequently Asked Questions

What is MiFIR Article 26 transaction reporting?

Article 26 requires investment firms executing transactions in reportable financial instruments to report transaction details to their NCA within T+1. Reports include 65+ data fields covering instrument identification, buyer/seller details, quantity, price, and decision-maker information. Regulators use this data to detect market abuse and monitor markets.

Which instruments are reportable?

Reportable instruments include equities, bonds, derivatives on reportable underlyings, commodity derivatives (if TOTV), CFDs on reportable assets, and emission allowances. The key test is whether the instrument is traded on a trading venue or has an underlying that is. The MiFIR review extends scope to certain OTC derivatives once the new delegated acts take effect.

What is the transaction reporting deadline?

T+1 – by the close of the next working day after execution. In Luxembourg, a Friday trade must be reported by end of Monday.

What is an ARM?

An Approved Reporting Mechanism is a service provider that collects transaction reports and submits them to the NCA on the firm’s behalf. Under the MiFIR review, ESMA now directly supervises ARMs. Firms remain responsible for data accuracy regardless of whether they use an ARM.

What is RTS 22?

Commission Delegated Regulation (EU) 2017/590, commonly known as RTS 22, specifies the detailed data fields, formats, and rules for transaction reporting under Article 26. It is distinct from RTS 25 (clock synchronisation). RTS 22 is being revised as part of the MiFIR review.

How does MiFIR relate to EMIR reporting?

Derivatives can trigger both MiFIR (to NCA) and EMIR (to trade repository) reporting. MiFIR covers transaction details for market abuse detection. EMIR covers derivative contract, valuation, and collateral data for systemic risk monitoring. Firms maintain parallel streams.

What are the most common errors?

Missing ISINs, incorrect buyer/seller LEI, missing natural person identifiers, timestamp format errors, and unpopulated short selling or conditional fields. Reference data quality and systematic validation are critical.

Key Takeaways

  • Article 26 requires investment firms to report transaction details to their NCA within T+1. The 65+ data fields are specified in RTS 22 (Commission Delegated Regulation (EU) 2017/590), not RTS 25.
  • The MiFIR review (Regulation (EU) 2024/791) is already in force since March 2024, but the existing RTS 22 transaction reporting rules continue to apply until the revised delegated acts are adopted. Watch for implementation dates.
  • Reportable instruments are determined by the TOTV test under the current regime. The MiFIR review extends this to include certain OTC derivatives subject to the new post-trade transparency framework.
  • ARMs are now supervised by ESMA rather than NCAs. Firms using ARMs remain responsible for data accuracy.
  • Client identification requires LEI for legal entities and national identifiers for natural persons, using the CONCAT approach specified by ESMA based on the person’s nationality.
  • MiFIR and EMIR overlap for derivatives. A single derivative trade may trigger both MiFIR reporting (to NCA) and EMIR reporting (to trade repository). The data elements, recipients, and purposes differ.
  • Most common errors are reference data quality issues: missing ISINs, incorrect LEIs, wrong natural person identifiers, and timestamp format problems. Systematic validation and quality controls are essential.
  • Natural person identification remains a pain point. Firms must maintain accurate registries of traders and decision-makers mapped to the correct national identifiers per ESMA’s CONCAT methodology.

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.

Sources and References

Similar Posts

  • The Most Common COREP Reporting Errors (And How to Avoid Them)

    Last updated: March 2026 Why COREP Errors Matter COREP submission day is busy, stressful, and error-prone – but overlooking COREP reporting errors carries real consequences that extend far beyond a missed deadline. You’re pulling data from multiple systems, running reconciliations, and pushing templates through validation in the final hours. When errors appear – especially late…

  • COREP Reporting Explained: A Practical Guide to Prudential Reporting

    Last updated: March 2026 What Is COREP and Why It Matters COREP stands for Common Reporting. It’s the standardized format through which EU banks and other regulated entities submit their prudential information – capital adequacy, risk exposure, asset quality, and liquidity data – to supervisory authorities. If you work in banking compliance, finance, or risk…

  • AML Reporting in Luxembourg: STRs, GoAML, and Your Obligations

    Last updated: March 2026 Introduction AML reporting in Luxembourg is mandatory for every regulated financial institution and obliged entity – failure to file suspicious transaction reports exposes your firm to regulatory sanctions, reputational damage, and legal liability. For compliance officers, risk managers, and AML practitioners in Luxembourg’s financial sector, understanding when and how to file…

  • MiCAR Reporting Obligations for CASPs: Complete Implementation Guide

    Last updated: March 2026 Introduction MiCAR (Markets in Crypto-Assets Regulation) creates the first comprehensive regulatory framework requiring crypto-asset service providers to implement authorization, prudential reporting, transaction monitoring, and incident notification systems. The Markets in Crypto-Assets Regulation (Regulation (EU) 2023/1114) represents the first unified rulebook for crypto-asset activities across the entire European Union. For reporting teams…

  • EMIR Initial Margin Reporting – What the New IM Model Authorisation Regime Means for Your Firm

    Last updated: March 2026 If your firm uses ISDA SIMM to calculate initial margin on non-centrally cleared OTC derivatives, you have operated for years without needing formal supervisory approval for that model. That changes under EMIR 3. For the first time, every counterparty using an IM model must obtain prior authorisation from its competent authority….