Designing MiFID II Best-Execution Reports for Buy-Side PMs

MiFID II Article 27(1) is short enough to quote in full:

"Member States shall require that investment firms take all sufficient steps to obtain, when executing orders, the best possible result for their clients taking into account price, costs, speed, likelihood of execution and settlement, size, nature or any other consideration relevant to the execution of the order."

That one sentence generates the two regulatory deliverables most buy-side shops hate producing: the RTS 27 venue-quality report (quarterly, from execution venues) and the RTS 28 top-five-venues report (annual, from the firm itself). Both are publicly filed. Both are, in almost every case I have seen on the buy side, an unreadable PDF churned out by a compliance team, rubber-stamped, and forgotten until the next cycle.

That is a design failure disguised as a regulatory one. The data is there. The portfolio managers who need it cannot see it. Here is how I approach the UX when I get to build it properly.

What PMs actually ask the report

When a buy-side PM reviews best-ex, the questions are specific and always the same five:

1. Where did my flow go? Venue-level volume share over the period, by asset class and by order size bucket.
2. Was I getting better prices elsewhere? Slippage versus arrival-price midpoint and versus EBBO (European best bid/offer), broken down by venue.
3. How fast did it fill? Time-to-fill distribution — not the mean, the full histogram, because the tail is where information leakage lives.
4. What did it cost me beyond the spread? Explicit fees + implicit market impact, per venue, per order size.
5. Is this pattern new? Versus last quarter, versus same-quarter-last-year, and versus the firm's stated RTS 28 execution policy.

None of those questions are answered well by a PDF. They are all answerable by the same data that generates the PDF. The design job is to present that data as a filterable, drill-downable surface that a PM can spend 90 seconds on during a Monday review.

The three-layer screen I keep coming back to

The best-ex surface I designed for Argos (a compliance analytics concept) and variations of it I have seen in production at broker desks all use the same three-layer layout:

Layer 1 — Policy compliance strip (top, always visible)

A horizontal strip with the RTS 28 stated policy on one side and observed reality on the other. "Policy: 60% LSE, 25% Cboe, 10% Turquoise, 5% other." "Observed this quarter: 52% LSE, 31% Cboe, 12% Turquoise, 5% other." Red pill if drift exceeds a threshold the compliance team sets. This answers question 5 in three seconds and gives compliance something they can staple to the quarterly file.

The strip must be persistent — it cannot disappear when the PM scrolls into the venue grid. The entire argument of the design is that policy adherence is ambient, always visible, never a separate workflow. If the compliance team starts treating the strip as a "daily check" tab, it has already lost its purpose.

Layer 2 — Venue attribution grid (middle, primary workspace)

A table of venues as rows; columns for volume share, arrival-price slippage (bps), EBBO capture %, mean time-to-fill, p95 time-to-fill, explicit cost (bps), implicit cost (bps), reject rate. Every cell is clickable and drills to the underlying trades. Row hover shows a 30-day sparkline of that venue's slippage against the firm's average. This is where the PM lives.

Filter controls at the top: asset class, order size bucket (under 1m shares / 1–10m / over 10m — the buckets matter because venue quality at large size often diverges sharply from venue quality at small size), time period, desk/trader. These four controls answer 80% of the questions PMs actually have. Every additional filter I have ever been asked for was a request from compliance, not from PMs.

Layer 3 — Trade-level audit trail (right drawer, on demand)

When the PM clicks into a cell, a right-side drawer opens with the individual executions: order ID, timestamp (microsecond), venue, arrival mid, fill price, fill size, venue latency, counterparty, MiFID transaction reference number (TRN). Copy-to-clipboard on the TRN because that is the field compliance will later need to cross-reference with the transaction reporting system (ARM). Export-to-CSV so the PM can hand the slice to the TCA (transaction cost analysis) team.

One thing to get right in the drawer: the column order. PMs read it left to right in decision order — timestamp, symbol, venue, size, arrival mid, fill price, slippage. Compliance reads it in audit order — TRN, timestamp, counterparty, venue, order type. These are different orders. Ship two export templates, not one.

Design choices that matter more than they look

Time-to-fill as a distribution, not a mean. Showing the mean time-to-fill is actively misleading — a venue with a 12ms mean and a 180ms p99 is a venue with an information-leakage problem. I always show the full distribution as a small histogram or boxplot in the row. The p95 column in the venue grid is the minimum; the histogram is what surfaces the tail.

Slippage in basis points, not currency. A PM trades AAPL at 210 USD and VOD at 70 GBp in the same session. Currency-denominated slippage is noise. Bps is the only unit that compares cleanly across instruments, session sizes, and portfolio vintage.

Policy vs observed colour logic. Drift < 2pp = neutral. 2–5pp = amber. > 5pp = red and it auto-generates a compliance note prompt. The colour is a signal to the compliance officer, not to the PM; the PM does not need to be told his execution is drifting — he already knows. The compliance team needs the escalation path visible and one-click.

Export everything. Buy-side PMs live in spreadsheets. Every drill-down must be CSV-exportable with one click, headers preserved, so they can paste into their own TCA model without reformatting. If the UI is a dead end for data, the PM will stop using it within two weeks. This is not a nice-to-have — it is the usage-retention floor for a tool that competes with "I'll just ask the desk."

Venue naming is political. Execution venues have technical names (MIC codes), trading names, and the informal names desks use. "XLON", "London Stock Exchange", and "LSE" all mean the same thing; your PM will use all three depending on context. The display layer needs to handle all three as the same entity. I have seen two separate firms' analytics break because the RTS 27 data used MIC codes and the PM interface used trading names, and nobody mapped them.

What I push back on

Compliance teams often ask for the report surface to double as the client-facing RTS 28 publication. It should not. The public RTS 28 is a static annual artefact in a prescribed ESMA format; it does not need a UI. The internal best-ex surface is a living tool for decision-making. Conflating the two produces a page that is too complex for regulators and too dumbed-down for PMs. Ship two things. The compliance team's instinct to merge them is understandable — one thing to maintain, one thing to audit. But the audiences are different and the success criteria are opposite: the regulatory artefact succeeds by being complete and filed; the PM tool succeeds by being used on Monday morning.

The regulatory driver for best-ex is not going away — ESMA's 2024 MiFID II review kept Article 27 largely intact and tightened the monitoring obligation. The firms that treat it as a PDF-generation problem will keep producing unreadable PDFs. The ones that treat it as a product-design problem will give their PMs a surface that actually moves execution quality.