Residual Quantity Handling After Partial Fills

Real orders rarely fill in one clean shot. A 10,000-share order might fill 3,000 shares against the first sweep of the book, leave 7,000 resting, get 2,000 more filled a minute later, and then need a decision: keep waiting, chase the price, or give up on the rest. That leftover amount — the residual quantity — is one of the most consequential and most casually modeled pieces of a backtesting simulator, because what happens to it determines both how much of the intended trade executes and at what average price.

Why the residual matters more than the first fill

A strategy's realized return depends on its average fill price across the whole order, not just the price of the first slice that traded. If a simulator assumes the residual fills instantly at the next available price, it understates how much the strategy has to pay to complete large orders — the real market doesn't provide unlimited liquidity on demand. Conversely, a simulator that never fills residuals realistically (say, it cancels anything not filled within one bar) understates capacity, making strategies look artificially small and low-turnover. Both errors move the backtest's competitiveness in a specific direction, and it's rarely the conservative one.

The decision tree a simulator must encode

For every partial fill, the residual has to go somewhere, and each choice has a real-world analog:

• Cancel the residual — models an aggressive, one-shot execution style; understates achievable size.
• Requeue at the same price — models patient limit-order behavior; the residual re-enters the queue, possibly behind new orders that arrived while it was executing (queue position is not preserved automatically).
• Re-price and requeue (chase the market) — models an execution algorithm's urgency schedule; needs its own price-adjustment logic, usually tied to a schedule like TWAP or VWAP.
• Route to a different venue — models smart order routing; requires the simulator to model multiple venues at once (see multi-venue simulation).

A simulator hardcoding just one of these behaviors regardless of the order's actual instructions will misrepresent every strategy whose execution logic depends on a different one.

Worked example: a 5,000-share limit order in three fills

A strategy sends a 5,000-share buy limit at $50.00. The book:

1. First fill: 1,200 shares at $50.00 (existing queue ahead consumed).
2. Residual: 3,800 shares, requeued at $50.00, now behind 2,000 shares of new order flow that arrived after the initial fill (correct queue modeling puts it behind them, not ahead).
3. Second fill: 1,800 shares at $50.00 fifteen seconds later.
4. Remaining residual: 2,000 shares. Strategy logic says cancel unfilled quantity after 30 seconds — those 2,000 shares never trade.

Total executed: 3,000 of 5,000 shares (a 60% fill rate) at $50.00 average — a very different outcome from a simulator that naively assumes the full 5,000 fills because the limit price was touched. Getting the queue position of the residual right, and honoring the cancellation rule, changes both the realized size and the realized capacity of the strategy.

What this means in practice

When auditing a simulator, ask explicitly what happens to the shares that don't fill on the first pass. If the answer is "they fill automatically at the next price" or "they're ignored," the backtest is misrepresenting both fill rate and average execution price for anything larger than top-of-book size. Getting residual handling right — correct queue position, cancellation timing, re-pricing logic — is unglamorous but directly determines whether a backtest's capacity and cost estimates are believable.