What Are the Specific Data Requirements for Proving Best Execution in an RFQ Trade under MiFID II?

Concept

The mandate to prove best execution for a Request for Quote (RFQ) trade under MiFID II presents a fundamental architectural challenge. It requires reconciling a bilateral, often discreet, liquidity sourcing protocol with a regulatory framework architected for the multilateral transparency of lit order books. Your operational objective is to construct a defensible, data-rich narrative demonstrating that for a specific moment in time, for a particular financial instrument, the executed trade represented the best possible outcome for your client. This is a profound undertaking that moves far beyond a simple price comparison.

At its core, the regulatory requirement compels your firm to build a system of record that captures not just the ‘what’ of the trade ▴ the price, the size, the counterparty ▴ but the ‘why’. Why was the RFQ protocol chosen over a central limit order book? Why were these specific counterparties solicited for a quote? Why was the winning quote selected over others?

The data requirements are therefore a blueprint for constructing this justification. They are the granular, empirical evidence that substantiates your firm’s execution policy and the professional judgment of your traders. The challenge is amplified in the RFQ context, where the most valuable data points, such as the identity of competing bidders and their pricing, are ephemeral and exist only within the closed loop of the query.

A firm’s data architecture must capture the full context of an RFQ trade, transforming a private negotiation into a transparently justifiable event for regulatory scrutiny.

Proving best execution is an exercise in demonstrating procedural integrity. It is the methodical collection and analysis of data points across the entire lifecycle of the order, from the initial decision to seek liquidity via RFQ to the final settlement of the trade. The European Securities and Markets Authority (ESMA) and corresponding national competent authorities demand that firms take “all sufficient steps” to achieve the best outcome. This standard requires a systematic, evidence-based approach.

Your data is your evidence. Without a robust, auditable trail of data, your firm’s claim to have achieved best execution remains an unsubstantiated assertion, vulnerable to regulatory challenge.

The data you collect serves two primary functions. Internally, it provides the feedback loop for refining your execution policies and evaluating the quality of your counterparty relationships. Externally, it forms the body of proof required for regulatory compliance reports, such as those derived from RTS 27 and RTS 28, and for responding to ad-hoc inquiries from clients and regulators.

The system you design must therefore be dual-facing, serving both internal performance optimization and external compliance validation. It is the foundational layer upon which your entire execution framework rests.

Strategy

A strategic approach to MiFID II data requirements for RFQ trades involves architecting a data-centric execution policy that is both proactive and defensive. The objective is to embed data collection into the very fabric of the trading workflow, ensuring that the evidence required for justification is a natural byproduct of the execution process itself. This strategy rests on a clear understanding of the MiFID II best execution factors and their specific application to the RFQ protocol.

Deconstructing the Best Execution Factors

MiFID II, under Article 27, moves the definition of best execution beyond the singular focus on price. It mandates a holistic assessment based on a set of weighted factors. Your strategy must be to define how your firm weighs these factors for different instrument classes and client types, and then to build a data capture process that records the state of each factor for every RFQ trade.

The primary execution factors include:

• Price This remains a dominant factor. The core data requirement is to capture the price of the winning quote. To provide context, you must also capture the prices of all losing quotes received in response to the RFQ. This comparative data is the most direct evidence of price competitiveness.
• Costs This encompasses all explicit and implicit costs associated with the trade. Explicit costs include any commissions or fees paid to the venue or counterparty. Implicit costs, such as information leakage or market impact, are harder to quantify but are a critical consideration, especially for large orders. Your data strategy must include a methodology for estimating and recording these costs.
• Speed of Execution In the RFQ context, this is measured by the time elapsed between sending the RFQ and receiving quotes, and the time between accepting a quote and receiving a fill confirmation. This data helps justify decisions made in fast-moving markets.
• Likelihood of Execution and Settlement This qualitative factor becomes quantifiable through data. It involves tracking the reliability of counterparties. Data points such as the frequency with which a counterparty provides a quote when solicited, and their fill rates on accepted quotes, build a historical record that justifies their inclusion in future RFQs.
• Size and Nature of the Order A large or complex order may justify the use of an RFQ to minimize market impact, even if a slightly better price is theoretically available on a lit market. Your data must capture the rationale for choosing the RFQ protocol, linking it to the specific characteristics of the order.

Architecting the Data Capture Framework

The strategic implementation requires a two-pronged data capture framework ▴ pre-trade and post-trade. This ensures that the context for the decision and the outcome of the decision are both recorded with high fidelity.

What Is the Pre-Trade Justification File?

Before an RFQ is even initiated, a data file should be created. This is the foundational record that justifies the choice of execution methodology. It is the system’s defense of the trader’s initial decision.

The pre-trade data file serves as the empirical justification for selecting the RFQ protocol over alternative execution methods for a specific order.

This “Justification File” should contain:

1. Order Characteristics The instrument, desired size, side (buy/sell), and any specific client instructions.
2. Market Snapshot A snapshot of the prevailing market conditions on relevant lit markets at the moment the decision is made. This should include the best bid and offer (BBO), displayed depth, and recent trade prices. This data provides a crucial benchmark against which the RFQ results can be compared.
3. Venue Selection Rationale A structured data field, often a pre-defined code or a brief text entry, that documents why the RFQ protocol was chosen. Examples include ‘Large-in-Scale Order,’ ‘Illiquid Instrument,’ or ‘Minimizing Market Impact.’
4. Counterparty Selection Logic A record of which counterparties were selected for the RFQ and the justification for their inclusion, based on historical performance data (e.g. response rates, pricing competitiveness).

How Should Post-Trade Analysis Be Structured?

Once the trade is complete, the post-trade analysis begins. The goal is to compare the executed trade against the pre-trade market snapshot and the other quotes received. This is where the firm proves the quality of the execution outcome.

The post-trade data set must integrate the pre-trade file with the results of the RFQ process, creating a complete, end-to-end record. This involves systematically comparing the winning quote against all other quotes received on the key execution factors. A scoring system can be developed to formalize this comparison, weighting the factors according to the firm’s execution policy. This creates a quantitative and repeatable process for evaluating execution quality, which is essential for both internal oversight and regulatory reporting.

Execution

The execution of a MiFID II compliant data strategy for RFQ trades is a matter of high-fidelity data engineering. It requires the implementation of specific data schemas, system-level logging, and analytical frameworks to transform regulatory principles into an auditable operational reality. The focus is on creating an immutable, timestamped record of every decision and data point in the RFQ lifecycle.

The Operational Playbook for Data Capture

A robust system for proving best execution is built on a detailed operational playbook that dictates exactly what data is captured, when it is captured, and how it is stored. This process must be automated to the greatest extent possible to ensure consistency and eliminate human error. The playbook can be broken down into distinct stages, each with its own set of critical data requirements.

Stage 1 Pre-Trade Data Logging

This stage concerns the capture of all relevant information at the moment the trader decides to use an RFQ. The system must automatically log this data without requiring manual intervention beyond the initial order parameters.

The following table outlines the essential pre-trade data points. This data forms the baseline against which the execution will be judged.

Stage 2 In-Flight RFQ Data Logging

While the RFQ is active, the system must track all events and communications. This data is vital for demonstrating that the process was fair and efficient.

Capturing in-flight RFQ data provides a transparent timeline of the negotiation, detailing the speed and responsiveness of all solicited counterparties.

• RFQ Sent Timestamp For each counterparty, the precise time the request was sent.
• Quote Received Timestamp For each counterparty that responds, the precise time their quote was received.
• Quote Details For each quote received, the full details must be logged ▴ counterparty ID, price, quantity, and any specific conditions attached to the quote.
• No-Quote Events For each counterparty that was solicited but did not provide a quote, this event must be logged. This is important for evaluating counterparty performance over time.

Stage 3 Post-Trade Execution Quality Analysis

After a quote is accepted and the trade is executed, the final and most complex stage of data analysis occurs. This involves comparing the chosen execution against all available alternatives at the time of the trade. The output of this analysis is the core of the best execution proof.

Quantitative Modeling and Data Analysis

The data collected must be fed into a quantitative framework to produce a clear, defensible report. The following table provides a simplified model for a post-trade Execution Quality Analysis (EQA) report for a hypothetical RFQ trade.

What Does a Post-Trade EQA Report Contain?

This report synthesizes all collected data into a comparative analysis. It is the ultimate document of record for the trade.

This quantitative model provides an objective basis for the execution decision. The ‘Overall Score’ would be calculated using a firm-defined weighting of the different execution factors. This model demonstrates to a regulator that the decision was systematic and data-driven, considering all facets of the execution quality as required by MiFID II. It transforms a subjective decision into a structured, auditable process.

Reflection

The architecture you build to satisfy these data requirements is a direct reflection of your firm’s commitment to its clients and its respect for the regulatory framework. It is a system designed to validate every execution decision with empirical evidence. The process of constructing this system forces a deep introspection into your firm’s trading protocols and counterparty relationships.

Does your current data infrastructure merely record trades, or does it provide the context necessary to defend them? The answer to that question defines your firm’s operational readiness and its strategic position in a market where data is the ultimate arbiter of compliance.