Current Blog
How to Model Reserve Orders in a Trading Backtest
A reserve-order backtest separates displayed and non-displayed quantity, applies venue-specific replenishment rules, and assigns priority at every child-order event.
This article was prepared with AI assistance and checked through automated editorial and source review. No named human review is recorded.
A reserve-order backtest should keep three quantities separate: total remaining quantity, currently displayed quantity, and non-displayed reserve quantity. Fills, replenishments, replacements, and cancellations must reconcile across all three. Public depth data usually reveals the displayed slice, not the reserve behind it.
Treat each replenishment as a venue event. The new displayed slice may receive a new working time or child-order identity even when the reserve interest retains older priority. A simulator that restores the display without updating priority can overstate fills.
Represent one instruction as linked order states
Store the parent instruction, every displayed child, the reserve balance, venue, accepted time, price, time in force, and rule version. The parent controls total quantity. Each child controls the visible slice and its own priority. Keep the original venue fields before normalizing them for research.
The current Nasdaq Equity 4 rules describe Reserve Size as an attribute that lets a displayed order replenish from additional non-displayed size. The rule also distinguishes the displayed order from non-displayed reserve interest. That structure should appear directly in the simulation ledger.
Do not infer reserve from public depth
Nasdaq describes TotalView-ITCH as an order-level feed for the displayed book. A visible order that repeatedly returns at the same price may be a reserve order, several independent orders, or unrelated cancellations and entries. Public messages alone do not reveal the participant's full hidden balance.
Choose an evidence mode before testing. A participant-order log can model known reserve instructions. A public-feed backtest should model only displayed events and label any reserve reconstruction as an assumption. Do not let later executions reveal hidden size to earlier simulated decisions.
Work a replenishment example
Assume a synthetic buy limit order for 1,500 shares at $50.00 has posted with 200 shares displayed and 1,300 shares in reserve. Ignore routing, fees, other same-price orders, and latency after venue acceptance. A marketable sell order executes 150 shares against the displayed child.
The parent now has 1,350 shares remaining. The original displayed child has 50 shares. Under the Nasdaq rule's round-lot replenishment behavior, another 200-share displayed child can be entered while 1,100 shares remain non-displayed. The quantities reconcile: 50 displayed + 200 replenished + 1,100 reserve = 1,350 shares.
Record the original 50-share child separately from the replenished 200-share child. The rule assigns the new displayed order a new timestamp while the non-displayed interest retains its original timestamp. The example is illustrative, not an observed execution result.
Apply venue-specific priority and entry rules
Nasdaq's rule states that the full size of a reserve order may be presented for potential execution on entry before unexecuted quantity is processed into displayed and non-displayed portions. It also specifies how displayed quantity is replenished and timestamped. Those details are not safe to replace with a generic iceberg label.
The current NYSE rulebook likewise describes displayed children, reserve interest, replenishment below a round lot, and working times. Its combinations, routing behavior, and cancellation sequence are venue-specific. Version the rule by venue and effective date, then connect it to the same queue-position model used for ordinary displayed orders.
Update fills, cancels, and replacements atomically
Every execution first reduces the child that traded, then total remaining quantity. Replenishment transfers quantity from reserve to a new displayed child without changing the parent total. A cancellation or size reduction must follow the venue's sequence across reserve and displayed children. A replacement may change display size, total size, price, or priority.
Feed each execution into the partial-fill ledger. Enforce the parent price through the limit-order constraints and expire all linked states through the time-in-force model. Never leave a child live after its parent is terminal.
Test observability and conservation
Displayed quantity never exceeds total remaining quantity.
Displayed children plus reserve quantity equal the parent remainder.
A replenishment creates the venue-required working time and child identity.
Public-feed mode never reads undisclosed reserve quantity.
Executions never exceed the active child's eligible quantity.
Cancel, replace, reject, and expiry events terminate the correct linked states.
Every fill still obeys price, session, and timestamp constraints.
Test no reserve, reserve smaller than one display slice, partial depletion, full depletion, several replenishments, a same-timestamp fill and cancel, a size reduction, a price replacement, an early close, and an incomplete feed. When the source cannot identify hidden quantity or participant identity, publish the limitation instead of fitting reserve size to the fills that happened later.
