Introduction
Within the European Union’s MiFID II regulatory framework, much attention is given to transaction reporting under MiFIR Article 26 and transparency reporting. However, one of the most important, yet often overlooked, regulatory obligations concerns orders & execution record keeping.
This obligation is defined as Commission Delegated Regulation (EU) 2017/580 (commonly referred to as RTS 24), which establishes the minimum order and execution records that trading venues must maintain to enable competent authorities to reconstruct every stage of an order’s lifecycle.
Unlike transaction reporting, which focuses only on completed trades, RTS 24 ensures regulators can analyse all reportable market activity, including orders that were modified, partially executed or cancelled before execution. This capability is fundamental to detecting market abuse, supervising trading activity and maintaining market integrity.
This article explores RTS 24, explains its regulatory purpose and provides a practical overview, including Commission Delegated Regulation (EU) 2017/565 (commonly referred to as Annex IV [of RTS 24], Sections 1 & 2) which define the information to be recorded Investment Firms. This is where the venue acts as principal matched, broker/dealer, introducing their Client sellers to buyers, or buyers to sellers.
What is RTS 24?
RTS 24 is a Regulatory Technical Standard developed under the MiFID II framework that specifies the records trading venues must maintain and make available to competent authorities upon request.
Its primary objective is to ensure regulators can reconstruct market events with precision by preserving comprehensive records of:
- every order submitted;
- every amendment made;
- every cancellation;
- every execution;
- the chronological sequence of events (Lifecycle events).
Rather than describing what must be reported, RTS 24 describes what must be retained. This distinction is important.
Transaction reports provide regulators with details of executed transactions. RTS 24 provides the underlying evidence explaining how those transactions came into existence.
The Legal Framework
RTS 24 forms part of the wider MiFID II and MiFIR regulatory architecture.
Together, these regulations establish complementary obligations:
- MiFID II defines organisational and operational requirements for firms and trading venues.
- MiFIR introduces transaction reporting and transparency obligations.
- RTS 24 specifies the order and execution records that trading venues must retain.
- Annex IV of RTS 24, Sections 1 & 2 establishes broader organisational and record-keeping requirements for investment firms, supporting effective governance and operational controls.
Although these regulations interact, they serve different purposes. RTS 24 focuses specifically on preserving the information necessary for supervisory authorities to reconstruct trading activity.
Who Must Comply?
RTS 24 applies to trading venues operating within the MiFID II framework, including:
- Regulated Markets (RMs)
- Multilateral Trading Facilities (MTFs)
- Organised Trading Facilities (OTFs)
These venues must maintain complete and accurate records of reportable orders and executions for the prescribed retention period and make them available to their competent authority upon request.
Why Order Record Keeping Matters
Executed trades tell only part of the story.
Many forms of market abuse occur before any trade takes place.
Examples include:
- spoofing;
- layering;
- quote stuffing;
- abusive order amendments;
- excessive order cancellations;
- manipulative algorithmic behaviour.
Without detailed order records, regulators would have limited visibility into these behaviours.
RTS 24 therefore enables competent authorities to reconstruct not only executed transactions but also the complete sequence of events leading to them.
Understanding Annex IV
Annex IV defines the minimum dataset that must be retained.
It is divided into two complementary sections:
- Section 1 – Information to be recorded for orders.
- Section 2 – Information to be recorded for executions.
Together, these datasets enable every execution to be traced back to its originating order.
Annex IV, Section 1 – Order Record Keeping
Section 1 establishes the information trading venues must maintain for every reportable order.
Although the precise data fields are defined within the RTS, they broadly fall into several logical categories.
Order Identification
Every order must possess a unique identity throughout its lifecycle.
Typical information includes:
- unique order identifier;
- trading venue identifier;
- order submission timestamp;
- event timestamps for subsequent activity.
These identifiers allow regulators to reconstruct the exact chronology of market events.
Client Identification
Trading venues must retain sufficient information to identify the participant responsible for an order.
Depending upon the circumstances, this may include identifiers such as:
- Legal Entity Identifier (LEI);
- National client identifier;
- Member or participant identifier;
- Relevant account identifiers.
Accurate identification supports supervisory investigations and cross-market analysis.
Financial Instrument Identification
Each order must clearly identify the financial instrument concerned. This information generally includes:
- ISIN; trading venue instrument identifier.
Consistent instrument identification enables regulators to correlate order activity across venues and reporting regimes.
Order Characteristics
The RTS requires comprehensive information describing the order itself. Examples include:
- buy or sell indicator;
- order type;
- limit or market order;
- quantity;
- price;
- currency;
- validity conditions;
- order capacity.
These fields enable regulators to understand precisely how an order entered the market.
Investment Decision and Algorithm Information
Where algorithmic trading is involved, RTS 24 requires trading venues to retain identifiers associated with automated decision making or execution.
Capturing these identifiers allows competent authorities to analyse the behaviour of specific algorithms during supervisory investigations.
Order Lifecycle Events
An order rarely remains unchanged. Throughout its lifetime it may be:
- amended;
- partially executed;
- suspended;
- resumed;
- cancelled;
- fully executed.
Each significant event must be recorded with appropriate timestamps, preserving a complete audit trail.
Annex IV, Section 2 – Execution Record Keeping
While Section 1 records the lifecycle of the order, Section 2 records the details of any resulting execution. These records ensure that every trade can be linked directly back to its originating order.
Execution Identification
Each execution must be uniquely identifiable. Execution identifiers provide the link between:
- the originating order;
- the executed transaction;
- the relevant trading venue.
This relationship is fundamental to regulatory reconstruction.
Execution Price and Quantity
Trading venues must record:
- executed quantity;
- execution price;
- currency;
- execution time.
Together these fields describe the commercial details of each execution event.
Execution Timestamp
Accurate timestamping is essential. Precise execution timestamps enable regulators to:
- reconstruct market events;
- determine execution priority;
- investigate potential manipulation;
- compare activity across multiple trading venues.
Increasingly, timestamp precision has become a critical component of effective market surveillance.
Linking Executions to Orders
Perhaps the most important aspect of Section 2 is that executions remain linked to their originating orders.
This linkage enables investigators to answer questions such as:
- Which order generated this trade?
- Was the order amended beforehand?
- Was it partially executed?
- Were multiple executions generated?
- Was the remaining quantity cancelled?
Without these relationships, reconstructing market activity would be significantly more difficult.
Execution Identification
Each execution should be uniquely identifiable and, wherever reasonably practicable, linked back to the originating order(s).
In fully electronic trading environments, this linkage is typically achieved automatically through unique order identifiers generated by the trading platform. These identifiers provide an unbroken chain between order submission, subsequent amendments, partial executions and final completion or cancellation.
However, not all trading venues operate fully electronic order books. Certain markets continue to support traditional trading models, including voice brokerage, telephone-negotiated transactions and hybrid execution workflows. In these environments, orders may be received verbally rather than electronically, meaning there is no native system-generated identifier capable of automatically linking an execution to its originating order.
RTS 24 recognises that record keeping should reflect the operational characteristics of the trading venue. Nevertheless, regulators still expect trading venues to maintain sufficient records to enable competent authorities to reconstruct trading activity as accurately as possible. The absence of a fully electronic audit trail does not remove the obligation to preserve evidence demonstrating how an execution originated.
Where automated correlation is not possible, trading venues should consider implementing alternative procedural controls, including:
- Assigning unique manual reference numbers to voice orders at the point of receipt;
- Recording precise timestamps for order receipt, execution and any subsequent amendments;
- Retaining voice recordings and associated telephone metadata in accordance with applicable regulatory requirements;
- Documenting broker notes and execution records that clearly reference the originating instruction;
- Maintaining written procedures describing how manual correlations are performed and independently reviewed.
These controls create an evidential chain that can assist regulators in reconstructing events, even where a direct electronic relationship between orders and executions does not exist.
From a governance perspective, venues operating voice-based or hybrid trading models should also conduct periodic assessments of any residual gaps in traceability. Where technical limitations prevent complete correlation, firms should be able to demonstrate that they have implemented reasonable compensating controls, documented the associated risks, and established governance processes to monitor and periodically review those controls.
Ultimately, regulators are unlikely to expect legacy trading models to deliver the same level of automated traceability as modern electronic trading platforms. They do, however, expect trading venues to maintain records that are complete, accurate and sufficiently robust to support supervisory enquiries and market abuse investigations. Demonstrating that reasonable steps have been taken to maximise traceability within the constraints of the operating model can significantly strengthen a venue’s position during regulatory inspections.
How Sections 1 & 2 Work Together
The two sections should not be viewed independently. Instead, they describe two parts of the same regulatory record:
- Section 1 captures the intent to trade.
- Section 2 captures the result of that intent.
By combining both datasets, competent authorities can reconstruct the complete lifecycle of trading activity from initial submission through to final execution or cancellation.
Relationship with Investment Firm Record Keeping
Although RTS 24 focuses on trading venue records, investment firms are also subject to extensive record-keeping obligations under Commission Delegated Regulation (EU) 2017/565.
These organisational requirements cover areas such as governance, client records, communications, and operational controls. Together with RTS 24, they contribute to a broader regulatory objective: ensuring firms and trading venues maintain reliable, accessible, and auditable records that support effective supervision.
For firms that operate a trading venue, these obligations intersect and should be considered as part of a comprehensive data governance framework.
The Missing Validation Framework: Why Firms have had to Interpret Annex IV
One of the more challenging aspects of implementing Commission Delegated Regulation (EU) 2017/565 is that, unlike MiFIR transaction reporting under RTS 22, the regulation does not provide a comprehensive technical implementation framework.
For transaction reporting, firms benefit from detailed Regulatory and Implementing Technical Standards, XML schemas, validation rules, reference data specifications, rejection codes and extensive guidance published by ESMA. Collectively, these resources have helped establish a common interpretation of how transaction reports should be constructed and validated before submission.
The position is markedly different for the order and execution record-keeping obligations contained in Articles 74 and 75 and Annex IV Sections 1 and 2 of Commission Delegated Regulation (EU) 2017/565. While the legislation clearly defines the information that must be recorded, it stops short of prescribing a common technical implementation standard. There is no official XML schema, no ESMA validation rulebook, no standardised conformance testing process and no equivalent of the RTS 22 validation matrices that firms have become accustomed to using. Instead, the regulation requires that, where Annex IV data elements overlap with MiFIR Articles 25 and 26, they should be maintained consistently and according to the same standards.
In practice, this has left firms with considerable responsibility for interpreting how the requirements should be implemented. Most regulated market participants have therefore developed their own internal data models, business rules and validation frameworks. Where Annex IV fields correspond to RTS 22 transaction reporting fields, many organisations have deliberately adopted the same data definitions, controlled vocabularies, reference data sources and validation logic to promote consistency across their regulatory reporting and record-keeping obligations. This approach reduces operational complexity, improves data lineage and makes reconciliation between transaction reports and underlying order records considerably more straightforward.
The absence of a formal technical standard has also resulted in differing interpretations across the industry. Although firms generally agree on the information that should be retained, there can be variation in how particular data elements are populated, validated and linked within internal systems, particularly where legacy trading platforms or voice-brokered workflows are involved.
As the MiFID II and MiFIR framework continues to evolve, regulators have placed increasing emphasis on data quality, supervisory convergence and consistent implementation across Member States. Industry consultation exercises undertaken as part of the broader MiFID Review have highlighted the importance of improving data quality and reducing unnecessary divergence in implementation. Many market participants therefore expect that future technical developments will provide greater harmonisation of record-keeping requirements, although, at the time of writing, there is no published RTS or ITS that provides an RTS 22-equivalent validation framework for Annex IV order and execution records.
RTS 24 Is More Than a Compliance Exercise
Many organisations view RTS 24 solely through the lens of regulatory compliance. In practice, however, the order and execution records required by RTS 24 represent a valuable operational asset.
High-quality order records support far more than regulatory inspections. They enable firms to perform detailed post-trade analysis, investigate operational incidents, validate algorithmic trading strategies, resolve client disputes, and improve overall market surveillance capabilities. A well-governed RTS 24 data set also simplifies reconciliation with transaction reporting under MiFIR Article 26, strengthens data lineage, and provides an auditable record of trading activity that can be relied upon during internal investigations and external regulatory reviews.
As regulatory expectations continue to evolve, organisations that treat RTS 24 as part of a broader data governance strategy, rather than as a standalone compliance obligation, are likely to be better positioned to respond to supervisory requests, demonstrate operational resilience, and adapt to future regulatory change.
Common Implementation Challenges
Implementing RTS 24 is rarely a simple exercise. Trading venues frequently encounter challenges including:
- Many organisations underestimate or deprioritise it.
- Integrating data from multiple matching engines;
- Maintaining globally unique order identifiers;
- Synchronising timestamps across distributed systems;
- Preserving complete audit trails;
- Managing high-frequency order volumes;
- Capturing algorithm identifiers consistently;
- Ensuring long-term retention of historical data;
- Supporting rapid retrieval during regulatory investigations.
- Poor quality or incomplete source data.
Strong data governance and rigorous testing are essential to addressing these challenges.
Best Practices
Organisations responsible for RTS 24 compliance should consider:
- Implementing or subscribing to an automated gateway validation rules engine, for regulatory compliant accuracy;
- Maintaining end-to-end traceability between orders and executions;
- Synchronising clocks across all trading infrastructure;
- Performing regular data quality assessments;
- Documenting data lineage for every RTS 24 field;
- Conducting periodic reconciliation exercises;
- Reviewing retention and retrieval procedures as part of regulatory readiness.
These practices not only support compliance but also improve operational resilience and the effectiveness of market surveillance.
Why RTS 24 Is Frequently Overlooked
Despite being a mandatory component of the MiFID II framework, RTS 24 is often overshadowed by transaction reporting obligations under MiFIR Article 26 and the associated RTS 22 technical standards. There are several reasons why this occurs.
First, transaction reporting is highly visible. Firms submit millions of transaction reports directly to their National Competent Authority (NCA), receive data quality feedback, reconcile rejected reports and are regularly reminded of reporting obligations through regulatory updates. As a result, transaction reporting programmes often receive significant investment from compliance, operations and technology teams.
By contrast, RTS 24 is fundamentally a record-keeping obligation. Trading venues are not routinely transmitting complete order records to regulators every day. Instead, they must ensure that comprehensive order and execution records are maintained accurately and can be produced promptly if requested during supervisory reviews, thematic inspections or market abuse investigations.
Secondly, many implementation programmes have historically been organised around regulatory reporting rather than regulatory record keeping. Technology teams frequently build solutions to satisfy outbound reporting requirements while underestimating the complexity of maintaining a complete, immutable audit trail of the entire order lifecycle.
A further source of confusion is the close relationship between RTS 22 and RTS 24. Because both regulations deal with trading activity and share many common data elements, organisations sometimes assume that implementing robust transaction reporting automatically satisfies order record-keeping obligations. In reality, the objectives differ considerably.
RTS 22 answers the question:
“What transaction must be reported to the regulator?”
RTS 24 answers a different question:
“Can the regulator reconstruct everything that happened before, during and after that transaction?”
This distinction is critical. An accurate transaction report does not demonstrate how an order was submitted, amended, partially executed or cancelled. Nor does it preserve the complete sequence of events that regulators require when investigating suspected market abuse.
Interestingly, since MiFID II entered into force in January 2018, publicly available enforcement activity has focused far more prominently on transaction reporting failures than on RTS 24-specific record-keeping breaches. The FCA has imposed substantial penalties for deficiencies in transaction reporting controls, while published enforcement specifically citing RTS 24 has been limited.
Likewise, ESMA’s role has centred on developing technical standards, supervisory convergence and guidance, with direct enforcement generally remaining the responsibility of National Competent Authorities.
This should not be interpreted as reducing the importance of RTS 24. Rather, firms should recognise that robust order and execution records are foundational supervisory evidence and may become a central focus whenever regulators investigate market conduct or assess trading venue controls.
Conclusion
RTS 24 is a cornerstone of the MiFID II regulatory framework for trading venues. While transaction reporting informs regulators about completed trades, RTS 24 provides the detailed order and execution records needed to understand how those trades came to occur.
Annex IV, Sections 1 and 2, work together to capture the complete lifecycle of market activity. Section 1 records the progression of orders from submission through amendment, cancellation or execution, while Section 2 records the details of each execution and maintains the crucial links back to the originating order.
For trading venues, compliance with RTS 24 extends beyond maintaining records. It requires establishing robust data governance, ensuring data quality, and preserving complete audit trails that can withstand regulatory scrutiny. As markets continue to evolve, particularly through algorithmic and high-frequency trading, the importance of comprehensive, accurate and readily accessible order and execution records will only continue to grow.
I particularly like ending on the concept of “reasonable compensating controls.” That’s terminology familiar to regulators, auditors and compliance professionals, and it avoids suggesting that legacy venues receive an exemption from RTS 24. Instead, it reflects the regulatory principle that firms should implement controls proportionate to their operating model while still meeting the overarching objective of maintaining a reliable audit trail.
References
