What Are the Data Requirements for a Smart Order Router under the New MiFIR Rules?

Concept

The implementation of the updated Markets in Financial Instruments Regulation, commonly known as MiFIR, fundamentally re-architected the role of a Smart Order Router (SOR). An SOR is no longer a mere efficiency tool for sourcing liquidity at the best available price. It has been systematically redefined as a core component of a firm’s regulatory compliance and data-generation apparatus.

The primary mandate of MiFIR in this context is to enforce and evidence the principle of “best execution.” This requires the SOR to operate within a framework of extreme transparency, where every routing decision is not just made, but is also recorded, justified, and auditable. The data requirements imposed by the regulation are the engineering specifications for this new class of SOR.

At its core, the challenge is one of data integrity and granularity. MiFIR compels an investment firm to prove, with verifiable data, that it has taken all sufficient steps to obtain the best possible result for its clients. This proof is not qualitative; it is quantitative, built upon a foundation of high-frequency data capture across the entire lifecycle of an order. The SOR sits at the epicenter of this data collection process.

It must be designed to capture not only the data points that inform its own routing logic ▴ such as price, volume, and latency ▴ but also a much wider universe of contextual market data. This contextual data provides the necessary evidence to regulators that the chosen execution venue was, in fact, the optimal choice among all available alternatives at that specific moment in time.

The SOR as a Regulated Data Utility

Viewing the SOR as a regulated data utility is the correct architectural starting point. Its function extends beyond simple order routing to include the systematic capture, timestamping, and storage of data sufficient to reconstruct any trade and its surrounding market conditions. The regulations, particularly the Regulatory Technical Standards (RTS) 27 and 28, dictate the specific outputs required.

RTS 27 focuses on the quality of execution from the perspective of the execution venues themselves, while RTS 28 requires investment firms to report on their top five execution venues and the quality of execution achieved. Although recent statements from the European Securities and Markets Authority (ESMA) have indicated a deprioritization of supervisory actions regarding these reports pending further review, the underlying obligation for best execution and the data capture to prove it remains firmly in place.

This transforms the SOR’s data handling requirements from an internal operational concern into a primary regulatory obligation. The system must be capable of ingesting a vast array of pre-trade data, processing it to make a compliant routing decision, and then logging every step of that process with microsecond precision. The data generated by the SOR becomes the raw material for the firm’s mandatory regulatory reporting and internal compliance oversight. Therefore, the design and data architecture of the SOR are inextricably linked to the firm’s ability to meet its legal and regulatory duties under MiFIR.

A Smart Order Router under MiFIR is an evidentiary engine, designed to prove best execution through granular, time-stamped data.

Pre-Trade Transparency Data

The first category of data required by the SOR relates to pre-trade transparency. To make a justifiable routing decision, the SOR must have access to a comprehensive view of the available liquidity across all potential execution venues. This includes regulated markets, multilateral trading facilities (MTFs), organised trading facilities (OTFs), and systematic internalisers (SIs). The data ingested must be sufficient to construct a complete picture of the European Best Bid and Offer (EBBO) for a given instrument.

The SOR’s data feed handlers must be capable of processing and normalizing quote data from all these disparate sources in real-time. This includes not just the top-of-book prices but also the depth of the order book. For the SOR to make an informed decision, it needs to know the available volume at each price level.

Furthermore, the data must be timestamped upon receipt to allow for accurate latency calculations and to provide a verifiable record of the market conditions at the precise moment the routing decision was made. This pre-trade data forms the baseline against which the quality of the final execution will be measured.

At-Trade Decision Logging

The second critical data category is the information generated and logged by the SOR at the moment of execution. This is the core of the evidentiary trail. When the SOR makes a routing decision, it must log not only where it sent the order but also why.

This requires the system to record the state of its own internal logic. For instance, if the SOR is configured to prioritize price, then cost, then speed, it must log the data points related to each of these factors for all considered venues at the time of the decision.

This “decision log” is a fundamental requirement. It must contain highly granular data, including:

• Timestamps ▴ The time the order was received by the SOR, the time the routing decision was made, and the time the order was sent to the execution venue, all with microsecond or better precision.
• Venue Analysis ▴ A record of all execution venues that were considered by the SOR’s logic, not just the one that was chosen.
• Best Execution Factors ▴ The specific data points for each venue that were used in the decision, such as the quoted price, expected transaction costs, and historical likelihood of execution.
• Order Characteristics ▴ The details of the client order itself, including the instrument, size, order type, and any specific client instructions.

This at-trade data provides the direct evidence that the firm’s execution policy was followed and that the routing decision was made in the client’s best interest. Without this detailed log, a firm would be unable to defend its execution quality to regulators.

Strategy

The strategic imperative for an investment firm under MiFIR is to architect a Smart Order Routing system that treats data as its primary asset. The design strategy must shift from a singular focus on execution performance to a dual focus on performance and provable compliance. This means the SOR’s logic and its data architecture must be developed in tandem, with the requirements of regulatory reporting shaping the very way the router analyzes markets and makes decisions. The goal is to build a system where compliance is an emergent property of a well-designed, data-centric execution process.

A successful strategy involves mapping the entire data lifecycle of an order, from its arrival at the firm to its final settlement and reporting. This data-centric approach ensures that at each stage of the process, the necessary data points are being captured, enriched, and stored in a manner that is both operationally useful and regulatorily sound. The SOR is the central node in this data lifecycle, acting as the point of maximum data convergence.

It is where pre-trade market data meets the client’s order, and where the decision to execute is made and recorded. Therefore, the strategy for the SOR must be a strategy for the firm’s entire execution data infrastructure.

Integrating Compliance into the Routing Logic

A key strategic decision is how to integrate the logic of best execution compliance directly into the SOR’s decision-making algorithm. A simplistic SOR might route an order based on the best displayed price. A MiFIR-compliant SOR must operate on a multi-factor model that considers all the best execution factors laid out in the regulation ▴ price, costs, speed, likelihood of execution and settlement, size, nature of the order, and any other relevant considerations. The SOR’s strategy must be to quantify these factors and use them as inputs into a weighted, auditable decision-making process.

This requires the SOR to have access to a rich set of supporting data beyond real-time market data. For example, to properly assess the “costs” factor, the SOR needs access to a database of execution venue fee schedules and an understanding of the potential for market impact. To assess the “likelihood of execution,” it needs access to historical data on the fill rates for different order types at different venues.

The strategy, therefore, involves creating a feedback loop where the results of past executions are used to enrich the data available for future routing decisions. This continuous improvement process is not just good for performance; it is also a key component of demonstrating to regulators that the firm is actively managing and improving its execution quality.

A MiFIR-compliant SOR transforms regulatory constraints into a structured framework for making more intelligent and defensible routing decisions.

Data Categorization for SOR Architecture

To implement this strategy, the data requirements for the SOR can be broken down into three main categories. This categorization provides a clear architectural blueprint for designing the system’s data handling capabilities. Each category represents a different type of data, with different requirements for sourcing, processing, and storage.

The following table outlines these data categories and their strategic importance for the SOR:

How Does the SOR Use This Data Strategically?

The strategic integration of these data types allows the SOR to move beyond simple price-based routing. For example, when a large institutional order arrives, the SOR can execute a more sophisticated routing strategy:

1. Initial Analysis ▴ The SOR ingests the client order (Execution Data) and identifies the instrument (Reference Data). It then pulls all relevant Market Data for that instrument from all connected venues.
2. Venue Scoring ▴ Using its internal logic, the SOR scores each potential venue. It might weigh the displayed price heavily, but it will also use Reference Data to factor in the execution fees for each venue. It can also use historical Execution Data to assess the likelihood of a large order being fully executed without significant market impact at each venue.
3. Intelligent Slicing ▴ Instead of sending the entire order to a single venue, the SOR might decide to slice the order into smaller pieces and route them to multiple venues simultaneously or over a short period. This decision is based on the depth of the order book (Market Data) and historical impact analysis (Execution Data).
4. Audit Trail Generation ▴ Crucially, every step of this process is logged. The SOR records which venues were considered, how they were scored, and the rationale for the final slicing and routing strategy. This generated Execution Data is the proof of compliance.

This strategic approach ensures that the SOR is not just a “dumb” router but an intelligent system that actively manages the trade-off between execution quality and regulatory risk. The data it consumes and generates is the key to achieving both objectives.

Execution

The execution phase of building or specifying a MiFIR-compliant Smart Order Router involves translating the strategic data requirements into a concrete technical architecture and operational workflow. This is where the abstract principles of best execution are embodied in specific data fields, database schemas, and system-to-system communication protocols. The paramount objective is to create a system that captures the right data, at the right time, with the right level of precision, and makes that data available for reporting and analysis.

At this level of detail, the focus is on the granular data elements that the SOR must process and store. The design of the SOR’s data logs is a critical exercise. These logs are the definitive record of the firm’s compliance with its best execution obligations.

They must be immutable, easily queryable, and contain all the information necessary to satisfy a regulator’s request for information. The technical implementation must ensure that this data is captured without adding significant latency to the execution process itself, as speed of execution remains a key factor in achieving best execution.

Core Data Fields for the SOR Audit Trail

The foundation of a compliant SOR is its audit trail. This is more than a simple log of trades; it is a comprehensive record of the entire decision-making process. The following table details the essential data fields that must be captured for every single order processed by the SOR. These fields provide the raw data needed to construct the reports required by regulations like RTS 28 and to conduct internal Transaction Cost Analysis (TCA).

What Is the Data Flow within the Execution System?

Understanding the flow of data is essential for proper implementation. The process can be visualized as a sequence of steps, each with specific data inputs and outputs.

1. Order Ingestion ▴ A client order enters the firm’s Order Management System (OMS). The OMS enriches the order with client and reference data before passing it to the SOR.
2. Pre-Trade Analysis ▴ The SOR receives the order. It immediately queries its market data handlers for a complete view of the lit and dark order books for the specified instrument. It also queries its internal reference data stores for venue costs and historical performance metrics.
3. Routing Decision ▴ The SOR’s core logic processes all this data. It runs its scoring algorithm and makes a routing decision. At this point, it writes a detailed “decision log” entry containing the fields described in the table above. This is the most critical data capture event.
4. Execution and Capture ▴ The SOR routes the order to the selected venue(s). The execution messages (fills) are returned from the venue and captured by the firm’s systems. These fills are used to update the SOR’s audit trail with the final execution price and timestamp.
5. Post-Trade Processing ▴ The completed audit trail record is passed to downstream systems. This includes the firm’s Transaction Cost Analysis (TCA) engine, which analyzes the quality of the execution, and the regulatory reporting engine, which aggregates the data for RTS 28 reports.

This structured flow ensures that data is captured systematically and that a complete, auditable record exists for every order. The SOR is the heart of this process, acting as both the decision-maker and the primary record-keeper.

Data Storage and Retrieval Architecture

The final piece of the execution puzzle is the data storage and retrieval architecture. MiFIR requires that all relevant data be stored for a minimum of five years and be readily accessible to competent authorities upon request. This has significant implications for the firm’s data infrastructure.

The volume of data generated by a modern SOR is immense. A high-frequency trading environment can generate terabytes of log data per day. Therefore, the storage solution must be both scalable and cost-effective. Many firms adopt a tiered storage approach.

The most recent data (e.g. from the last 90 days) is kept in a high-performance, queryable database for immediate access by compliance and trading desks. Older data is migrated to a lower-cost, long-term storage solution, such as a cloud-based data lake. The key is to maintain a unified query interface that can access data from all tiers, allowing a regulator’s request for data from three years ago to be fulfilled efficiently. The choice of database technology is also critical. Time-series databases are often favored for this use case due to their efficiency in storing and querying timestamped data.

Reflection

The integration of MiFIR’s data mandates into a Smart Order Router is a formidable engineering challenge. It forces a systemic view of execution, where regulatory compliance and performance optimization are two facets of the same objective. The exercise of architecting a compliant SOR compels a firm to look deeply at its own operational processes, its data infrastructure, and the very logic it uses to interact with the market. What data does the firm currently capture?

What is missing? How can the feedback loop between execution, analysis, and future decision-making be tightened?

Is Your Data Architecture an Asset or a Liability?

Ultimately, the regulations provide a non-negotiable blueprint for a data-centric execution framework. A firm that approaches these requirements as a mere compliance burden will build a system that is brittle and expensive to maintain. A firm that views them as a specification for a superior execution system will build a strategic asset. The data generated by a well-architected SOR is a source of profound market intelligence.

It can be used to refine execution algorithms, to better understand venue behavior, and to provide clients with a level of transparency that builds enduring trust. The question for every institution is whether its current data architecture is capable of supporting this future, or if it remains anchored to a past where data was a byproduct, not the purpose, of execution.