Rafael Torres had spent twenty-two years in financial services before going independent, and he had learned one thing above all others: the regulations that look simple in the directive text are the ones that cost firms the most money in practice.
In This Chapter
- Learning Objectives
- 18.1 Introduction: The Weight of Best Execution
- 18.2 MiFID II and MiFIR: The Legislative Architecture
- 18.3 Transaction Reporting Under Article 26 MiFIR
- 18.4 Best Execution Under Article 27 MiFID II
- 18.5 Pre-Trade Transparency
- 18.6 Post-Trade Transparency
- 18.7 The MiFID II Venue Landscape
- 18.8 UK MiFID II Post-Brexit: The Wholesale Markets Review
- 18.9 Technical Implementation: ISO 20022 and Algorithmic Trading Identification
- 18.10 RegTech for MiFID II Compliance
- 18.11 Python Implementation: Best Execution Analysis
- 18.12 MiFID II Compliance: Common Failure Modes
- 18.13 Summary
- Key Terms
Chapter 18: MiFID II, MiFIR, and Best Execution Compliance
Learning Objectives
By the end of this chapter, you will be able to:
- Explain the scope and architecture of MiFID II and MiFIR, including the key changes from MiFID I
- Describe the transaction reporting obligations under Article 26 MiFIR, including the 65-field reporting template, TVTIC, and LEI requirements
- Articulate the five best execution factors under Article 27 MiFID II and the role of RTS 27 and RTS 28 reporting
- Map the EU venue landscape — Regulated Markets, MTFs, OTFs, SIs, and dark pools — and understand pre- and post-trade transparency obligations
- Identify the key divergences between EU MiFID II and UK MiFID II post-Brexit, including FCA Wholesale Markets Review outcomes
- Implement a basic best execution analysis tool in Python using arrival price slippage and VWAP benchmarking
18.1 Introduction: The Weight of Best Execution
Rafael Torres had spent twenty-two years in financial services before going independent, and he had learned one thing above all others: the regulations that look simple in the directive text are the ones that cost firms the most money in practice.
He thought about this in January 2023, sitting across a conference table from the Cornerstone Financial Group's head of European compliance, a meticulous Scottish lawyer named Fiona Mackenzie. Cornerstone — a fictional composite of the multi-jurisdictional institutions Rafael typically served — had just received an FCA thematic review letter. The topic: best execution under MiFID II Article 27.
"We have a best execution policy," Fiona said, sliding a document across the table. "We published our RTS 28 report. We have SmartOrder Routing."
Rafael flipped through the policy document. It was forty-two pages long and had last been updated in October 2019. The RTS 28 report had been published in April — three months late.
"This is a good start," Rafael said carefully. "But what the FCA will want to see is not the policy. They want to see the evidence that the policy is being followed. They want venue analysis. They want execution quality metrics. They want to know that when your traders route an order, they have a documented reason for that routing decision, and they want to know that someone is checking."
Fiona was quiet for a moment. "How bad is it?"
"It depends on what we find," Rafael said. "Let's start building the picture."
This chapter follows Rafael's engagement with Cornerstone through the structure of MiFID II and MiFIR — what the rules actually require, where firms most commonly fall short, and how RegTech tools close the gap between regulatory aspiration and operational reality.
18.2 MiFID II and MiFIR: The Legislative Architecture
18.2.1 The Directive-Regulation Distinction
The Markets in Financial Instruments Directive II (MiFID II, Directive 2014/65/EU) and the Markets in Financial Instruments Regulation (MiFIR, Regulation 600/2014/EU) together form the primary legislative framework governing securities trading and investment services in the European Union. They came into force on 3 January 2018, following a one-year delay from the original 2017 target driven by the sheer complexity of implementation.
The distinction between a directive and a regulation is legally significant. A directive requires transposition into national law — each EU member state must enact domestic legislation implementing MiFID II's requirements, which creates some scope for variation in implementation detail. A regulation applies directly across the EU without national transposition — MiFIR's transaction reporting and transparency requirements are therefore uniform across all EU member states, and were directly applicable in the UK prior to Brexit.
Together, MiFID II and MiFIR replaced the original Markets in Financial Instruments Directive (MiFID I, Directive 2004/39/EC), which had been the foundational framework for EU capital markets since November 2007.
18.2.2 What Changed from MiFID I
MiFID I was primarily concerned with creating a competitive European market for investment services, dismantling the national exchange monopolies that had dominated European equity trading. Its central mechanism was the "concentration rule" prohibition — member states could no longer require that retail orders be routed to national exchanges. The practical effect was the growth of alternative trading venues, particularly Multilateral Trading Facilities (MTFs), and a fragmentation of European equity markets.
By 2012, the European Commission had concluded that MiFID I had succeeded in creating competition but had also created significant problems: a proliferation of dark pools undermining price formation, inconsistent transaction reporting quality impeding market surveillance, inadequate investor protections in structured product sales, and insufficient transparency in non-equity markets. The MiFID II review process began, and six years of negotiation and technical standard-setting produced the legislative package that took effect in January 2018.
The key changes from MiFID I to MiFID II and MiFIR:
Transaction reporting: MiFID I transaction reporting was widely acknowledged as insufficient for market surveillance purposes. MiFIR Article 26 introduced a dramatically expanded reporting requirement — 65 mandatory fields compared to MiFID I's 23 — including the Legal Entity Identifier (LEI) for counterparties, the Trading Venue Transaction Identification Code (TVTIC) enabling cross-venue trade reconstruction, and algorithmic trading identification. The reporting obligation also extended to financial instruments admitted to trading on EU venues, regardless of where the transaction actually occurred.
Best execution: MiFID I's best execution requirements were widely criticised as aspirational rather than enforceable. MiFID II introduced mandatory annual reporting by venues (RTS 27) and investment firms (RTS 28), created the systematic internaliser framework for firms trading on their own account above defined thresholds, and required firms to take "all sufficient steps" (upgraded from "all reasonable steps" under MiFID I) to achieve best execution.
Market structure: MiFID II created a new venue category — the Organised Trading Facility (OTF) — specifically for non-equity instruments including bonds, structured products, and derivatives. MiFID II also introduced position limits for commodity derivatives, mandatory trading obligations for certain equity and derivatives instruments, and new rules on algorithmic and high-frequency trading.
Pre- and post-trade transparency: MiFID II significantly extended the transparency regime beyond equities. Non-equity instruments — bonds, structured products, emissions allowances, derivatives — were brought within the pre- and post-trade transparency framework for the first time, albeit with a calibrated approach acknowledging the different liquidity characteristics of these markets.
Investor protection: MiFID II introduced significant new requirements around product governance, inducements, and suitability assessment. These are beyond the scope of this chapter but form a significant part of the MiFID II compliance burden for retail-facing investment firms.
18.3 Transaction Reporting Under Article 26 MiFIR
18.3.1 The Reporting Obligation
Article 26 of MiFIR imposes a transaction reporting obligation on investment firms. The obligation is technically demanding and has generated extensive ESMA guidance.
The core obligation: investment firms that execute transactions in financial instruments must report complete and accurate details of those transactions to their National Competent Authority (NCA) as quickly as possible and no later than the close of business on the following working day (T+1).
Several elements of this obligation require unpacking.
Who is an investment firm for MiFIR purposes? The definition is broad: any legal person whose regular occupation or business is the provision of one or more investment services to third parties and/or the performance of one or more investment activities on a professional basis. This includes banks, broker-dealers, asset managers, and many entities that do not think of themselves primarily as investment firms. The obligation applies to EU-authorised investment firms regardless of where the transaction is executed.
What is a transaction for reporting purposes? A transaction is the conclusion of a purchase or sale of a financial instrument. This includes acquisitions and disposals of financial instruments (whether by sale, exercise of rights, or otherwise), securities financing transactions, and certain derivatives transactions. Mergers, spin-offs, and corporate events may also require reporting.
What instruments are in scope? Financial instruments admitted to trading on a trading venue in the EU or for which a request for admission has been made; financial instruments where the underlying is a financial instrument admitted to trading on a trading venue; and financial instruments where the underlying is an index or basket composed of financial instruments admitted to trading on a trading venue.
This extraterritorial scope is significant: an EU investment firm executing a transaction in a US-listed security on a US exchange must report that transaction under Article 26 MiFIR if the security is also admitted to trading on an EU venue.
18.3.2 The 65-Field Reporting Template
ESMA's technical standards specify 65 mandatory data fields for each transaction report. The full template is specified in the Annex to Commission Delegated Regulation (EU) 2017/590 (RTS 22). The fields cover five broad categories:
Counterparty identification: - Field 1: Reporting firm's LEI - Field 2: Executing entity's LEI (if different) - Field 3: Investment decision maker's ID (LEI or NCA identifier) - Field 4: Executing trader's ID - Field 7: Buyer's LEI (or concatenated code for individuals) - Field 8: Buyer's date of birth (for natural persons) - Fields 9-12: Similar seller fields
Instrument identification: - Field 41: ISIN of the instrument - Field 42: MIC code of the trading venue - Field 43: The TVTIC — Trading Venue Transaction Identification Code
Transaction terms: - Field 44: Transaction type - Field 45: Buy/sell indicator - Field 46: Price - Field 47: Price currency - Field 48: Net amount - Field 49: Venue of execution - Field 50: Quantity - Field 51: Price multiplier - Field 52: Commodity derivative indicator
Trading capacity: - Field 29: Capacity (DEAL/MTCH/AOTC) - Field 30: Quantity notation
Algorithmic trading: - Field 26: Algorithmic trading indicator (Y/N) - Field 27: Algo decision-making indicator - Field 28: Algo execution indicator
The Trading Venue Transaction Identification Code (TVTIC) deserves particular attention. The TVTIC is a unique code assigned by a trading venue to each transaction executed on that venue. Its purpose is to enable regulators to link a firm's transaction report to the venue's own record of the trade, creating a cross-reference mechanism that makes it far easier to detect misreporting and reconstruct market events. The TVTIC is assigned by the venue; the investment firm must include it in its transaction report for on-venue transactions.
For OTC transactions — those executed off-venue — there is no TVTIC, and the field is left blank. This is significant: OTC transactions are harder for regulators to reconstruct, which is one reason MiFID II introduced mandatory trading obligations for certain instruments.
18.3.3 The Legal Entity Identifier and GLEIF Integration
The Legal Entity Identifier (LEI) is a 20-character alphanumeric code that uniquely identifies legal entities participating in financial transactions. LEIs are issued by Local Operating Units (LOUs) accredited by the Global Legal Entity Identifier Foundation (GLEIF), which maintains the global LEI registry.
MiFIR makes the LEI mandatory for reporting purposes. Article 26(6) MiFIR states that investment firms shall not execute a transaction on behalf of a client who has not obtained an LEI when required to do so. This is the "no LEI, no trade" rule — and it was, in 2018, a significant operational challenge for many firms whose corporate clients had not yet registered for LEIs.
The GLEIF integration serves market surveillance purposes directly: regulators can cross-reference LEI data with GLEIF's publicly available reference data to verify entity identity, check ownership structures, and detect discrepancies. ESMA actively uses GLEIF data quality reports in its transaction reporting quality assessments.
18.3.4 Approved Reporting Mechanisms (ARMs)
Investment firms may submit transaction reports directly to their NCA, or they may use an Approved Reporting Mechanism (ARM) to submit on their behalf. ARMs are entities authorised under MiFIR Article 59 to receive transaction reports from investment firms and submit them to NCAs.
Using an ARM does not relieve the investment firm of responsibility for the accuracy and completeness of its transaction reports. The firm remains responsible; the ARM is a submission conduit. However, ARMs typically provide value-added services beyond mere transmission: format validation, data enrichment, error reporting, and reconciliation tools that help firms identify and correct reporting deficiencies before submissions are made.
Major ARM providers include DTCC (operating in partnership with European providers), Unavista (part of the London Stock Exchange Group), and a number of regional specialists. ARM selection is itself a RegTech decision: the right ARM for a firm depends on instrument coverage, system integration capability, validation depth, and the quality of the reporting analytics provided.
18.4 Best Execution Under Article 27 MiFID II
18.4.1 The Best Execution Obligation
Article 27 of MiFID II requires investment firms executing orders on behalf of clients to "take all sufficient steps to obtain, when executing orders, the best possible result for their clients." The upgrade from MiFID I's "all reasonable steps" to "all sufficient steps" was deliberate — it raises the standard and shifts the burden toward demonstrable outcome measurement rather than procedural compliance.
Best execution is not simply about price. Article 27(1) specifies that firms must consider the following factors:
Price — The consideration paid or received for the financial instrument, excluding costs.
Costs — All expenses incurred by the client that are directly related to the execution of the order, including execution venue fees, clearing and settlement fees, and any other fees paid to third parties involved in the execution of the order.
Speed — The time taken to execute the order from receipt to completion. Speed may be critical for certain clients and instruments; for others, it may be less important than price or certainty of execution.
Likelihood of execution and settlement — The probability that the order will be filled in full, at an acceptable price, and that the resulting transaction will settle without fail. This factor is particularly important for illiquid instruments where there is genuine risk that an order cannot be filled.
Size — The size of the order relative to market liquidity. A large order may fragment across multiple venues or time periods; the execution strategy must account for market impact.
The MiFID II framework also acknowledges that other execution factors may be relevant in specific circumstances: "the nature of the order, the nature and size of the order in relation to the market for the instrument, the speed of delivery of payment or of other consideration received or paid." These are treated as secondary factors that can be relevant where price and cost do not fully determine execution quality.
18.4.2 The Best Execution Policy
Every investment firm subject to Article 27 must establish and implement an order execution policy. The policy must:
- Identify, for each class of financial instruments, the venues on which the firm places significant reliance to meet its obligation to achieve the best possible result for the execution of client orders
- Include sufficient information about each venue to enable clients to understand and verify the firm's approach
- Be reviewed at least annually or whenever a material change occurs that affects the firm's ability to obtain the best possible result
The policy must be provided to clients in good time before the provision of services, and clients must provide their prior consent to the execution policy. This consent is typically embedded in client onboarding documentation.
Rafael spent the first week of the Cornerstone engagement reviewing the firm's execution policy. The policy was not inadequate on its face — it listed nine venues across equities, fixed income, and FX, and it described a Smart Order Routing (SOR) system that would evaluate venues in real time. But the policy had been written in 2019 and had not been updated to reflect two significant changes: Cornerstone had added three new venue connections in 2021, and the UK had diverged from EU MiFID II following Brexit.
"The policy needs to reflect the current venue universe," Rafael told Fiona. "And if you're trading UK securities on UK venues, those transactions are now governed by UK MiFIR, not EU MiFIR. Your policy needs to be clear about which regulatory regime applies to which book."
18.4.3 Client Order Handling
Article 28 MiFID II — distinct from Article 27 but closely related — governs client order handling. Investment firms executing client orders must implement procedures and arrangements for the prompt, fair, and expeditious execution of client orders relative to other client orders and the trading interests of the investment firm.
The client order handling rules have several practical implications:
Prompt execution: Orders must be executed as soon as reasonably practicable given market conditions. Time-stamping orders at receipt (to microsecond precision under Commission Delegated Regulation 2017/574 — the RTS 25 clock synchronisation requirements) is essential for demonstrating compliance.
Chronological execution: Unless market conditions or the nature of the order otherwise dictate, otherwise equivalent orders should be executed in the sequence of their receipt.
Aggregation and allocation: Where multiple client orders are aggregated for execution, the firm must have policies governing allocation of partial fills that do not disadvantage any individual client.
18.4.4 RTS 27 and RTS 28 Reporting
RTS 27 (Commission Delegated Regulation 2017/575) requires trading venues, systematic internalisers, market makers, and other liquidity providers to publish quarterly reports on execution quality. The RTS 27 reports must include data on price, costs, speed, and likelihood of execution, published in a machine-readable format.
RTS 28 (Commission Delegated Regulation 2017/576) requires investment firms to publish annual reports on the top five execution venues used for each class of financial instruments, together with information on execution quality. The RTS 28 report must cover at minimum the previous calendar year and be published no later than 30 April of the following year.
In practice, the RTS 27 and 28 framework faced significant challenges. The machine-readable format requirements were specified in detail, but implementation was inconsistent. ESMA conducted a review of RTS 27 data quality in 2020 and found widespread deficiencies. In February 2021, the European Commission announced that it would suspend the RTS 27 obligation as part of the Capital Markets Recovery Package — a recognition that the compliance costs were high and the market surveillance benefits had not materialised as hoped.
The RTS 28 obligation remained in force at the EU level. The UK, post-Brexit, retained both obligations initially but as of mid-2022 had also suspended its equivalent of RTS 27 (renamed as Best Execution reporting under the FCA's MIFIDPRU framework) pending the outcomes of the Wholesale Markets Review.
Cornerstone's RTS 28 report had been published in April — three months after the regulatory deadline of 30 April. Rafael noted this as a formal finding. It was not a material breach, but it demonstrated a compliance culture that needed strengthening.
18.5 Pre-Trade Transparency
18.5.1 The Pre-Trade Transparency Obligation
Pre-trade transparency requirements under MiFIR Articles 3-13 require trading venues and systematic internalisers to make public, on a continuous basis during normal trading hours, the current bid and offer prices and the depth of trading interest at those prices. The purpose is to allow market participants to find the best available price before executing a transaction.
Pre-trade transparency requirements apply to: - Regulated Markets (Articles 3, 8) - Multilateral Trading Facilities (Articles 3, 8) - Organised Trading Facilities (Articles 8) - Systematic Internalisers (Articles 14-17, equities and equity-like instruments; Articles 18-19, non-equities)
18.5.2 Waivers from Pre-Trade Transparency
MiFIR Articles 4 and 9 provide for waivers from pre-trade transparency obligations in specific circumstances. The most commercially significant waivers are:
Large in scale (LIS) waiver: Orders that are large relative to normal market size (determined by ESMA's published LIS thresholds) may be shielded from pre-trade transparency to protect the liquidity provider from being "front-run" by other market participants who observe the large order.
Reference price waiver: Orders matched at a price derived from a reference venue (typically the primary market's mid-point) — the mechanism used by many dark pools. The reference price waiver enables "dark" trading without the need for pre-trade quote display.
Negotiated transaction waiver: Certain negotiated transactions between professional counterparties may be conducted off-book and reported post-trade.
Order management facility waiver: Orders held in an order management system for investor-decided times.
18.5.3 The Double Volume Cap
MiFID II introduced the double volume cap (DVC) mechanism to limit the amount of trading occurring under reference price and negotiated transaction waivers in dark pools. The DVC restricts such trading to:
- No more than 4% of total EU-wide trading in a financial instrument in any rolling 12-month period on any single venue
- No more than 8% of total EU-wide trading in a financial instrument in any rolling 12-month period across all EU venues combined
When either cap is breached, the waiver is suspended for six months and the instrument must be traded on a lit venue. ESMA monitors and publishes DVC data monthly. The DVC has been controversial: critics argue it has fragmented European equity markets and pushed some dark trading to systematic internalisers, which are not subject to the DVC. As of 2023, the European Commission was reviewing the DVC mechanism as part of broader MiFID II review discussions.
18.6 Post-Trade Transparency
18.6.1 The Post-Trade Reporting Obligation
Post-trade transparency requirements under MiFIR Articles 20-21 (equities) and Articles 21 (non-equities) require investment firms executing transactions to make public the price, volume, and timing of those transactions as close to real-time as technically possible.
For on-venue transactions, post-trade transparency is the responsibility of the trading venue. For OTC transactions, the reporting obligation falls on the investment firm — specifically, the selling firm must publish the details of the transaction.
18.6.2 Approved Publication Arrangements (APAs)
An Approved Publication Arrangement (APA) is an entity authorised under MiFIR Article 64 to publish trade reports on behalf of investment firms. APAs are the post-trade equivalent of ARMs: they receive trade data from investment firms and publish it in a standardised, machine-readable format to the market.
Using an APA satisfies the investment firm's post-trade transparency obligation. The major APAs in the European market include Bloomberg, Refinitiv (now LSEG Data & Analytics), MarkitSERV, and ICE Data Services.
18.6.3 Deferred Publication
For certain instruments, immediate post-trade publication would be commercially damaging — a large block trade in an illiquid bond published immediately would reveal the firm's position and expose it to adverse price movement before it could hedge. MiFIR Article 11 provides for deferred publication of transactions in illiquid instruments and large-in-scale transactions.
ESMA specifies deferred publication periods calibrated to instrument type and transaction size. For the most illiquid instruments, deferred publication of up to four weeks is permitted. For liquid instruments that breach the LIS threshold, a shorter deferral period applies.
The instrument-by-instrument assessment of liquidity status — determining which instruments are "liquid" for MiFID II transparency purposes — is one of the most technically demanding aspects of MiFIR compliance. ESMA publishes and updates the liquidity assessments, using the concept of "Average Daily Number of Transactions" (ADNA) and "Average Daily Turnover" thresholds to determine whether an instrument is liquid.
18.7 The MiFID II Venue Landscape
18.7.1 Regulated Markets (RMs)
A Regulated Market (RM) is a multilateral system operated and/or managed by a market operator, which brings together or facilitates the bringing together of multiple third-party buying and selling interests in financial instruments — in the system and in accordance with its non-discretionary rules — in a way that results in a contract. The RM must be authorised and subject to authorisation and continuing supervision by the relevant NCA.
Examples: London Stock Exchange (Main Market), Euronext Amsterdam, Deutsche Börse Xetra. RMs are the "lit" primary markets — they are subject to the most stringent pre- and post-trade transparency requirements.
18.7.2 Multilateral Trading Facilities (MTFs)
An MTF is a multilateral system operated by an investment firm or a market operator, which brings together multiple third-party buying and selling interests in financial instruments — in the system and in accordance with non-discretionary rules — in a way that results in a contract. MTFs are authorised as investment firms.
MTFs include both lit venues (for example, BATS Europe, now CBOE Europe) and dark pools operating under pre-trade transparency waivers (for example, Liquidnet, Turquoise Dark). The MTF category was the primary vehicle through which MiFID I competition was implemented in European equity markets.
18.7.3 Organised Trading Facilities (OTFs)
The OTF is the new venue category introduced by MiFID II. OTFs are multilateral systems that are neither RMs nor MTFs, in which multiple third-party buying and selling interests in bonds, structured finance products, emissions allowances, or derivatives are able to interact in a way that results in a contract.
The critical distinction between an OTF and an MTF is that OTF operators have discretion in matching orders. An OTF operator can decide whether to place or retract an order, and can determine how orders interact with each other. This accommodates the reality of bond and derivatives markets, where relationship-based voice brokerage has historically played an important role.
OTFs may not execute equity instruments. OTFs may not execute against their own capital (with limited exceptions for non-equity instruments). The OTF category was designed primarily for voice-broking desks and dealer-to-client platforms in bond and derivatives markets.
18.7.4 Systematic Internalisers (SIs)
A Systematic Internaliser is an investment firm that, on an organised, frequent, systematic, and substantial basis, deals on its own account when executing client orders outside a trading venue without operating a multilateral system.
The SI determination methodology was substantially revised by MiFID II. Firms are SIs if they meet one of two tests:
Frequency/systematicity test: The OTC trades executed internally exceed 1% of total EU trading in the instrument in any three-month period.
Size test: OTC internal executions exceed 15% of the total EU trading by the firm in that instrument in any three-month period.
SIs in liquid instruments are subject to pre-trade transparency requirements: they must publish firm quotes on a continuous basis during normal trading hours. SI quotes must be firm — the SI must be prepared to transact at the published quote (up to the standard market size). SIs may update or withdraw quotes in exceptional market conditions.
The SI framework has become commercially and strategically important. Many large investment banks that would previously have operated as market makers in dark pools — and thus been subject to the double volume cap — have registered as SIs, where the DVC does not apply. The growth of SI trading has been one of the defining structural features of post-MiFID II European equity markets.
18.8 UK MiFID II Post-Brexit: The Wholesale Markets Review
18.8.1 The UK's Retained EU Law Approach
When the UK left the EU's single market at the end of 2020, EU financial services law — including MiFID II and MiFIR — was "onshored" into UK law through the European Union (Withdrawal) Act 2018. The UK versions of these instruments — known informally as UK MiFID II and UK MiFIR — initially mirrored the EU versions almost exactly, with only the textual changes necessary to make the legislation function in a domestic UK context (for example, replacing references to "the European Commission" with "the Treasury" and references to "ESMA" with "the FCA").
The FCA took over ESMA's supervisory role for UK-authorised investment firms. UK investment firms remained obligated to file transaction reports to the FCA via an ARM, using the same 65-field format (UK NCAs accepting equivalent data under the UK MAR and UK MiFIR frameworks).
18.8.2 The FCA's Wholesale Markets Review
The FCA launched the Wholesale Markets Review (WMR) in March 2021, with an explicit mandate to identify where the UK could diverge from EU MiFID II to create a more proportionate and competitive regulatory environment. The WMR consultation paper was published in March 2021 (CP21/9), and the final policy statement — PS22/2 — was published in March 2022.
Key WMR outcomes:
Share Trading Obligation (STO): The EU MiFID II Share Trading Obligation requires investment firms to execute shares admitted to trading on EU venues on EU trading venues or with an EU SI. The UK retained an equivalent Share Trading Obligation (UK STO) but diverged significantly in its approach: the FCA created a framework for recognising third-country trading venues, allowing UK investment firms to execute UK-share-equivalents on a broader range of venues. This has been commercially significant, particularly for dual-listed stocks traded on both EU and UK venues.
SI regime: The UK retained the SI regime but modified the determination methodology. The FCA concluded that the EU's binary SI thresholds (1% frequency / 15% size) were not well-calibrated and indicated its intention to develop a more proportionate approach for smaller firms.
Transparency waivers: The UK replaced the EU's double volume cap with a new mechanism. Under the FCA's post-WMR framework, the reference price waiver remains available but is subject to a single volume cap of 7.5% per-venue in a rolling 12-month period (the EU's 4%/8% structure was abandoned). The negotiated transaction waiver is retained with modest modifications.
RTS 27: As noted above, the UK suspended its equivalent of RTS 27 following the WMR, pending evidence that a reformed version would deliver meaningful market surveillance benefits proportionate to the compliance costs.
Commodity derivatives position limits: The UK moved to a "position management control" model rather than prescriptive position limits for commodity derivatives — a significant divergence from the EU framework.
18.8.3 MIFIDPRU and the Investment Firm Prudential Regime
Alongside the Wholesale Markets Review, the FCA implemented the Investment Firms Prudential Regime (IFPR) through the MIFIDPRU sourcebook, which came into force on 1 January 2022. MIFIDPRU replaced the Capital Requirements Regulation (CRR)-based prudential requirements for non-bank investment firms with a regime specifically designed for investment firms.
MIFIDPRU is not strictly a trading compliance framework — it is a prudential capital and liquidity framework. However, it is relevant to this chapter because it illustrates the broader pattern of UK regulatory divergence post-Brexit: while the UK has retained much of the substantive MiFID II framework for trading and investor protection, it has been willing to create significantly different prudential requirements for investment firms.
18.8.4 UK-EU Equivalence: An Unresolved Question
As of 2023, the UK and EU had not agreed on mutual market access arrangements for investment services. The EU had not granted equivalence under MiFIR Article 25 to UK trading venues, meaning EU investment firms are not permitted to execute EU mandatory trading obligation instruments on UK venues without breaching their obligations. The UK has adopted a somewhat more pragmatic approach to EU venues, but the absence of a formal equivalence decision creates ongoing legal uncertainty for cross-border operations.
For Cornerstone, this uncertainty was operationally real. The firm had booking entities in both London and Frankfurt. Rafael's review would need to address how Cornerstone's execution policy handled the distinction between orders routed from the UK entity (subject to UK MiFIR) and orders routed from the German entity (subject to EU MiFIR).
18.9 Technical Implementation: ISO 20022 and Algorithmic Trading Identification
18.9.1 ISO 20022 and Reporting Standards
Transaction reports submitted under Article 26 MiFIR must conform to technical standards specified in ESMA's regulatory technical standards. These standards draw extensively on the ISO 20022 financial messaging standard — a metadata-rich XML-based standard that provides a common language for financial transactions across institutions and jurisdictions.
ESMA's transaction reporting guidelines (ESMA/2020/1897, as updated) specify the precise format for each of the 65 fields, including permitted values, field lengths, and conditional logic (some fields are only required depending on the values in other fields). The algorithmic trading indicator (Field 26), for example, triggers additional mandatory fields: when Field 26 is "Y" (yes, the transaction involved algorithmic trading), Fields 27 and 28 (algorithmic decision-making and execution indicators) become mandatory.
The ESMA guidelines also specify the format for entity identifiers. Legal entities must be identified by LEI. Natural persons must be identified by a concatenated code comprising nationality code, identity document type, and identity document number — a format that varies by jurisdiction and has been a persistent source of reporting errors.
18.9.2 Algorithmic Trading Identification
The identification of algorithmic trading in transaction reports is a significant compliance challenge for firms that use automated execution systems. MiFID II defines algorithmic trading as "trading in financial instruments where a computer algorithm automatically determines individual parameters of orders such as whether to initiate the order, the timing, price or quantity of the order or how to manage the order after its submission, with limited or no human intervention."
The definition is broad. A simple automated execution system that uses a time-weighted average price (TWAP) algorithm to slice a large order is clearly algorithmic trading. But what about a system that uses pre-programmed rules to select a venue? What about a system that generates trade suggestions that a human then approves?
ESMA's guidelines provide a framework for making this determination, but it requires judgment in many cases. Investment firms must document their determination process and apply it consistently. Regulators have noted that inconsistent application of the algorithmic trading indicator is one of the most common transaction reporting quality issues identified in supervisory reviews.
18.10 RegTech for MiFID II Compliance
18.10.1 Transaction Reporting Technology
The 65-field MiFID II transaction reporting requirement is, in practice, impossible to implement without substantial technology infrastructure. The data required for a single transaction report may come from multiple source systems: the order management system (OMS), the execution management system (EMS), the reference data system (for ISIN, LEI, and instrument classification), the client data system (for buyer/seller identification), and the trade booking system.
Building the infrastructure to gather, validate, and submit this data reliably at T+1 across an entire firm's transaction book is a substantial engineering project. Most investment firms use a combination of:
ARM services: Rather than building direct FCA/NCA connections, most firms route transaction reports through an ARM that handles format validation, connectivity, and error reporting.
Reference data utilities: Services that maintain up-to-date ISIN-to-classification mappings, LEI reference data (sourced from GLEIF), and venue MIC code databases.
Reconciliation tools: Systems that reconcile the firm's transaction records against the ARM's submissions and the NCA's acknowledgements, identifying reporting failures and enabling corrective action.
Data quality dashboards: Analytics tools that monitor the quality of transaction data at the field level, flagging common error types (missing LEIs, incorrect instrument classifications, duplicate submissions) before they become regulatory findings.
18.10.2 Best Execution Analytics
Best execution compliance technology has evolved significantly since MiFID II's 2018 implementation. The early approaches focused primarily on demonstrating procedural compliance — documenting that the SOR was configured to route to listed venues in a defined priority order. Regulators have made clear that this is insufficient; they expect firms to demonstrate outcome-based compliance: that execution quality was actually achieved, not just that a compliant process was followed.
The modern best execution analytics platform typically provides:
Execution quality benchmarking: Comparing the firm's execution prices against standard benchmarks — arrival price (the mid-point at the time the order was received), VWAP over the execution period, close price, and implementation shortfall. Different benchmarks are appropriate for different order types and client mandates.
Venue analysis: Comparing execution quality across the venues used, identifying whether the SOR is routing orders to the venues that are actually delivering best execution.
Exception management: Flagging executions that fall outside tolerance bands for further review, enabling the compliance team to investigate and document the reason for apparent under-performance.
RTS 28 reporting support: Generating the data and format required for annual RTS 28 publication, including venue classification and quality metrics.
Trend analysis: Identifying whether execution quality is improving or deteriorating over time, and correlating changes with venue or algorithm changes.
18.11 Python Implementation: Best Execution Analysis
18.11.1 The Best Execution Analysis Problem
From a quantitative perspective, best execution analysis involves comparing the execution outcomes achieved for a set of orders against a set of reference benchmarks. The most fundamental analysis is implementation shortfall (also called arrival price slippage): the difference between the decision price (typically the mid-point at the time the order was received) and the volume-weighted average price at which the order was actually filled.
For a buy order, positive implementation shortfall (executed above the arrival price) represents a cost to the client. For a sell order, positive implementation shortfall (executed below the arrival price) represents a cost. The sign convention used in this implementation follows market practice: a positive slip is always a cost to the client, regardless of order direction.
18.11.2 Implementation
from dataclasses import dataclass
from datetime import datetime
from typing import Optional
import pandas as pd
import numpy as np
@dataclass
class ClientOrder:
"""Represents a client order received by the investment firm."""
order_id: str
instrument_isin: str
side: str # 'buy' or 'sell'
quantity: float
order_type: str # 'market', 'limit'
limit_price: Optional[float]
received_time: datetime
client_id: str
@dataclass
class Execution:
"""Represents an individual execution (partial fill or full fill) of an order."""
execution_id: str
order_id: str
executed_price: float
executed_quantity: float
venue: str
execution_time: datetime
class BestExecutionAnalyzer:
"""
Implements MiFID II best execution analysis.
The five MiFID II Article 27 factors are addressed as follows:
- Price: arrival_price_slippage, vwap_slippage
- Cost: passed via cost_bps parameter
- Speed: execution_duration (time to fill)
- Likelihood of execution: fill_rate (quantity filled / quantity ordered)
- Size: large_order_flag (order vs LIS threshold)
"""
def __init__(self, large_order_threshold_pct: float = 0.01):
"""
Args:
large_order_threshold_pct: Orders whose notional exceeds this fraction
of average daily volume are flagged as large-in-scale. Default 1%.
"""
self.large_order_threshold_pct = large_order_threshold_pct
# ------------------------------------------------------------------
# Core benchmark analysis methods
# ------------------------------------------------------------------
def analyze_vs_arrival_price(
self,
order: ClientOrder,
executions: list[Execution],
arrival_price: float,
) -> dict:
"""
Compute implementation shortfall (arrival price slippage).
Implementation shortfall = (VWAP_executed - arrival_mid) / arrival_mid
for buys; reversed for sells. Positive value = cost to client.
Args:
order: The ClientOrder being analysed.
executions: All Execution records for this order.
arrival_price: Mid-point of the NBBO at the time the order was
received by the firm (before any market impact).
Returns:
Dictionary with keys:
arrival_price, vwap_executed, slippage_pct, slippage_bps,
total_quantity_filled, fill_rate, execution_duration_secs
"""
if not executions:
return {
"arrival_price": arrival_price,
"vwap_executed": None,
"slippage_pct": None,
"slippage_bps": None,
"total_quantity_filled": 0.0,
"fill_rate": 0.0,
"execution_duration_secs": None,
}
total_value = sum(e.executed_price * e.executed_quantity for e in executions)
total_qty = sum(e.executed_quantity for e in executions)
vwap_executed = total_value / total_qty if total_qty > 0 else None
if vwap_executed is not None and arrival_price > 0:
raw_slippage = (vwap_executed - arrival_price) / arrival_price
# For sell orders the sign is inverted: selling below arrival is a cost
slippage_pct = raw_slippage if order.side == "buy" else -raw_slippage
slippage_bps = slippage_pct * 10_000
else:
slippage_pct = None
slippage_bps = None
fill_rate = total_qty / order.quantity if order.quantity > 0 else 0.0
sorted_execs = sorted(executions, key=lambda e: e.execution_time)
duration_secs = (
(sorted_execs[-1].execution_time - order.received_time).total_seconds()
if sorted_execs
else None
)
return {
"arrival_price": arrival_price,
"vwap_executed": vwap_executed,
"slippage_pct": slippage_pct,
"slippage_bps": slippage_bps,
"total_quantity_filled": total_qty,
"fill_rate": fill_rate,
"execution_duration_secs": duration_secs,
}
def analyze_vs_vwap(
self,
order: ClientOrder,
executions: list[Execution],
market_vwap: float,
) -> dict:
"""
Compare the firm's execution VWAP against the market VWAP for the period.
A positive VWAP slippage (for buys) means the firm executed above
the market average — a cost to the client.
Args:
order: The ClientOrder being analysed.
executions: All Execution records for this order.
market_vwap: Volume-weighted average price of all market
transactions in the instrument during the execution
period (sourced from market data).
Returns:
Dictionary with keys:
market_vwap, firm_vwap, vwap_slippage_pct, vwap_slippage_bps
"""
if not executions or market_vwap <= 0:
return {
"market_vwap": market_vwap,
"firm_vwap": None,
"vwap_slippage_pct": None,
"vwap_slippage_bps": None,
}
total_value = sum(e.executed_price * e.executed_quantity for e in executions)
total_qty = sum(e.executed_quantity for e in executions)
firm_vwap = total_value / total_qty if total_qty > 0 else None
if firm_vwap is not None:
raw_diff = (firm_vwap - market_vwap) / market_vwap
vwap_slippage_pct = raw_diff if order.side == "buy" else -raw_diff
vwap_slippage_bps = vwap_slippage_pct * 10_000
else:
vwap_slippage_pct = None
vwap_slippage_bps = None
return {
"market_vwap": market_vwap,
"firm_vwap": firm_vwap,
"vwap_slippage_pct": vwap_slippage_pct,
"vwap_slippage_bps": vwap_slippage_bps,
}
def analyse_venue_distribution(
self,
executions: list[Execution],
) -> pd.DataFrame:
"""
Break down executed quantity and value by execution venue.
Returns a DataFrame indexed by venue with columns:
quantity, notional, avg_price, pct_of_total_qty
"""
if not executions:
return pd.DataFrame(columns=["quantity", "notional", "avg_price", "pct_of_total_qty"])
records = []
for e in executions:
records.append({
"venue": e.venue,
"quantity": e.executed_quantity,
"notional": e.executed_price * e.executed_quantity,
})
df = pd.DataFrame(records)
summary = (
df.groupby("venue")
.agg(quantity=("quantity", "sum"), notional=("notional", "sum"))
.assign(avg_price=lambda x: x["notional"] / x["quantity"])
)
total_qty = summary["quantity"].sum()
summary["pct_of_total_qty"] = summary["quantity"] / total_qty * 100
return summary.sort_values("pct_of_total_qty", ascending=False)
# ------------------------------------------------------------------
# Portfolio-level reporting
# ------------------------------------------------------------------
def generate_execution_quality_report(
self,
orders: list[ClientOrder],
executions: list[Execution],
benchmarks: dict,
) -> pd.DataFrame:
"""
Generate a portfolio-level execution quality report.
Args:
orders: List of ClientOrder objects.
executions: List of all Execution records.
benchmarks: Dict mapping order_id -> dict with keys:
'arrival_price' (float): mid at order receipt
'market_vwap' (float): market VWAP for the period
Returns:
DataFrame with one row per order containing arrival-price and
VWAP slippage metrics, fill rate, and execution duration.
"""
# Group executions by order_id for efficient lookup
exec_by_order: dict[str, list[Execution]] = {}
for e in executions:
exec_by_order.setdefault(e.order_id, []).append(e)
rows = []
for order in orders:
order_execs = exec_by_order.get(order.order_id, [])
bench = benchmarks.get(order.order_id, {})
arrival_px = bench.get("arrival_price")
market_vwap = bench.get("market_vwap")
arrival_result = (
self.analyze_vs_arrival_price(order, order_execs, arrival_px)
if arrival_px is not None
else {}
)
vwap_result = (
self.analyze_vs_vwap(order, order_execs, market_vwap)
if market_vwap is not None
else {}
)
rows.append({
"order_id": order.order_id,
"instrument_isin": order.instrument_isin,
"side": order.side,
"ordered_qty": order.quantity,
"filled_qty": arrival_result.get("total_quantity_filled", 0),
"fill_rate": arrival_result.get("fill_rate"),
"arrival_price": arrival_result.get("arrival_price"),
"vwap_executed": arrival_result.get("vwap_executed"),
"arrival_slippage_bps": arrival_result.get("slippage_bps"),
"market_vwap": vwap_result.get("market_vwap"),
"vwap_slippage_bps": vwap_result.get("vwap_slippage_bps"),
"execution_duration_secs": arrival_result.get("execution_duration_secs"),
})
report_df = pd.DataFrame(rows)
# Derived summary columns
if "arrival_slippage_bps" in report_df.columns:
report_df["exceeds_threshold"] = (
report_df["arrival_slippage_bps"].abs() > 10 # 10 bps alert threshold
)
return report_df
def summarise_report(self, report: pd.DataFrame) -> dict:
"""
Produce summary statistics from a generate_execution_quality_report output.
Returns a dict with portfolio-level averages and exception counts,
suitable for inclusion in RTS 28 documentation packs.
"""
slippage_col = "arrival_slippage_bps"
summary = {
"total_orders": len(report),
"avg_fill_rate": report["fill_rate"].mean(),
"avg_arrival_slippage_bps": report[slippage_col].mean() if slippage_col in report.columns else None,
"median_arrival_slippage_bps": report[slippage_col].median() if slippage_col in report.columns else None,
"pct_orders_exceeding_threshold": (
report["exceeds_threshold"].mean() * 100
if "exceeds_threshold" in report.columns
else None
),
"avg_execution_duration_secs": report["execution_duration_secs"].mean(),
}
return summary
18.11.3 Using the Analyzer: A Worked Example
from datetime import datetime
# Order received at 09:31:05 on 15 March 2024
order = ClientOrder(
order_id="ORD-2024-001",
instrument_isin="GB00B1YW4409", # Hypothetical UK equity
side="buy",
quantity=50_000,
order_type="market",
limit_price=None,
received_time=datetime(2024, 3, 15, 9, 31, 5),
client_id="CLI-00421",
)
# Three partial fills across two venues
executions = [
Execution("EX-001", "ORD-2024-001", executed_price=142.35, executed_quantity=20_000,
venue="XLON", execution_time=datetime(2024, 3, 15, 9, 31, 8)),
Execution("EX-002", "ORD-2024-001", executed_price=142.48, executed_quantity=20_000,
venue="XLON", execution_time=datetime(2024, 3, 15, 9, 31, 12)),
Execution("EX-003", "ORD-2024-001", executed_price=142.60, executed_quantity=10_000,
venue="BATE", execution_time=datetime(2024, 3, 15, 9, 31, 19)),
]
analyzer = BestExecutionAnalyzer()
# Arrival mid-price at 09:31:05 was 142.20p
arrival_result = analyzer.analyze_vs_arrival_price(order, executions, arrival_price=142.20)
print(f"Arrival slippage: {arrival_result['slippage_bps']:.2f} bps")
# → Arrival slippage: +13.53 bps (cost to the client)
# Market VWAP for the instrument between 09:30 and 09:32 was 142.30p
vwap_result = analyzer.analyze_vs_vwap(order, executions, market_vwap=142.30)
print(f"VWAP slippage: {vwap_result['vwap_slippage_bps']:.2f} bps")
# → VWAP slippage: +8.80 bps (firm's VWAP was above market VWAP)
# Venue distribution
venue_df = analyzer.analyse_venue_distribution(executions)
print(venue_df)
# quantity notional avg_price pct_of_total_qty
# venue
# XLON 40000 5695200.0 142.38 80.0
# BATE 10000 1426000.0 142.60 20.0
In the Cornerstone context, results like these would be logged to the firm's best execution monitoring system. An arrival slippage of 13.53 basis points on a market order might be within acceptable parameters — or it might trigger an exception review, depending on the instrument's liquidity and the firm's defined tolerance bands. The key point is that the system generates a systematic, comparable, auditable record of execution quality that regulators can review.
18.12 MiFID II Compliance: Common Failure Modes
The RegTech community has learned a great deal from five years of MiFID II supervisory enforcement. The following failure modes appear repeatedly across FCA thematic reviews, ESMA quality assessments, and regulatory enforcement actions:
Transaction reporting field errors: The most common errors are missing or incorrect LEIs (particularly for natural persons, where the concatenated code format is error-prone), incorrect instrument classifications (confusing bond vs. structured product categories), missing algorithmic trading indicators, and TVTIC format errors for on-venue trades.
Best execution policy staleness: Policies written at implementation in 2018 and never updated. The venue landscape, the firm's trading activity, and the regulatory framework have all changed; the policy must reflect current reality.
RTS 28 late publication: The 30 April annual deadline for RTS 28 publication is frequently missed. This is partly an internal workflow problem (the compliance team requires execution data from multiple business lines and systems) and partly a prioritisation problem.
Single-venue routing: Smart Order Routing systems configured to route orders to a single preferred venue in practice — either because of commercial relationships, fee arrangements, or simply inertia. Regulators expect to see evidence that the SOR is genuinely evaluating multiple venues and routing to the best available.
No venue analysis: Firms that have a SOR but do not conduct any retrospective analysis of venue performance. MiFID II requires firms to monitor execution quality and review the effectiveness of their execution policy — this requires data, analytics, and a regular review process.
18.13 Summary
MiFID II and MiFIR represent the most comprehensive reform of European capital markets regulation in a generation. The transaction reporting framework under Article 26 MiFIR — with its 65-field template, TVTIC requirements, and LEI obligations — has created a surveillance infrastructure that gives regulators unprecedented visibility into trading activity. The best execution framework under Article 27 has elevated execution quality from a procedural checkbox to a data-driven, outcome-measured compliance discipline.
Post-Brexit divergence between UK and EU MiFID II has added complexity for cross-jurisdictional firms: the UK's Wholesale Markets Review has produced genuine differences in the transparency waiver framework, the SI determination methodology, and the RTS 27 reporting obligation, and further divergence is likely as the FCA continues to reform the inherited EU framework under its new powers.
For RegTech practitioners, MiFID II represents both a challenge and an opportunity. The complexity of the reporting and best execution requirements creates genuine compliance risk that technology can systematically address. The best execution analytics platform, the ARM-based transaction reporting utility, and the reference data infrastructure are not optional enhancements — they are, for any investment firm of meaningful scale, essential infrastructure for meeting regulatory obligations.
Rafael spent six months working with Cornerstone to build that infrastructure. At the end of the engagement, Fiona Mackenzie presented the remediation programme to the FCA. The outcome is examined in Case Study 1.
Key Terms
ARM (Approved Reporting Mechanism): An entity authorised under MiFIR Article 59 to receive and submit transaction reports on behalf of investment firms.
APA (Approved Publication Arrangement): An entity authorised under MiFIR Article 64 to publish trade reports on behalf of investment firms.
Double Volume Cap (DVC): The MiFID II mechanism limiting dark pool trading under reference price and negotiated transaction waivers to 4% per-venue and 8% market-wide in any rolling 12-month period.
Implementation Shortfall: The difference between the decision price (arrival mid-point) and the volume-weighted average execution price, expressed as a cost to the client.
LEI (Legal Entity Identifier): A 20-character alphanumeric code uniquely identifying legal entities in financial transactions, issued by GLEIF-accredited LOUs.
MiFID II (Directive 2014/65/EU): The Markets in Financial Instruments Directive II, governing investment services, trading venues, and investor protection in the EU from 3 January 2018.
MiFIR (Regulation 600/2014/EU): The Markets in Financial Instruments Regulation, directly applicable across the EU and governing transaction reporting and market transparency.
OTF (Organised Trading Facility): A new MiFID II venue category for non-equity instruments operated on a discretionary matching basis.
Systematic Internaliser (SI): An investment firm that deals on its own account when executing client orders, on an organised, frequent, systematic, and substantial basis, outside a trading venue.
TVTIC (Trading Venue Transaction Identification Code): A unique code assigned by a trading venue to each transaction, enabling cross-reference between firm transaction reports and venue records.
Chapter 18 is part of Part 4: Trading Compliance and Market Surveillance. Chapter 19 examines Market Abuse Regulation (MAR) surveillance systems and the technology of trade and communications surveillance.