What Are the Specific Data Points Required in an Rts 27 Best Execution Report?

Concept

An RTS 27 report functions as a public, quantitative ledger of an execution venue’s performance. It is a mandated disclosure under the European Union’s Markets in Financial Instruments Directive II (MiFID II) framework, designed to bring radical transparency to the quality of trade execution. The core purpose is to provide market participants with standardized data to compare how different venues ▴ such as traditional exchanges, Multilateral Trading Facilities (MTFs), and Systematic Internalisers (SIs) ▴ actually perform. This allows for empirical, data-driven decisions when directing order flow, moving the industry from relationship-based assumptions to verifiable metrics of execution quality.

The operational challenge presented by RTS 27 is one of data architecture and translation. It requires a venue to capture a vast array of highly granular, time-stamped data points for every single transaction and order event. This raw data must then be aggregated, calculated, and structured into a series of standardized tables.

These tables cover everything from explicit and implicit costs to the likelihood and speed of execution. The final report, published quarterly, provides a forensic accounting of the venue’s ability to facilitate efficient price discovery and trade matching for specific financial instruments.

The RTS 27 framework transforms the abstract concept of ‘best execution’ into a set of concrete, measurable, and comparable data points.

Viewing this from a systems perspective, the RTS 27 report is an output layer built upon a complex foundation of a venue’s internal trading and data systems. It is the point where the internal mechanics of order matching, liquidity provision, and price formation are exposed to external scrutiny. The specific data points required are not arbitrary; they are carefully selected to paint a multi-dimensional picture of performance, covering the critical factors that a sophisticated market participant would consider when evaluating where to trade. These factors include price, costs, speed, and likelihood of execution, forming the pillars of the reporting obligation.

Strategy

A strategic approach to RTS 27 reporting and data consumption moves beyond mere compliance. It re-frames the obligation as a source of competitive intelligence. For execution venues, generating accurate and insightful reports can become a marketing tool, quantitatively demonstrating their advantages in liquidity, price improvement, or speed for certain asset classes. For investment firms and asset managers, the strategy involves systematically ingesting and analyzing the RTS 27 reports published by all relevant venues to build a sophisticated, data-driven smart order routing logic.

How Can RTS 27 Data Refine Trading Strategies?

The public availability of RTS 27 data permits a level of empirical analysis that was previously impossible. A trading desk can construct a detailed, evidence-based profile of each venue it connects to. This allows for the development of highly nuanced routing policies that adapt to order size, instrument liquidity, and prevailing market conditions.

For instance, a strategy for a large, illiquid block trade would prioritize venues that demonstrate a high likelihood of execution and minimal price impact for that specific instrument and order size, even if their average spreads for small trades are wider. Conversely, a high-frequency strategy would favor venues with the lowest latency and tightest spreads for small, liquid orders.

Systematic analysis of RTS 27 reports allows a firm to architect an order routing policy based on verifiable performance instead of historical assumptions.

This analytical process requires a dedicated data strategy. Firms must build or acquire the capability to download, parse, and store the quarterly reports from dozens of venues. The data, often published in large XML or CSV files, must be cleaned and normalized into a unified database schema. From this structured dataset, analysts can generate comparative dashboards and quantitative models to rank venues according to the specific execution factors that matter most to their trading strategies.

A Framework for Venue Comparison

The table below illustrates a simplified framework for how an investment firm might compare two hypothetical venues using key data points derived from their RTS 27 reports for a specific class of equities.

This comparative analysis reveals a clear strategic path. A firm might route small, latency-sensitive orders to Venue Alpha to capture the tightest spreads, while directing larger, less time-critical orders to Venue Beta to benefit from lower fees, a higher probability of execution, and the potential for substantial price improvement.

Execution

The execution of an RTS 27 reporting project is a significant undertaking in data engineering and regulatory interpretation. It demands a meticulous, systematic approach to ensure that the final output is not only compliant but also an accurate representation of the venue’s performance. The process is a chain of custody for data, from its raw creation at the point of trade to its final publication in a standardized format.

The Operational Playbook

Generating a compliant RTS 27 report involves a multi-stage operational workflow. Each step must be carefully designed and validated to ensure data integrity and adherence to the technical standards.

1. Data Sourcing and Capture This initial phase involves identifying every internal system that generates or stores the requisite data. This includes the order management system (OMS) for order details, the matching engine for execution timestamps and prices, and market data feeds for reference prices (like the best bid and offer) at various points in time. Data must be captured with high-precision timestamps, typically at the microsecond level.
2. Aggregation and Warehousing Raw data from disparate sources must be collected into a central repository. This data warehouse or data lake becomes the single source of truth for the reporting process. A critical task here is normalization ▴ ensuring that data formats, instrument identifiers (e.g. ISINs), and timestamps are consistent across all sources.
3. The Calculation Engine This is the core of the reporting system. A powerful processing engine, often built using Python, Java, or specialized financial software, consumes the aggregated data. It is responsible for calculating the dozens of metrics required by the regulation. This includes complex calculations like the effective spread, which requires comparing the trade price to the contemporaneous best bid and offer.
4. Report Assembly and Formatting Once all metrics are calculated, they must be organized into the nine distinct tables specified by the regulation. The system must then generate the final report file for each financial instrument. The technical specification mandates an XML (Extensible Markup Language) format, which requires a robust XML generator that can handle large volumes of data and adhere to a strict schema.
5. Validation and Publication Before publication, the generated reports must be rigorously validated. This involves checking for completeness, accuracy of calculations, and correct formatting. Once validated, the reports must be made publicly available on the execution venue’s website, free of charge, where they must remain accessible for at least two years.

Quantitative Modeling and Data Analysis

The heart of the RTS 27 report lies in its quantitative data tables. These tables provide the granular details that allow for a forensic analysis of execution quality. The regulation specifies the exact fields and structure for nine tables, though not all tables are applicable to every type of venue or instrument. The most critical information is contained within the tables covering price, costs, and likelihood of execution.

The table below details a selection of the most significant data points required within “Table 1 – Price information for each financial instrument,” which forms the foundation of the entire report.

What Is the Core Calculation for Implicit Costs?

One of the most vital calculations is for the “effective spread.” This metric quantifies the implicit cost of trading by measuring the difference between the actual trade price and the midpoint of the best bid and offer (BBO) at the moment an order is received. The formula provides a clear view of price slippage.

For a buy order, the calculation is ▴ Effective Spread = 2 (Execution Price – Midpoint of BBO at time of order)

For a sell order, the calculation is ▴ Effective Spread = 2 (Midpoint of BBO at time of order – Execution Price)

A positive result indicates a cost to the liquidity demander (slippage), while a negative result signifies price improvement. The RTS 27 report requires venues to publish the average of this value across all transactions for an instrument, providing a powerful indicator of execution quality.

Predictive Scenario Analysis

Consider a quantitative hedge fund, “Systemic Alpha,” looking to deploy a new market-neutral strategy focused on European chemical stocks. The strategy relies on frequent, small-to-medium-sized trades and is sensitive to both explicit and implicit transaction costs. The head of execution, Dr. Anya Sharma, tasks her team with performing a deep analysis of two primary execution venues using their latest quarterly RTS 27 reports ▴ “EuroLit,” a traditional lit exchange, and “SI-Chem,” a systematic internaliser specializing in the chemical sector.

The team begins by downloading the voluminous XML reports from both venues’ websites. Their first step is to build a parser to extract and normalize the data for the 50 specific chemical stock ISINs in their strategy’s universe. They focus on three key tables from the reports ▴ Table 1 (Price), Table 3 (Costs), and Table 4 (Likelihood of execution). After several days of data processing, they generate a comparative dashboard.

The initial findings are compelling. EuroLit’s reports show an average effective spread (from Table 1) of 1.2 basis points across the target stocks. In contrast, SI-Chem’s reports show a wider average effective spread of 2.5 basis points. On the surface, EuroLit appears to be the superior choice for minimizing implicit costs.

However, Dr. Sharma pushes the team to look deeper. They turn to Table 3, which details explicit costs. EuroLit operates on a maker-taker model, and for Systemic Alpha’s aggressive, liquidity-taking orders, the cost is 0.20 basis points. SI-Chem, seeking to attract flow, has zero explicit execution fees for client orders.

When this is factored in, the total cost differential narrows. The analysis then moves to the probability of execution. The team analyzes Table 4, focusing on the “likelihood of execution” for standard order sizes between €10,000 and €50,000. EuroLit shows a 98% likelihood of execution. SI-Chem shows a 99.5% likelihood and, more importantly, a 25% “likelihood of price improvement.” This means that for one in every four trades, SI-Chem provided a price better than the prevailing European Best Bid and Offer (EBBO).

Dr. Sharma models the total cost of execution by combining these factors. She calculates the expected total cost for a €1 million notional portfolio turnover. For EuroLit, the cost is the sum of the average effective spread and the explicit fee ▴ 1.2 bps + 0.2 bps = 1.4 basis points, or €140. For SI-Chem, the calculation is more nuanced.

The cost is the average effective spread, minus the expected gain from price improvement, plus the explicit fee ▴ 2.5 bps – (25% Average Price Improvement) + 0 bps. The team digs back into the raw data to calculate the average size of this price improvement, which they find to be 3.0 basis points. The expected gain from price improvement is therefore 0.25 3.0 bps = 0.75 bps. The total expected cost on SI-Chem is 2.5 bps – 0.75 bps = 1.75 basis points, or €175. Even with the price improvement, SI-Chem appears slightly more expensive.

The final piece of the puzzle comes from a qualitative data point in the report ▴ information on factors that may have affected execution. SI-Chem’s report notes that its liquidity is particularly deep during the first and last hours of the trading day. Dr. Sharma reruns the analysis, filtering the data for only those time periods. The results are starkly different.

During these peak hours, SI-Chem’s average effective spread drops to 1.5 bps and its likelihood of price improvement increases to 40%. The new expected cost on SI-Chem becomes 1.5 bps – (40% 3.0 bps) = 0.3 basis points. This is dramatically lower than EuroLit’s 1.4 bps. Based on this deep, multi-faceted analysis of the RTS 27 data, Systemic Alpha architects a dynamic smart order router.

The system’s default is to route to EuroLit, but during the first and last 60 minutes of the trading day, it automatically shifts all order flow for the chemical stock strategy to SI-Chem. The result over the next quarter is a 60% reduction in total transaction costs for the strategy, an edge gained entirely through the strategic deconstruction of regulatory data.

System Integration and Technological Architecture

The technological architecture required to support RTS 27 reporting is a microcosm of a modern financial data platform. It must be robust, scalable, and capable of handling high-throughput, time-sensitive data with complete accuracy.

• Data Ingestion Layer This is the frontline of the architecture. It consists of listeners and connectors that tap directly into the firm’s core systems. FIX protocol engines capture order and trade messages in real-time from the OMS and matching engine. Market data handlers subscribe to specialized feeds to receive and store a complete history of the order book and BBO quotes for all relevant instruments.
• Time-Series Database The captured data is best stored in a high-performance, time-series database like Kdb+ or a similar technology. This type of database is optimized for storing and querying massive volumes of timestamped data, which is essential for performing the point-in-time lookups required for calculations like the effective spread.
• The Regulatory Calculation Core This is a dedicated application or suite of microservices that contains the business logic for the RTS 27 calculations. It queries the time-series database, performs the complex computations for each instrument and order type, and aggregates the results into the required daily and quarterly metrics. This core must be designed for auditability, with clear logging of all calculation steps.
• XML Generation and Distribution The final component takes the output from the calculation core and formats it into the ISO 20022 XML schema mandated by ESMA. This system must be capable of generating potentially thousands of individual XML files per quarter. An automated distribution module then places these files in the correct public-facing directory on the company’s web servers.

Reflection

The intricate web of data points mandated by RTS 27 provides more than a compliance checklist. It offers a blueprint for a more evolved operational intelligence. By mastering the architecture required to produce these reports, a venue inherently builds a system capable of profound self-analysis.

The same data, when consumed strategically, allows investment firms to dismantle the opaque walls between execution venues and peer inside, transforming regulatory data into a tangible execution advantage. The ultimate question for any market participant is how this new level of transparency can be integrated into their own systems, not as a source of reports to be filed, but as a live feed of market intelligence that refines every single routing decision.