Fill Quality and Venue Scorecards

A strategy's backtest usually assumes a single, simplified execution cost — a fixed number of basis points of slippage, applied uniformly. In live trading, actual execution quality varies a great deal depending on where an order is sent: different exchanges and dark pools have different fee structures, different latency, different likelihood of getting a good price, and different amounts of adverse selection. A fill-quality and venue scorecard is the ongoing report that tracks these differences directly, so a desk can see, with real numbers, whether its routing logic is actually sending orders where they get filled best.

A typical scorecard tracks, per venue, metrics like average slippage against the price at order submission, fill rate (what fraction of orders sent there actually execute), average time to fill, and price improvement relative to the quoted spread. These get compared across venues and reviewed periodically — weekly or monthly is common — because venue quality is not static. A venue that offered great fills a year ago can degrade as more participants route flow there and the easy liquidity gets picked off, or as the venue's own matching engine or fee schedule changes.

A concrete example: a scorecard shows that Venue A fills orders 20% faster than Venue B on average, but with 3 basis points more slippage per fill. For a strategy that is latency-sensitive — where being a few milliseconds slow means missing a price entirely — Venue A's speed might be worth the extra cost. For a strategy that is patient and cost-sensitive, Venue B is the better default. Without the scorecard, a desk might keep routing everything through whichever venue was configured as default years ago, silently leaving money on the table on every single order.

Because these scorecards are one of the few places where the gap between backtest assumptions and live reality shows up in hard numbers, they are also a natural feedback loop back into research: if live slippage is consistently higher than the backtest assumed, that assumption should be corrected before the next strategy is designed around it.