Learning Execution Cost Models From Fills

Every parent order a desk executes leaves a record: how large it was, how fast it was worked, what the market looked like, and how much the price moved against the desk while filling it. That record is training data for a cost model — a function that predicts, before an order is placed, how expensive it will be to execute a given size at a given speed in given conditions. The appeal is obvious: a model trained on a desk's own fills should predict that desk's actual costs better than a generic textbook formula like the square-root impact law. The catch is that the desk's own history was generated by a scheduling algorithm that was already trying to minimise cost — meaning the historical data systematically under-samples the expensive, aggressive executions a naive cost model most needs to learn from.

Why "just fit a model to fills" isn't enough

A cost model needs, as inputs, the features that plausibly drive cost — order size relative to average daily volume, participation rate, volatility, spread, time of day — and as a target, realised cost, usually measured as implementation shortfall against arrival price. Fitting a regression or gradient-boosted model to this data is mechanically straightforward. The problem is selection bias in the training set itself: if the desk's execution algorithm routes large orders to be worked more slowly precisely because they're expected to be costly, the historical data has disproportionately few observations of "large order, executed fast, high realised cost" — the exact combination a model most needs to see to predict it well for a future order that, for some reason, must be executed fast.

This is compounded by the fact that market conditions during past fills are not independent of the strategy's own footprint (see Learning Market Impact From Your Own Fills) — an order that moved the market itself changed the conditions the next order in the queue was placed under, so treating historical fills as independent training examples understates how much one order's cost depends on very recent order flow, including the desk's own.

A worked example

A desk trains a gradient-boosted regression on two years of parent-order fills, predicting implementation shortfall (in basis points) from order size as a percentage of average daily volume, target participation rate, and trailing 20-day volatility.

On held-out fills drawn from the same distribution as training (moderate size, moderate participation — the algorithm's usual operating range), the model's predictions track realised cost closely, with a mean absolute error of a few basis points.

The desk then tests the model against a rare event in the data: a handful of orders that, for risk-reduction reasons, were forced through at high participation rates during a volatile week. On exactly these observations, the model underpredicts cost by a wide margin — its training data contained very few examples anywhere near this size/speed/volatility combination, so it extrapolates using whatever smooth relationship it learned from the much more common moderate-participation region, and that relationship does not hold once impact becomes convex at high participation.

The fix isn't a better model architecture; it's recognising the coverage gap and either deliberately sampling more aggressive executions (at a real cost, in a controlled way) or falling back to a parametric model with known convex behaviour (like a square-root impact law) in the region the learned model has never seen.

Adjust the exponent above a value of 1 and watch the curve bend upward faster than linear — this is the shape realised cost typically takes as participation rate rises, because moving faster than the market can absorb costs disproportionately more. A learned model trained mostly on low-participation fills tends to under-estimate this curvature, since it has seen little data in the region where the curve bends hardest.

Where it breaks in practice

The other common failure is measuring "cost" against the wrong benchmark. Implementation shortfall against arrival price captures the desk's own footprint plus whatever the market did anyway; a volatile market can inflate shortfall even for an order executed skilfully. A cost model trained without controlling for concurrent market moves ends up partly predicting market volatility rather than the desk's own impact, which looks fine in aggregate but misattributes cost driver by driver.