What Are the Key Differences between RTS 22 Transaction Reporting and RTS 24 Order Record Keeping? ▴ Question

Angularly connected segments portray distinct liquidity pools and RFQ protocols. A speckled grey section highlights granular market microstructure and aggregated inquiry complexities for digital asset derivatives

Interlocking transparent and opaque geometric planes on a dark surface. This abstract form visually articulates the intricate Market Microstructure of Institutional Digital Asset Derivatives, embodying High-Fidelity Execution through advanced RFQ protocols

Concept

In dissecting the European Union’s market surveillance architecture, one must view RTS 22 and RTS 24 as two distinct, yet complementary, data architectures designed for fundamentally different regulatory objectives. They are the central nervous system and the official historical record of the market, respectively. Understanding their functional separation is the first principle in mastering the operational realities of MiFIR compliance.

RTS 22 is the post-trade declarative act; it is the definitive statement of a transaction’s existence, reported by the investment firm that brought it to life. Its purpose is to create an immutable ledger for accountability, allowing regulators to connect every executed trade to a specific market participant.

Conversely, RTS 24 serves as the market’s chronicle, a high-fidelity recording of all market intent. This regulation mandates that trading venues capture every single order and quote, whether it results in a trade or is withdrawn in a fraction of a second. It is the raw, pre-trade and at-trade data stream that reveals the mechanics of price discovery. While RTS 22 answers the question “What was ultimately traded?”, RTS 24 answers the question “How was that price discovered?”.

The former is a record of outcomes, the latter a record of the process. One provides the ‘who’ and ‘what’ for surveillance; the other provides the ‘how’ and ‘why’ for market reconstruction.

RTS 22 governs the external reporting of executed transactions by investment firms, while RTS 24 mandates the internal record-keeping of all orders by trading venues.

The core distinction lies in the entity responsible and the scope of the data captured. An investment firm fulfills its RTS 22 obligation by submitting a detailed report of an executed trade to its National Competent Authority (NCA), typically via an Approved Reporting Mechanism (ARM). This report contains the vital statistics of the transaction itself.

A trading venue, on the other hand, meets its RTS 24 obligation by maintaining an exhaustive internal log of every order message that hits its matching engine. This data is not reported daily; it is stored meticulously, ready for regulators to request and analyze in order to reconstruct the order book at any given moment in time, particularly during periods of market stress or to investigate manipulative behavior.

A sleek, two-toned dark and light blue surface with a metallic fin-like element and spherical component, embodying an advanced Principal OS for Digital Asset Derivatives. This visualizes a high-fidelity RFQ execution environment, enabling precise price discovery and optimal capital efficiency through intelligent smart order routing within complex market microstructure and dark liquidity pools

A sleek, futuristic apparatus featuring a central spherical processing unit flanked by dual reflective surfaces and illuminated data conduits. This system visually represents an advanced RFQ protocol engine facilitating high-fidelity execution and liquidity aggregation for institutional digital asset derivatives

Strategy

The strategic imperatives behind RTS 22 and RTS 24 flow directly from their distinct functions within the MiFIR framework. The strategy of RTS 22 is fundamentally about market integrity and the deterrence of illicit activity through transparency. For regulators, it is the primary tool for market abuse surveillance.

The strategy of RTS 24 is about systemic oversight and ensuring the robustness of market structures. It provides the empirical data needed to analyze market mechanics and the behavior of trading algorithms.

A precision-engineered system with a central gnomon-like structure and suspended sphere. This signifies high-fidelity execution for digital asset derivatives

The Surveillance Mandate of RTS 22

The strategic design of RTS 22 is centered on creating a comprehensive and standardized dataset that allows regulators to effectively monitor for insider dealing, market manipulation, and other financial crimes. By mandating the reporting of uniform data fields from all investment firms across the EU, regulators can aggregate and analyze trading activity across different venues and asset classes. This cross-market view is essential for detecting sophisticated manipulative schemes that might otherwise go unnoticed. The inclusion of personal identifiers for traders and client identifiers (LEIs) is a critical component of this strategy, as it allows for the direct attribution of trading activity to individuals and entities, creating a powerful deterrent effect.

The image presents a stylized central processing hub with radiating multi-colored panels and blades. This visual metaphor signifies a sophisticated RFQ protocol engine, orchestrating price discovery across diverse liquidity pools

The Market Reconstruction Mandate of RTS 24

The strategic purpose of RTS 24 is to give regulators the ability to perform a complete “replay” of market activity. This capability is vital for several reasons. First, it allows for the forensic investigation of market incidents, such as flash crashes or periods of extreme volatility, by examining the sequence of orders and cancellations that led to the event. Second, it enables regulators to assess the health and fairness of the market’s price formation process.

By analyzing order book data, they can study liquidity dynamics, the impact of high-frequency trading strategies, and the overall quality of a trading venue’s matching engine. The recent MiFIR review’s emphasis on machine-readable formats and common templates for RTS 24 data underscores its strategic importance as an analytical tool.

The strategic focus of RTS 22 is attributing accountability for actions taken, whereas the focus of RTS 24 is understanding the mechanics of the environment in which those actions occurred.

The following table outlines the core strategic distinctions between the two regulatory technical standards:

Strategic Dimension	RTS 22 (Transaction Reporting)	RTS 24 (Order Record Keeping)
Primary Regulatory Goal	Market Abuse Detection & Surveillance	Market Reconstruction & Systemic Oversight
Responsible Entity	Investment Firms executing transactions	Trading Venues (e.g. Regulated Markets, MTFs, OTFs)
Data Timeframe	Post-Trade (Typically reported by T+1)	Pre-Trade, At-Trade, and Post-Trade (Real-time capture)
Data Scope	Details of executed transactions only	All orders, quotes, modifications, and cancellations
Core Analytical Question	Who traded what, when, and with whom?	How did the market arrive at a specific price?
Data Flow	External submission to a Competent Authority	Internal storage, provided to regulators upon request

A complex central mechanism, akin to an institutional RFQ engine, displays intricate internal components representing market microstructure and algorithmic trading. Transparent intersecting planes symbolize optimized liquidity aggregation and high-fidelity execution for digital asset derivatives, ensuring capital efficiency and atomic settlement

Execution

From an operational standpoint, the execution of RTS 22 and RTS 24 obligations presents vastly different technical and procedural challenges. Compliance with RTS 22 is a data integration and reporting challenge for investment firms, while RTS 24 compliance is a high-volume data capture and storage challenge for trading venues. The level of granularity, the timing requirements, and the technological architecture required for each are fundamentally distinct.

Operational Mechanics of RTS 22 Reporting

For an investment firm, executing its RTS 22 reporting duty involves a multi-stage process. The firm must first identify all reportable transactions within its trading systems. This requires a clear understanding of the instrument scope, which can be complex for derivatives.

Once identified, the firm must enrich the trade data with dozens of required fields. These fields include:

Instrument Identification ▴ Using an ISIN to uniquely identify the financial instrument.
Party Identifiers ▴ Legal Entity Identifiers (LEIs) for the investment firm, the client, and the counterparty.
Trade Economics ▴ Precise quantity, price, currency, and trading date/time.
Venue and Execution Details ▴ The MIC of the trading venue and codes to indicate the trading capacity.
Post-MiFIR Review Additions ▴ Proposals include new fields for the transaction’s effective date and identifiers for instruments on distributed ledger technology (DLT).

This enriched data is then typically transmitted to an Approved Reporting Mechanism (ARM). The ARM validates the report for format and content errors before submitting it to the relevant National Competent Authority (NCA) by the end of the next trading day (T+1). The primary operational challenge is ensuring data quality and consistency across multiple internal systems (e.g. order management systems, execution management systems, and client databases) to produce a single, accurate report for each transaction.

Abstract depiction of an advanced institutional trading system, featuring a prominent sensor for real-time price discovery and an intelligence layer. Visible circuitry signifies algorithmic trading capabilities, low-latency execution, and robust FIX protocol integration for digital asset derivatives

What Are the Systemic Demands of RTS 24?

For a trading venue, the execution of RTS 24 is an exercise in high-performance data engineering. The venue’s systems must capture every single message related to an order’s lifecycle, from its initial submission to its final state (executed, cancelled, or expired). The data must be timestamped with extreme precision, often to the microsecond or nanosecond, and synchronized to Coordinated Universal Time (UTC) as mandated by RTS 25. The sheer volume of this data is immense, especially on active markets with significant high-frequency trading activity.

The operational complexity of RTS 22 lies in data aggregation and accuracy, while the complexity of RTS 24 lies in data volume, velocity, and storage.

The table below provides a granular comparison of the operational execution requirements:

Operational Element	RTS 22 (Transaction Reporting)	RTS 24 (Order Record Keeping)
Primary Data Source	Firm’s execution records and client data	Venue’s matching engine and order management system
Timestamp Granularity	Date and time of execution (seconds, sometimes milliseconds)	Microsecond or nanosecond precision for every order event
Key Data Points	Client LEI, Trader ID, Price, Quantity, Venue	Order ID, Order Status (New, Modify, Cancel), Price, Size, Timestamp
Data Volume	Proportional to the number of executed trades	Massive; includes all non-executed orders (often 100x+ trade volume)
Systemic Challenge	Data enrichment, validation, and timely submission	Real-time capture, high-capacity storage, and clock synchronization
Reporting Cadence	Daily (T+1 deadline)	Continuous real-time capture, stored for at least five years

The recent MiFIR review further refines these obligations. For RTS 22, the proposed changes aim to improve data quality and link transaction reports more effectively along the reporting chain, for example by enhancing the use of the Trading Venue Transaction Identification Code (TVTIC). For RTS 24, the amendments focus on standardizing the format for data storage to make it easier for regulators to consume and analyze the vast datasets they request.

A translucent institutional-grade platform reveals its RFQ execution engine with radiating intelligence layer pathways. Central price discovery mechanisms and liquidity pool access points are flanked by pre-trade analytics modules for digital asset derivatives and multi-leg spreads, ensuring high-fidelity execution

References

European Securities and Markets Authority. “Consultation Paper on the review of RTS 22 on transaction data reporting and RTS 24 on order book data.” ESMA, 3 October 2024.
DLA Piper. “ESMA consults on revisions RTS 22 on transaction data reporting and RTS 24 on order book data under MiFIR.” Global Law Firm, 29 October 2024.
Control Now Ltd. “Key Proposals for MiFIR RTS 22.” Control Now, 4 October 2024.
Kaizen Reporting. “ESMA MiFIR Review ▴ Key changes proposed to MiFIR Transaction Reporting (RTS 22).” Kaizen Reporting, 9 October 2024.
European Fund and Asset Management Association. “EDMA responses to ESMA CP on Review of RTS 22 and RTS 24.” EFAMA, January 2025.

A sleek pen hovers over a luminous circular structure with teal internal components, symbolizing precise RFQ initiation. This represents high-fidelity execution for institutional digital asset derivatives, optimizing market microstructure and achieving atomic settlement within a Prime RFQ liquidity pool

Reflection

Viewing RTS 22 and RTS 24 through a systems architecture lens reveals them as two foundational pillars supporting the entire edifice of modern market transparency. One is the ledger of accountability, the other a chronicle of market intent. Their effective implementation within a firm or a venue is a reflection of its commitment to operational integrity. The data generated for compliance is not merely a regulatory burden; it is a high-resolution digital footprint of market activity.

How does your institution’s data architecture treat these two distinct streams? Are they viewed simply as compliance outputs, or are they integrated into a broader framework of internal risk management and operational intelligence? The capacity to leverage this data internally, to understand one’s own trading impact or market’s microstructure, is what separates a reactive compliance function from a proactive, strategic asset.