What Are the Key Differences in Documenting RFQ Best Execution under FINRA and MiFID II Regimes?

Concept

An execution desk operating across New York and London faces a fundamental architectural challenge in unifying its compliance framework. The divergence in regulatory philosophy between the Financial Industry Regulatory Authority (FINRA) and the European Union’s Markets in Financial Instruments Directive II (MiFID II) requires more than a simple overlay of rules. It demands a sophisticated, dual-pronged operational design for documenting best execution, particularly within the bilateral and often opaque Request for Quote (RFQ) protocol. The core of the matter resides in two distinct interpretations of a firm’s duty to its clients.

FINRA’s Rule 5310 establishes a principles-based system centered on the concept of “reasonable diligence.” This framework requires a firm to construct a defensible narrative, demonstrating that the price obtained for a client was as favorable as possible under the prevailing market conditions. The documentation serves as evidence for a qualitative judgment. It is an attestation of professional diligence, where the firm’s process and market expertise are scrutinized.

The system trusts the firm to police itself, provided it can produce a robust, logical record of its decision-making process upon review. The burden of proof lies in the coherence and thoroughness of the documented rationale.

The essential difference lies in whether the documentation aims to prove a diligent process or to provide raw data for systemic analysis.

Conversely, MiFID II operates on a foundation of prescriptive, data-centric verification. It mandates that firms take “all sufficient steps” to achieve the best possible result, a subtle but meaningful elevation from FINRA’s “reasonable diligence.” This obligation is substantiated through extensive data collection and public reporting, as outlined in Regulatory Technical Standards (RTS) 27 and 28. Here, the documentation is not merely a narrative but a dataset. It is designed to provide regulators and the public with the quantitative evidence needed to assess execution quality across the market systematically.

The system is architected to externalize proof, shifting the focus from a firm’s internal judgment to its verifiable data output. For an RFQ, this means every quote solicited, its timestamp, and the rationale for the winning bid must be captured with machine-like precision, ready for aggregation and analysis.

Therefore, the challenge for a global head of trading is to design a documentation workflow that satisfies both masters. The system must be capable of generating a qualitative, defensible story for FINRA auditors while simultaneously producing a structured, quantitative data stream for MiFID II reporting. One regime demands a lawyer’s brief; the other requires an engineer’s log file. Building a single, elegant architecture to produce both without creating redundant, resource-intensive processes is the central strategic objective.

Strategy

Developing a unified strategy for RFQ best execution documentation under both FINRA and MiFID II requires architecting a compliance framework that accommodates two fundamentally different regulatory philosophies. The optimal approach involves creating a core data capture and decision-logging process that is comprehensive enough to satisfy MiFID II’s prescriptive requirements, from which the narrative-driven documentation for FINRA can be extracted. This strategy treats MiFID II’s stringent data-centric model as the superset of requirements, ensuring the granular details are always available to construct the qualitative justification demanded by FINRA.

A Bifurcated Philosophy on Proof

The strategic divergence originates in what each regulator considers sufficient proof of best execution. FINRA’s Rule 5310 is built on a “facts and circumstances” analysis, empowering firms to use their market expertise to navigate complex environments like the debt securities market. The strategy for FINRA compliance is to build a robust, repeatable process for demonstrating “reasonable diligence.” This involves documenting the consideration of several key factors that justify the execution outcome.

MiFID II, on the other hand, demands a more systematic and evidentiary approach. The directive compels firms to establish an order execution policy that includes, for each class of instrument, the specific venues and factors affecting the choice of execution. The strategy here is one of data integrity and transparency.

It is about proving that “all sufficient steps” were taken by making the underlying data available for scrutiny. This is less about justifying a single outcome and more about demonstrating a consistently applied, data-driven process over time.

The following table illustrates the core strategic differences in approach:

How Should a Firm Structure Its Execution Policy?

A global firm’s best execution policy must be a modular document, with a core global policy supplemented by regional addenda that address the specific requirements of FINRA and MiFID II. This structure prevents contradictions and ensures operational efficiency.

1. Global Foundation Policy This core document should define the firm’s universal principles of best execution. It will outline the execution factors the firm considers paramount, such as price, costs, speed, likelihood of execution, size, and nature of the order. This section establishes a consistent firm-wide philosophy.
2. MiFID II Compliance Module This section details the “sufficient steps” and data architecture. It must specify the process for selecting, monitoring, and reviewing execution venues (including counterparties in an RFQ). It will define the data fields to be captured for every RFQ process (e.g. timestamps, all quotes received, rejection reasons) and the methodology for the annual RTS 28 report. This module is the data-collection engine of the entire framework.
3. FINRA Compliance Module This module translates the data captured under the MiFID II framework into the narrative required by FINRA. It will outline the procedure for conducting and documenting the “regular and rigorous” quarterly reviews. It will specify how the firm uses the captured data to demonstrate that the “reasonable diligence” factors ▴ such as the character of the market and the number of markets checked ▴ were properly evaluated for each transaction type.

By treating MiFID II’s data requirements as the baseline, a firm ensures it always has the necessary evidence to construct the qualitative arguments required by FINRA.

This strategic architecture ensures that a trader executing an RFQ for a corporate bond in London and another trader executing a similar trade in New York are operating from a shared playbook. The underlying data capture is identical. The subsequent use and reporting of that data are tailored to the specific regulatory audience, creating a system that is both robust and efficient.

Execution

The execution of a compliant RFQ documentation process under the dual regimes of FINRA and MiFID II is an exercise in operational precision. It requires a system that captures every relevant data point at the moment of the trade, stores it logically, and allows for its flexible retrieval and analysis. The architecture must serve two distinct masters ▴ the data-hungry, systematic analysis required by MiFID II’s RTS 28, and the principles-based, narrative justification required by FINRA’s Rule 5310 auditors.

The Operational Playbook an Integrated RFQ Documentation Workflow

For a trading desk to function efficiently, the documentation process cannot be an afterthought. It must be integrated directly into the trading workflow, ideally through the Order Management System (OMS) or Execution Management System (EMS). The following steps outline a unified operational playbook for a single RFQ transaction:

• Step 1 Pre-Trade Justification Before initiating the RFQ, the trader must document the rationale for selecting the counterparties to be included in the inquiry. This is a critical step for both regimes. For FINRA, this demonstrates diligence in “ascertaining the best market.” For MiFID II, this is part of demonstrating that the choice of “execution venues” was appropriate. The OMS should require the trader to select from a predefined list of rationales (e.g. ‘Known liquidity provider in this asset,’ ‘Best historical response rate,’ ‘Required for size’).
• Step 2 Automated Data Capture During RFQ Once the RFQ is sent, the system must automatically log all relevant data points without manual intervention. This is the core of the MiFID II data-gathering requirement. Key fields include ▴ Client ID, Order ID, Instrument Identifier (ISIN/CUSIP), Timestamp of RFQ initiation, List of solicited counterparties, Timestamp of each response, Quoted price and size from each respondent, and Timestamp of any quote withdrawal or expiry.
• Step 3 Execution Decision And Rationale Logging Upon receiving the quotes, the trader selects the winning counterparty. The system must record the execution timestamp, final price, and size. Crucially, if the selected quote is not the best price, the system must force the trader to provide a justification from a structured dropdown menu. Reasons could include ‘Better likelihood of execution,’ ‘Size improvement,’ or ‘Faster settlement.’ This directly addresses MiFID II’s requirement to consider factors beyond price and provides concrete evidence for FINRA’s qualitative review.
• Step 4 Post-Trade Data Aggregation The captured data for the individual trade is fed into a centralized compliance database. This database is structured to serve two purposes. It allows for the aggregation of data by instrument class for the annual MiFID II RTS 28 report. It also allows compliance officers to query the data on a trade-by-trade or security-by-security basis to prepare for a FINRA “regular and rigorous” review.

Quantitative Modeling and Data Analysis

The output of this operational playbook is a rich dataset that can be modeled for both regulatory and internal performance analysis. The following tables provide a simplified illustration of how the same trade would be documented to meet the distinct needs of each regime.

For a FINRA review, the focus is on demonstrating a thoughtful and diligent process. The documentation would be presented to tell a story of diligence.

For MiFID II, the same trade data is structured for quantitative analysis as part of the firm’s broader execution quality monitoring and eventual RTS 28 reporting.

A well-designed system captures data once and allows it to be presented in multiple formats to satisfy distinct regulatory requirements.

What Is the Ultimate Goal of This Documentation?

The ultimate goal is to create a single, auditable system of record. This system must be robust enough to withstand the scrutiny of a FINRA examiner asking for the story behind a trade and automated enough to feed the vast data requirements of MiFID II reporting without manual remediation. By building the architecture around the more granular, data-intensive requirements of MiFID II, a firm ensures it has the raw material necessary to construct the qualitative, principles-based arguments required by FINRA. This integrated approach transforms compliance from a burdensome, duplicative task into a single, efficient, and data-driven process that enhances both regulatory adherence and internal performance analysis.

Reflection

The examination of FINRA and MiFID II documentation protocols reveals a fundamental divergence in regulatory trust and methodology. One system is built upon the premise of professional judgment, requiring a firm to articulate its diligence. The other is built upon data-driven verification, requiring a firm to expose its process to systemic scrutiny. The operational challenge is clear.

Yet, the deeper question for any institutional leader is how to move beyond mere compliance. How can the architecture required to satisfy these disparate regimes be engineered not as a cost center, but as a source of strategic intelligence? When your system can simultaneously construct a compelling narrative and generate pristine analytical data from a single event, you have not just built a compliance tool. You have created a unified lens through which to view your own execution quality, turning a regulatory mandate into a competitive advantage.