Training Cost Models on Parent Order Data

A trading desk wants to know: "if I send an order to buy 500,000 shares over the next two hours, how much will it cost me relative to the price when I decided to trade?" That question is about a parent order — the whole 500,000-share instruction — not about any one of the hundreds of small child fills the algorithm slices it into. Yet it's tempting to build a cost model on the child fills, because that's the data sitting right there in the execution log, one row per fill, with a price and a timestamp. Training on child fills instead of the parent order is a subtle but consequential mistake.

Why the fill is the wrong unit

Each child fill is priced against whatever the market happened to be doing in its own tiny slice of time, but the thing the desk actually cares about — and the thing that determines whether the algorithm did a good job — is the average cost across the whole parent, measured against a benchmark fixed before trading started, usually the arrival price. A model trained fill-by-fill learns to predict the noise in each micro-slice rather than the systematic cost of moving the full size. Two parent orders that trade the same total quantity in the same stock on the same day can have wildly different child-fill patterns (different schedules, different venues) while landing at nearly the same average cost — and a fill-level model has no way to see that the parent-level outcome is what's stable and predictable.

Building the parent-level dataset

The training set should have one row per parent order, not one row per fill. Each row aggregates:

• Features known at order arrival: order size as a fraction of average daily volume, side, urgency/schedule chosen, spread and volatility over the preceding period, time of day.
• Label: the realized implementation shortfall — the volume-weighted average execution price minus the arrival price, signed by side and usually expressed in basis points.

Child fills still matter, but only as inputs that get aggregated up — e.g., the volume-weighted average price and the standard deviation of fill prices around it — not as separate training examples. This also fixes a subtler problem: child fills within one parent are highly correlated (they share the same market conditions and the same underlying decision), so treating them as independent training examples overstates the effective sample size and understates prediction uncertainty.

Worked example: two parent orders, very different fill counts

Parent order A buys 200,000 shares via an aggressive schedule and gets filled in 40 child trades; parent order B buys the same 200,000 shares more passively and gets filled in 400 child trades. If you trained fill-by-fill, order B would contribute ten times as many rows to the dataset as order A, even though it represents exactly one decision and one outcome — the model would implicitly learn to fit passive-schedule behavior ten times harder than aggressive-schedule behavior, for reasons that have nothing to do with which pattern is more common or more informative. Aggregating to one row per parent gives A and B equal weight, which matches how a trader would actually think about "how many decisions have I observed."

What this means in practice

Getting the training unit right changes everything downstream: the effective sample size, the feature set (order-level facts like total size and schedule choice rather than fill-level facts like a single trade's queue position), and the evaluation metric (implementation shortfall on held-out parent orders, not fill-price residuals). It also matters for backtesting a cost model honestly — you must split train and test sets by parent order (or by day), never by fill, or fills from the same parent order will leak between train and test.