MiFIR Transaction Reporting: Article 26 Requirements Explained

Requirement	Practical answer
Main legal requirement	Article 26 of MiFIR
Detailed reporting standard	RTS 22
Instrument reference-data standard	RTS 23
General reporting party	An investment firm that executes a reportable transaction
Submission deadline	As quickly as possible and no later than the close of the following working day
Reporting route	Directly to the competent authority or through an Approved Reporting Mechanism
Off-venue transactions	Certain transactions remain reportable even when not executed on a trading venue
Responsibility	Using an ARM or eligible transmission arrangement does not remove the firm’s responsibility

What is MiFIR transaction reporting?

MiFIR transaction reporting is the process through which investment firms provide regulators with detailed, structured information about transactions in specified financial instruments.

The principal EU obligation is contained in Article 26 of the Markets in Financial Instruments Regulation. An investment firm that executes a reportable transaction must provide complete and accurate details to the relevant competent authority as quickly as possible and no later than the close of the following working day.

A transaction report contains more than the basic economic terms of a trade. It can identify the buyer, seller, client, executing firm, branch, venue, investment decision-maker, execution decision-maker, and other people or systems connected to the transaction.

MiFIR sits within the wider MiFID II and MiFIR framework governing investment services, market structure, transparency, conduct, and investor protection.

How do Article 26, RTS 22, and RTS 23 work together?

Article 26 establishes the transaction-reporting obligation. The regulatory technical standards provide much of the operational detail required to apply it.

RTS 22—Commission Delegated Regulation (EU) 2017/590—sets out the detailed rules used to determine what constitutes a transaction, when an investment firm executes one, which information must be included, and how reports should be constructed.

RTS 23—Commission Delegated Regulation (EU) 2017/585—governs the standards and formats used to supply financial-instrument reference data to regulators. That data helps authorities and firms identify and classify the instruments connected to reported transactions.

RTS 22 therefore focuses mainly on the transaction, the parties involved, and the decisions surrounding it. RTS 23 supports the accurate identification and classification of the financial instrument.

The direct legal obligation sits within MiFIR rather than the MiFID II Directive. A firm may use the phrase “MiFID II transaction reporting” informally, but the more precise description is MiFIR transaction reporting under Article 26.

For a wider comparison, see MiFID II and MiFIR: Key differences and similarities.

Why do regulators require transaction reports?

Transaction reports allow authorities to see who was involved in a transaction, what was traded, when and where it was executed, and who made the relevant investment and execution decisions.

Regulators can combine this information with instrument reference data, trading-venue records, order data, market data, communications, account relationships, and Suspicious Transaction and Order Reports.

This can help identify trading before a price-sensitive announcement, activity across linked accounts, potentially manipulative strategies, inaccurate reporting patterns, and transactions inconsistent with previous behavior.

Where transaction data indicates potential insider dealing or market manipulation, it can support analysis under the market abuse regulation.

The same evidence may contribute to an assessment of whether a suspicious transaction and order report is required.

Transaction reporting also complements the monitoring described in trade surveillance, because completed trades can be connected with orders, cancellations, accounts, instruments, decision-makers, and market conditions.

Who must submit MiFIR transaction reports?

Under the EU framework, an investment firm that executes a transaction in a reportable financial instrument is generally responsible for submitting the report.

This may include firms dealing on their own account, executing client orders, making investment decisions under discretionary mandates, or carrying out other activities within the RTS 22 definition of execution.

A trading venue may also have reporting responsibilities where a transaction is executed through its systems by a member, participant, or user that is not itself subject to MiFIR transaction reporting.

The outcome depends on the legal entity, branch structure, instrument, transaction flow, and role performed by each organization.

A firm should map the complete journey from the original client instruction or investment decision through order transmission, execution, allocation, booking, and regulatory submission.

Statements such as “our broker reports for us” or “we only transmit orders” are not sufficient without evidence that the supporting legal and data-transmission conditions are met.

Which instruments and transactions are reportable?

Reportability is not determined solely by whether a transaction occurred on an exchange.

Under the currently applicable framework, scope can include instruments admitted to trading, traded on a trading venue, or subject to a request for admission. It can also include certain instruments whose underlying instrument, index, or basket is connected to instruments traded on a venue.

Some over-the-counter and off-venue transactions may therefore remain reportable.

A firm’s analysis should consider the instrument’s regulatory reference data, underlying exposure, execution method, and applicable exclusions. It should not rely only on a front-office product label or the fact that a transaction was booked as over the counter.

RTS 22 also defines what constitutes a transaction. A transaction generally involves acquiring or disposing of a financial instrument, but the detailed treatment can include entering into or closing derivatives and changing their notional amount.

Specified corporate actions, portfolio-compression events, securities-financing transactions reported under another regime, and some administrative or lifecycle events may fall outside the definition.

Classification should follow the technical rules rather than the ordinary commercial meaning of “transaction.” Firms should document product and lifecycle classifications and revisit them when systems, products, or regulatory standards change.

ESMA’s MiFIR reporting and FIRDS resources support firms in identifying relevant instruments and reference data under the EU framework.

What does execution of a transaction mean?

Execution is broader than placing a trade directly on a trading venue.

Depending on the circumstances, a firm may execute a transaction by dealing on its own account, executing a client order, making an investment decision under a discretionary mandate, or receiving and transmitting an order in circumstances covered by RTS 22.

One firm may decide whether to buy or sell, while another determines how, when, or where the order is executed. The report may need to identify both decisions separately.

Execution analysis should reflect what happened rather than relying only on contract wording or a commercial label.

This makes MiFIR reporting closely connected to recordkeeping. The firm should be able to reconstruct the instructions, decisions, transmissions, amendments, allocations, and executions supporting the report.

For the wider preservation of regulatory evidence, see recordkeeping compliance.

How does transmitting an order affect reporting?

A transmitting firm may be able to rely on the receiving investment firm to report the resulting transaction where all required transmission conditions are satisfied.

The transmitting firm must provide the prescribed information accurately and completely. Depending on the arrangement, this can include details about the client, buyer and seller, financial instrument, order, investment decision-maker, and transmitting firm.

Where the information is incomplete, inaccurate, or sent outside the eligible arrangement, the transmitting firm may retain its own reporting responsibility.

A contractual clause assigning reporting to another firm does not resolve the obligation where the required information does not move correctly in practice.

Firms should document transmission arrangements, test the data exchanged, reconcile acknowledgments, and preserve evidence showing how an order was received, amended, transmitted, and executed.

When must a transaction report be submitted?

Reports must be submitted as quickly as possible and no later than the close of the following working day. This is commonly described as T+1 reporting.

The next-working-day deadline should be treated as the final limit rather than the preferred submission time. The process needs enough time to generate the report, validate the data, submit it, receive an acknowledgment, and investigate any rejection or failure.

A report can be accurate but late. It can also arrive on time while containing incorrect or incomplete data. Timeliness and accuracy are separate requirements.

Firms should monitor transactions that remain unreported, submissions awaiting acknowledgment, rejected files, and corrections approaching the deadline.

For the wider operational challenge of managing reporting deadlines, data dependencies, and evidence of submission, see Reporting requirements.

What information does RTS 22 require?

Under the currently applicable framework, RTS 22 provides for transaction reports containing up to 65 fields, although not every field applies to every transaction.

Data category	Examples
Transaction details	Date, time, price, quantity, currency, and venue
Instrument	ISIN and other applicable instrument information
Parties	Buyer, seller, client, counterparty, and reporting entity
Decision-making	Person or algorithm responsible for investment and execution decisions
Execution context	Capacity, branch, venue, and method of execution
Regulatory indicators	Applicable short-selling, waiver, commodity-derivative, or other flags
Order transmission	Information required where an order passes between investment firms

A report can pass format and validation checks while remaining factually wrong.

A valid LEI may identify the wrong entity. A correctly formatted timestamp may not match the execution. A transaction may be duplicated or assigned to the wrong trader or algorithm while still being accepted technically.

Acceptance by an ARM or competent authority should not be treated as proof of substantive accuracy.

What does RTS 23 contribute?

RTS 23 specifies the reference-data standards and formats used to identify financial instruments for transaction reporting and related regulatory purposes.

Reference data can include the instrument identifier, name, classification, issuer, trading venue, currency, maturity, underlying instrument, and other attributes depending on the product.

Trading venues and systematic internalizers provide this information so that regulators can identify and classify instruments consistently.

RTS 23 matters because transaction reporting depends on reliable instrument data. Incorrect, incomplete, or late reference data can affect whether a transaction is identified as reportable and whether the instrument is described accurately.

Firms should understand how reference data enters their reporting process, which source takes precedence, how exceptions are resolved, and how instrument changes are reflected.

Which identifiers are used?

MiFIR reporting relies on standardized identifiers to connect a transaction with the correct entity, person, instrument, venue, and algorithm.

Common examples include Legal Entity Identifiers, ISINs, Market Identifier Codes, prescribed natural-person identifiers, trader codes, algorithm identifiers, and transaction or transmission identifiers.

These should be governed as controlled regulatory data rather than ordinary reference fields.

The firm should know which person, entity, or algorithm each identifier represents, when it became active or inactive, and which systems use it.

For legal-entity clients, the UK framework continues to apply the general “no LEI, no trade” principle. A firm should not execute a reportable transaction for an LEI-eligible client that lacks the required valid identifier.

A validly formatted LEI is not necessarily accurate. Using a parent-company LEI for a subsidiary or an investment manager’s LEI for the underlying client can make a report incorrect.

The FCA explains the UK position in its UK MiFIR and Legal Entity Identifier guidance.

A report may also need to identify separately the person or algorithm responsible for the investment decision and the person or algorithm responsible for execution.

Firms should maintain controlled inventories linking those identifiers to the relevant role, business area, strategy, and active period. Algorithm records should account for versions and material changes rather than relying on one generic code for several different strategies.

What is an Approved Reporting Mechanism?

An Approved Reporting Mechanism, or ARM, is a regulated service that submits transaction reports to a competent authority on behalf of investment firms.

An ARM may receive transaction data, perform technical validation, transform it into the required format, submit it, and return acknowledgments or rejection messages.

Using an ARM does not transfer the firm’s reporting responsibility.

The investment firm remains accountable for the completeness, accuracy, and timeliness of the data it supplies and for correcting reports when errors are found.

Oversight should cover service availability, rejection handling, data quality, business continuity, regulatory change, access to submitted records, and exit or migration arrangements.

The firm should verify successful regulatory submission rather than assume that delivery to the ARM completed the obligation.

How should firms validate, reconcile, and correct reports?

Validation checks whether a report is complete, correctly structured, and internally consistent. Reconciliation tests whether the submission matches the firm’s source transactions and records.

A robust process begins with the population of transactions the firm expected to report. This is compared with what was actually submitted and accepted.

Under UK MiFIR, firms can use the FCA’s Market Data Processor entity portal to download submitted transaction-report extracts and compare them with front-office records.

When an error is identified, the firm should correct it promptly and determine whether the same cause affected a wider population.

The investigation should identify what failed, which reports were affected, how they were corrected, whether regulatory notification is necessary, and how remediation was tested.

Correcting one report without addressing the underlying source problem leaves the control failure unresolved.

What is the difference between transaction reporting and trade reporting?

Feature	Transaction reporting	Trade or transparency reporting
Main recipient	A competent authority	The market or public transparency system
Primary purpose	Supervision, reconstruction, and market-abuse detection	Pre-trade or post-trade transparency
Information	Detailed client, firm, trader, algorithm, and transaction data	Primarily market-level price, volume, time, and execution information
Publication	Confidential regulatory submission	Relevant information may be published
Typical reporting service	Approved Reporting Mechanism	Approved Publication Arrangement

The same trade may create both obligations. Completing a public transparency report does not satisfy Article 26 transaction reporting, and submitting a transaction report does not necessarily meet the transparency requirement.

How are EU and UK MiFIR diverging?

EU MiFIR and UK MiFIR retain a common foundation, but firms should now manage them as separate regimes.

In the EU, the MiFIR review amended Article 26 and required ESMA to develop revised technical standards. ESMA published final reports on revised RTS 22 and RTS 23 in June 2025.

The amended provisions and revised standards should not be treated as operational until they have been formally adopted and their application dates have arrived. Until then, firms must continue applying the currently effective framework.

In the UK, the FCA’s CP25/32 consultation proposed replacing retained UK MiFIR transaction-reporting requirements with a more streamlined FCA Handbook regime.

The consultation closed on February 20, 2026. As of July 31, 2026, the FCA had not published its final Policy Statement and implementation timetable.

Cross-border firms should maintain separate EU and UK rule inventories, reportability logic, technical specifications, reference-data sources, schemas, and change programs.

What records and governance should support reporting?

Transaction reporting and recordkeeping are connected but separate obligations.

The firm should retain enough evidence to reconstruct the client instruction, investment decision, execution decision, order transmission, amendments, allocations, execution, identifiers, and relationship between orders and resulting transactions.

A technically complete report does not prove that the firm can explain the transaction. Equally, retaining extensive records does not remedy a late or inaccurate submission.

Governance should assign ownership across Compliance, Operations, Technology, front-office teams, reference-data owners, service-provider managers, and senior management.

The firm should be able to explain which entities and branches are in scope, how reportability and execution are classified, where each field originates, how successful submission is confirmed, how reports are reconciled, and how errors are corrected.

Common weaknesses include incomplete reportability analysis, incorrect execution classifications, missing off-venue transactions, poor LEI or client data, generic trader identifiers, incorrect algorithm mappings, timestamp errors, overreliance on ARM validation, and failure to reconcile accepted reports.

Effective reporting requires regulatory interpretation, data governance, technical delivery, reconciliation, recordkeeping, change management, and senior oversight to operate as one control environment.

See Prevent financial crime with real-time compliance monitoring for wider discussion of connected compliance data and monitoring.

Frequently asked questions

What does MiFIR stand for?

MiFIR stands for the Markets in Financial Instruments Regulation.

Which MiFIR article covers transaction reporting?

Article 26 contains the principal transaction-reporting obligation.

What is RTS 22?

RTS 22 is the regulatory technical standard governing the detailed construction and content of transaction reports.

What is RTS 23?

RTS 23 governs the standards and formats used to supply financial-instrument reference data.

When is a transaction report due?

It must generally be submitted as quickly as possible and no later than the close of the following working day.

Can an ARM take over the firm’s responsibility?

An ARM can submit reports, but the investment firm remains responsible for the accuracy, completeness, and timeliness of its data.

Are off-venue transactions reportable?

They can be. Reportability depends on the instrument and applicable scope rather than only on where execution occurred.

Are transaction reporting and trade reporting the same?

Transaction reporting is a confidential regulatory submission, while trade reporting primarily supports market transparency.

Are EU and UK MiFIR still identical?

They retain common foundations but are developing separately and should be governed as distinct regimes.

How Global Relay helps

MiFIR reporting depends on accurate transaction data, but firms may also need evidence showing how a transaction was instructed, decided, transmitted, amended, and executed.

Global Relay captures and preserves communications across email, mobile, voice, financial messaging, collaboration platforms, and other business channels.

This communications record can support transaction reconstruction, internal investigations, regulatory enquiries, legal hold, and analysis of reporting discrepancies.

Global Relay Communications Surveillance can also help connect relevant communications with wider conduct, financial-crime, and market-abuse investigations.

Learn more about Global Relay Archive and Global Relay Communications Surveillance.

Related reading:

• MiFID II and MiFIR: Key differences and similarities
• Reporting requirements
• Recordkeeping Compliance in Financial Services