What Specific Data Points Must Be Captured to Prove Best Execution for an Rfq under Rts 28?

Concept

The obligation to demonstrate best execution for a Request for Quote (RFQ) transaction introduces a fundamental tension within market microstructure. An RFQ is an inherently discreet, bilateral negotiation, designed to source liquidity with minimal market impact. Conversely, regulations like MiFID II’s RTS 28 are built upon a foundation of transparency, demanding verifiable data to substantiate execution quality. The challenge, therefore, is to architect a data capture framework that translates the nuanced, often qualitative, decision-making process of an RFQ into a quantitative, auditable trail without compromising the protocol’s strategic purpose.

This is not a simple matter of logging trades. It requires the construction of a complete evidence repository for each RFQ lifecycle. The system must capture the state of the market before the request is sent, document the full range of responses during the quoting window, and record the final execution details with high-fidelity timestamps.

Proving best execution in this context moves beyond a single data point like price; it is about demonstrating that the chosen execution pathway was the most favorable for the client when assessed against a multidimensional set of factors, including cost, speed, and likelihood of execution. The true objective is to build a system that not only satisfies regulatory scrutiny but also creates a powerful feedback loop for optimizing counterparty selection and execution strategy over time.

Demonstrating best execution for RFQs requires a systematic capture of pre-trade, trade-time, and post-trade data to build a complete, auditable narrative of each transaction.

The Anatomy of an Auditable RFQ

To construct a defensible best execution file for an RFQ, one must think like a systems architect designing a database. The goal is to create a relational data structure where every decision point is captured and linked. This begins before the first quote is even requested.

The initial decision to utilize an RFQ protocol over another execution method, such as a lit market order, is the first piece of evidence. It establishes the strategic intent ▴ typically, the management of a large or illiquid order where minimizing information leakage is paramount.

Following this, the selection of counterparties to include in the RFQ is a critical data field. A firm must be able to justify its choice of liquidity providers, connecting it to a documented history of their performance, reliability, and specific strengths in the financial instrument being traded. Each subsequent event ▴ the dispatch of the request, the receipt of each individual quote, any withdrawals or modifications, and the final acceptance ▴ must be timestamped with sufficient granularity to reconstruct the sequence of events with absolute certainty. This detailed log forms the core of the evidence, allowing for a precise analysis of not just the winning quote, but the entire competitive landscape at the moment of execution.

Beyond Price the Execution Quality Factors

While the final transaction price is a primary component, a robust data framework must account for all the best execution factors defined by the regulation. These factors provide the context against which the final execution is judged.

• Price ▴ The price of the winning quote, captured alongside the prices of all competing quotes received.
• Costs ▴ This includes both explicit and implicit costs. Explicit costs are any commissions or fees associated with the transaction. Implicit costs, such as information leakage or market impact, are harder to quantify but are the very reason for using an RFQ. Pre- and post-trade market data can help model this.
• Speed of Execution ▴ The latency between sending the RFQ and receiving responses, as well as the time taken to accept a quote. This data can reveal the efficiency of different counterparties and execution venues.
• Likelihood of Execution and Settlement ▴ This involves capturing data on quote firmness and settlement reliability. A history of failed trades or withdrawn quotes from a specific counterparty is a critical data point in justifying future counterparty selection.
• Size and Nature of the Order ▴ The size of the order relative to typical market depth is a key justification for using an RFQ. The nature of the instrument, such as its liquidity profile or complexity, must also be documented.

Capturing these elements transforms the compliance exercise into a strategic tool. It allows a firm to move from simply justifying a single trade to systematically evaluating and optimizing its execution policies and counterparty relationships, creating a powerful competitive advantage rooted in data.

Strategy

A strategic approach to RFQ data capture extends beyond mere compliance with RTS 28 principles; it involves architecting a system that generates actionable intelligence. The core strategy is to create a longitudinal record of execution quality that informs and refines a firm’s trading process. This requires a granular data model that captures not only the outcome of each RFQ but also the full context of the decision-making process. By systematically recording every stage of the quote lifecycle and the prevailing market conditions, a firm can perform sophisticated Transaction Cost Analysis (TCA) tailored to this specific liquidity sourcing method.

The initial strategic decision is to define the “universe” of data to be captured. This universe must encompass three distinct temporal domains ▴ the pre-trade environment, the intra-trade quoting process, and the post-trade settlement phase. For each domain, specific data points must be identified and logged in a structured format.

This structured data then becomes the foundation for building analytical models that can assess counterparty performance, measure the implicit costs of information leakage, and ultimately validate that the firm’s execution policy is delivering the best possible outcomes for its clients. The strategy is to use data to transform the art of trading into a science of execution.

The strategic collection of RFQ data allows a firm to build a proprietary model of counterparty behavior and execution quality, turning a compliance requirement into a competitive intelligence asset.

A Tiered Data Capture Framework

To implement this strategy, a tiered framework for data capture is essential. This framework organizes the required data points by their function in the execution narrative, ensuring that a complete and coherent picture can be reconstructed for any given trade. This is not just a list of fields; it is a schema for understanding the entire lifecycle of a bilateral negotiation.

Tier 1 Pre-Trade Contextual Data

This layer captures the state of the world at the moment the decision to trade is made. It forms the baseline against which execution quality will be measured. Without this context, a price is just a number, devoid of meaning.

• Order Initiation Timestamp ▴ The precise time the order was received or the investment decision was made.
• Instrument Identifier ▴ A standardized code (e.g. ISIN) for the financial instrument.
• Order Characteristics ▴ The size, side (buy/sell), and any specific instructions from the client.
• Rationale for RFQ Protocol ▴ A documented reason for choosing an RFQ over other execution methods (e.g. order size exceeds 5% of average daily volume, instrument is on an internal illiquid list).
• Counterparty Selection ▴ A list of the liquidity providers selected for the RFQ.
• Counterparty Selection Rationale ▴ Justification for choosing this specific group of counterparties, linked to their historical performance or specific expertise.
• Lit Market Snapshot ▴ The best bid and offer (BBO), volume, and spread on the most relevant public trading venue at the time of RFQ initiation. This is the primary benchmark for price comparison.

Tier 2 Intra-Trade Execution Data

This is the heart of the data capture system, logging every event during the active quoting and execution window. The granularity of timestamps in this tier is of paramount importance.

The following table outlines the critical data points that must be captured for each counterparty involved in the RFQ process. This level of detail is necessary to reconstruct the competitive environment and justify the final execution decision.

Tier 3 Post-Trade and Analytical Data

This final layer documents the conclusion of the trade and provides data for ongoing analysis. It closes the loop on the execution lifecycle and feeds into future pre-trade decisions.

• Settlement Status ▴ Confirmation that the trade settled correctly and on time.
• Settlement Failure Data ▴ Any issues or delays in settlement, linked to the specific counterparty.
• Explicit Cost Data ▴ A full breakdown of any commissions, fees, or taxes associated with the trade.
• Post-Trade Market Snapshot ▴ The BBO and volume on the lit market at various intervals after the trade (e.g. 1 minute, 5 minutes, 30 minutes) to analyze for potential information leakage or market impact.
• TCA Results ▴ The calculated metrics from the firm’s Transaction Cost Analysis model, such as price improvement versus the arrival BBO, spread capture, and performance versus other quotes.

By implementing this comprehensive, tiered data capture strategy, a firm moves from a defensive, compliance-oriented posture to a proactive, data-driven approach to execution. The resulting dataset becomes a core asset, enabling continuous improvement and providing irrefutable proof of the firm’s commitment to achieving the best possible results for its clients.

Execution

The operational execution of an RTS 28-compliant data capture framework for RFQs is a significant systems engineering challenge. It requires the seamless integration of a firm’s Order Management System (OMS), Execution Management System (EMS), and data warehousing capabilities. The objective is to create an automated, non-repudiable log of every event in the RFQ’s lifecycle, from the initial decision to the final settlement. This process must be robust, with high-resolution timestamps and standardized data formats to ensure consistency and allow for effective analysis.

The foundation of this system is the ability to link disparate events into a single, coherent trade narrative. A unique “RFQ Instance ID” must be generated at the moment of initiation. Every subsequent message ▴ each quote request sent, each quote response received, and the final execution report ▴ must carry this identifier.

This allows the system to aggregate all related data points, even when they are communicated asynchronously across different protocols or platforms. The execution framework must also be designed with analysis in mind, structuring the data in a way that facilitates the complex queries required for Transaction Cost Analysis and counterparty performance reporting.

The RFQ Data Capture Workflow

Implementing a robust data capture system involves a clear, step-by-step process that aligns with the flow of a typical RFQ trade. This workflow ensures that all necessary data points are captured at the appropriate stage.

1. Order Ingestion and Justification ▴ The process begins when an order is received by the OMS. The system should automatically flag orders that are candidates for RFQ execution based on pre-defined rules (e.g. size, instrument liquidity). The trader must then select the RFQ protocol and provide a structured justification, which is logged against the order.
2. Counterparty Selection and RFQ Dispatch ▴ The trader selects a list of counterparties from the EMS. The system logs the selected list and the timestamp. The EMS then dispatches the RFQ, and the system records the precise timestamp for each outbound message to each counterparty.
3. Response Aggregation and Monitoring ▴ As counterparties respond, the EMS receives their quotes. Each quote is logged with its price, size, and the timestamp of its arrival. The system populates a real-time dashboard that displays all competing quotes alongside the prevailing lit market benchmark, which is continuously updated.
4. Execution and Confirmation ▴ The trader executes against the chosen quote. The system logs the execution timestamp, the winning counterparty, the executed price, and size. A confirmation message (e.g. a FIX Execution Report) is sent and received, and its details are logged.
5. Data Enrichment and Warehousing ▴ The complete trade record, now linked by the RFQ Instance ID, is passed to a central data warehouse. Here, it is enriched with additional data, such as the calculated TCA metrics and post-trade market data snapshots. This enriched record becomes the final, immutable evidence file for the trade.

A Simulated RFQ Data Log

To illustrate the required level of granularity, the following table simulates a data log for a single RFQ instance. This demonstrates how different events and data points are captured and linked together to form a complete audit trail. The timestamps are presented in ISO 8601 format with microsecond precision, which is a critical requirement for accurate sequencing and analysis.

This detailed log provides a complete, time-sequenced narrative of the trade. It shows that while CPTY-A offered a better price, the quote was for an insufficient size. CPTY-B provided the best price for the full required size and was chosen for execution.

The price of 175.21 represents a $0.01 improvement per share over the best bid available on the lit market at the time of initiation. This is the level of detail required to construct an unassailable argument for best execution.

Reflection

From Mandate to Mechanism

The intricate data requirements for demonstrating best execution in RFQs should not be viewed as a static compliance burden. Instead, they provide the schematic for building a dynamic execution quality system. The true value of this detailed data capture lies in its potential to create a feedback loop, transforming raw log files into a predictive intelligence layer.

Each trade, with its rich context of competing quotes and market conditions, becomes a training set for a more sophisticated execution model. The framework ceases to be about proving past performance and evolves into a mechanism for refining future strategy.

This perspective shifts the focus from simple data collection to knowledge creation. The assembled data allows an institution to move beyond asking “Did we get the best price?” to addressing more profound questions. Which counterparties are consistently fastest to respond in volatile markets? Is there a pattern of information leakage associated with including certain responders in an RFQ?

How does our execution quality on RFQs compare to a volume-weighted average price (VWAP) strategy on a lit venue under similar conditions? Answering these questions requires a commitment to transforming data into insight, building an operational framework that learns, adapts, and ultimately provides a persistent, structural advantage in the market.