Can the Data from RTS 27 Reports Be Used to Demonstrate Adherence to the Code’s Last Look Principles?

Concept

An institution’s ability to demonstrate adherence to market codes is a direct reflection of its operational architecture. The assertion that data from Regulatory Technical Standard 27 (RTS 27) reports can be used to substantiate conformity with the FX Global Code’s principles on last look is a query into the interoperability of two distinct, yet philosophically aligned, frameworks. One is a mandated public disclosure regime born from MiFID II, designed to bring transparency to execution quality.

The other is a principles-based code of conduct, established to foster integrity and fairness in the global wholesale foreign exchange market. The core of the issue resides in understanding the data’s inherent capabilities and its limitations when mapped against the behavioral expectations outlined in the Code.

RTS 27 reports provide a quantitative snapshot of execution performance from a specific venue. They offer metrics on price, costs, speed, and the likelihood of execution for individual financial instruments. These are the raw materials, the elemental data points that describe the observable outcomes of a transaction lifecycle. They document what happened, when it happened, and at what cost.

For an entity employing last look, these reports offer a foundational layer of transparency, publishing aggregated data that can be scrutinized by clients and regulators alike. The reports, in essence, create a public ledger of a venue’s execution characteristics.

RTS 27 reports offer a public, quantitative baseline of execution metrics, while the FX Global Code provides the ethical and behavioral framework for interpreting those metrics in the context of last look.

The FX Global Code, particularly its Principle 17, operates on a higher plane of abstraction. It addresses the intent and fairness of the last look process. The Code is concerned with the ‘why’ behind an execution outcome. It dictates that last look should be a risk control mechanism for price and validity checks, not a tool for generating revenue from information asymmetry.

It proscribes trading activity that utilizes information from a client’s request during the last look window. This principle delves into the conduct of the market participant, a dimension of behavior that raw quantitative data alone cannot fully illuminate.

Therefore, the challenge is one of translation. Can the ‘what’ described by RTS 27 data be effectively used to infer the ‘why’ required by the FX Global Code? The data can show that a trade was rejected or that the price slipped between the request and the final execution. It cannot, on its own, prove that the rejection was a legitimate risk control measure or that the price slippage was the result of fair, symmetrical application of a pre-disclosed policy.

This is the critical gap. Using RTS 27 data to demonstrate adherence is an exercise in building a robust analytical framework that correlates statistical outcomes with the behavioral principles of the Code. It requires moving from data reporting to data intelligence.

Strategy

A strategic framework for leveraging RTS 27 data to monitor last look practices requires a systematic approach that transcends simple data collection. The objective is to construct an analytical model that uses the quantitative outputs of RTS 27 to build a mosaic of a liquidity provider’s behavior, which can then be assessed against the principles of the FX Global Code. This strategy is predicated on data aggregation, the definition of specific key performance indicators (KPIs), and a structured comparative analysis.

Data Aggregation and Normalization

The first strategic step is the aggregation and normalization of RTS 27 reports. These reports are published by individual execution venues, including Systematic Internalisers and other liquidity providers. A significant challenge is the lack of a standardized format; reports can be in XML or CSV, with varying interpretations of the required fields.

An effective strategy must therefore begin with the implementation of a system capable of ingesting these disparate reports and transforming them into a unified, analyzable dataset. This normalized database becomes the foundational asset upon which all subsequent analysis is built.

This process involves mapping the various fields from different provider reports to a single, coherent schema. Key data points to extract and standardize include:

• Instrument Identification ▴ Ensuring consistent identification of currency pairs across all reports.
• Timestamps ▴ Normalizing all timestamps to a common standard (e.g. UTC) to allow for accurate latency calculations.
• Price and Cost Data ▴ Aggregating data from RTS 27 Tables 3, 4, and 5, which detail intra-day prices, end-of-day prices, and costs.
• Execution Likelihood Data ▴ Compiling information from Table 6, which provides insight into the number of orders or requests received, accepted, and executed.

Developing Key Performance Indicators for Last Look

With a normalized dataset, the next step is to develop specific KPIs that act as proxies for the behaviors addressed in the FX Global Code’s Principle 17. These KPIs are derived from the raw RTS 27 data but are designed to flag statistical anomalies that may warrant further investigation. The goal is to translate the Code’s principles into measurable metrics.

Key KPIs include:

1. Hold Time Analysis ▴ While RTS 27 does not explicitly provide the ‘hold time’ of a last look window, it does provide data on the speed of execution. By analyzing the distribution of execution speeds, a firm can identify outliers. A consistently long execution time for a particular provider, especially when correlated with trade rejections, could indicate that the last look window is being used for purposes other than a simple price and validity check.
2. Price Slippage Analysis ▴ RTS 27 reports contain detailed price information. A critical KPI is the measurement of price slippage, which is the difference between the price at the time of the trade request and the final execution price. The analysis should focus on the symmetry of this slippage. Does the liquidity provider pass on price improvements as readily as they pass on price deteriorations? Asymmetrical slippage, where the client is consistently disadvantaged, is a strong indicator of unfair last look practices.
3. Rejection Rate Correlation ▴ The likelihood of execution data in RTS 27 Table 6 is fundamental. This KPI involves correlating trade rejection rates with market volatility. While a higher rejection rate during volatile periods can be a legitimate use of last look as a risk control, a consistently high rejection rate in stable market conditions, or a rate that is an outlier compared to peers, requires justification from the liquidity provider.

How Can Data Reveal Adherence to the Code?

The core of the strategy lies in using these KPIs within a comparative framework. By benchmarking liquidity providers against each other using the normalized RTS 27 data, a firm can identify which providers are statistical outliers. This data-driven approach moves the conversation with a provider from a subjective discussion about fairness to an objective review of their execution statistics. A provider with significantly longer hold times, more asymmetrical slippage, and higher rejection rates than its peers can be asked to provide a qualitative explanation for these discrepancies, referencing their disclosed last look policies.

The following table illustrates how the principles of the FX Global Code can be mapped to the data available in RTS 27 reports, forming the basis of this strategic analysis.

This strategic framework allows an institution to build a defensible, evidence-based process for evaluating liquidity provider adherence to the FX Global Code. It transforms the public, and often cumbersome, RTS 27 data into a powerful internal governance and risk management tool.

Execution

The execution of a robust monitoring system for last look practices using RTS 27 data is a multi-stage process that requires significant technical and analytical capabilities. It moves from the theoretical strategy to the practical implementation of data pipelines, quantitative models, and reporting dashboards. This is where the architectural vision is translated into a functional, operational reality.

Quantitative Modeling of Last Look Behavior

The central pillar of the execution phase is the development of quantitative models to analyze the aggregated RTS 27 data. These models are designed to detect patterns and outliers that would be invisible in a simple review of the raw reports. The analysis must be granular, systematic, and statistically rigorous.

Hold Time and Latency Profile Analysis

While RTS 27 does not provide a direct “hold time” field, a proxy can be engineered by analyzing the “speed of execution” metrics provided in the reports. The first step is to create a latency profile for each liquidity provider (LP). This involves plotting a distribution of their execution speeds for a given currency pair and trade size.

A detailed quantitative analysis of RTS 27 data, focusing on hold time, price slippage, and rejection rate correlations, is the primary mechanism for identifying potential deviations from the FX Global Code’s last look principles.

The table below presents a hypothetical analysis of execution speed data extracted and aggregated from multiple RTS 27 reports for a standard EUR/USD transaction of 1 million.

In this model, LP C is immediately identifiable as an outlier. Its median execution speed is significantly higher, but more telling are the 95th and 99th percentile speeds. These figures suggest that while many trades are executed relatively quickly, a material number of trades are being held for an exceptionally long time. This long tail distribution is a quantitative red flag.

It provides a concrete data point to begin a discussion with LP C about the nature of their last look window and why certain trades experience such high latency. This data allows a firm to ask a precise question ▴ “What are the circumstances under which 5% of our trade requests are taking longer than 150 milliseconds to process?”

Symmetrical Price Slippage Modeling

The next critical model is the analysis of price slippage. This model assesses the fairness of the price check during the last look window. It requires data on the price at the time of the request and the final executed price.

While RTS 27 provides aggregated price data, a truly effective analysis often requires supplementing this with the firm’s own transaction cost analysis (TCA) data for greater granularity. The model calculates slippage for every trade and then analyzes the distribution of that slippage.

The key is to test for symmetry. A fair last look process, applied consistently as a risk control, should result in a roughly symmetrical distribution of slippage around zero. The provider should be just as likely to pass on a price improvement (positive slippage for the client) as they are to pass on a price deterioration (negative slippage for the client).

What Does Asymmetrical Slippage Indicate?

Asymmetrical slippage, where the distribution is skewed towards negative outcomes for the client, strongly suggests that the last look process is being used opportunistically. It implies that the provider is rejecting trades when the market moves against them (protecting themselves from a loss) but holding the client to the original price when the market moves in their favor (capturing the profit for themselves). This directly contravenes the spirit and letter of the FX Global Code.

An analysis might produce the following summary statistics:

• LP A ▴ Mean Slippage ▴ +0.01 pips; Skewness ▴ 0.05 (Symmetrical)
• LP B ▴ Mean Slippage ▴ -0.15 pips; Skewness ▴ -1.2 (Highly Asymmetrical)

The data for LP B provides quantitative evidence of a potential issue. The negative mean slippage and high negative skewness are objective data points that demonstrate the client is, on average, receiving worse execution from this provider due to their last look practices.

Building an Internal Compliance Dashboard

The final execution step is to operationalize this analysis by building an internal compliance dashboard. This tool is for the Best Execution Committee, compliance officers, and traders. It should visualize the KPIs and model outputs in an intuitive way. The dashboard should allow users to:

1. View LP Scorecards ▴ A summary view for each liquidity provider, showing their key metrics (latency profile, slippage symmetry, rejection rates) against the peer group average.
2. Set Alert Thresholds ▴ The system should allow compliance to set thresholds for each KPI. If a provider’s 99th percentile hold time exceeds 200ms, or their slippage skewness falls below -1.0, an automated alert is generated for review.
3. Drill Down into Data ▴ Users should be able to click on an anomalous result and see the underlying aggregated data that generated it. While RTS 27 is aggregated, the ability to see the data for a specific instrument on a specific day is crucial for investigating issues.

By executing this three-part process ▴ quantitative modeling, deep analysis of specific behaviors like slippage, and the creation of an operational dashboard ▴ a firm can transform the raw, public data of RTS 27 into a sophisticated, internal system for monitoring adherence to the FX Global Code. It creates a structured, defensible, and data-driven process for ensuring fair treatment from liquidity providers.

Reflection

The successful integration of RTS 27 data into a compliance framework for the FX Global Code is more than a regulatory exercise. It represents a fundamental shift in how an institution approaches its own operational intelligence. The data itself is a commodity, publicly available and often unwieldy.

The true value is unlocked in the architecture of the analytical system built upon it. This system becomes a lens, focusing disparate data points into a coherent picture of counterparty behavior.

Consider the framework not as a static compliance tool, but as a dynamic component of your firm’s overall liquidity sourcing strategy. The insights generated from this analysis should feed directly back into your execution protocols. Which providers offer genuine risk-transfer pricing?

Which counterparties exhibit patterns that increase implicit trading costs? The answers to these questions, derived from a rigorous and systematic analysis, allow for the intelligent routing of orders and the cultivation of a higher-quality liquidity pool.

Ultimately, the question of adherence to the Code is a question of trust. The framework detailed here provides a method for verifying that trust with quantitative evidence. It transforms the principles of the Code from abstract ideals into measurable benchmarks. The challenge now is to look at your own data architecture.

Does it merely collect information, or does it generate intelligence? The answer will define your firm’s capacity to navigate the complexities of modern market structure and secure a durable competitive edge.