Current Blog
How to Model Order Replacements in a Trading Backtest
A replacement-aware backtest preserves the original order, resets priority when the venue does, reconciles in-flight fills, and links every accepted replacement to a new identifier.
This article was prepared with AI assistance and checked through automated editorial and source review. No named human review is recorded.
A replacement-aware backtest should keep the original order live until the venue accepts a replacement. At acceptance, it should end the original order, create the accepted replacement under a new identifier, and reset time priority when the venue rule requires it. Earlier fills remain attached to the original lifecycle.
Do not overwrite price or quantity when the strategy sends the request. A request can arrive after another fill, be ignored because the original is no longer live, cancel the old order when the proposed replacement is invalid, or be rejected while the existing order remains active.
Treat replacement as a state transition
The Nasdaq OUCH 5.0 specification defines Replace Order as an atomic request that cancels an existing order and replaces it with a new order. It carries the old and new user reference numbers, and the new number must be unique for the session. A successful response reports both references.
Represent the lifecycle as original live, replacement pending, then one venue-confirmed outcome. Preserve the request and response as separate events. This extends the timestamp separation in the latency model because the old order can still execute while the request is in flight.
Reset priority when the venue does
OUCH states that replacement gives the order a new timestamp for time priority. Nasdaq's current U.S. equities trading description says displayed limit orders use price and time priority, with equally priced orders ranked by receipt. A simulator should therefore place an accepted replacement behind displayed orders already resting at the same price when it receives its new timestamp.
Do not confuse replacement with partial cancellation. OUCH says a partial cancel retains time priority. If a strategy only reduces quantity through the venue's supported cancel mechanism, apply that rule instead. Feed the accepted event into the queue-position model rather than carrying forward an unsupported queue estimate.
Work through an event sequence
Consider a synthetic buy order for 500 shares at $40.00 with original reference A. The venue accepts it, then 100 shares execute before a pending replacement is accepted. The strategy sends a replacement with new reference B and a total cumulative liable quantity of 500 shares.
The OUCH example for this sequence reports the replacement with 400 shares remaining. The arithmetic is 500 total liable shares minus 100 already executed shares. If 7,400 shares at $40.00 are ahead when B is accepted, B joins after that displayed quantity under price-time priority. The 7,400-share queue is illustrative, not a Nasdaq measurement.
Store A as partially executed and ended by replacement. Store B as a distinct accepted order with 400 shares live. Link both records through the replacement event. Do not move the 100-share execution onto B or pretend B existed before acceptance.
Reconcile fills already in flight
Quantity semantics matter. OUCH specifies replacement quantity as the total cumulative quantity for which the order chain is liable, including shares already executed. It also shows an execution on the original reference arriving before the replacement response. The accepted remaining quantity is the authoritative result.
Process events in venue sequence, then apply local arrival times for what the strategy knows. A fill can occur before acceptance yet reach the strategy after a replacement acknowledgment. Preserve both orders in the research data-lineage trail so accounting follows venue state instead of message arrival order.
Keep identifiers and accepted values
The Nasdaq TotalView-ITCH specification says an Order Replace removes the remaining original shares and assigns a new order reference number for subsequent updates. It also supplies the replacement price and displayed quantity. Keep the original and new identifiers, requested values, accepted values, and sequence numbers.
Accepted values can differ from submitted values. Apply the venue response to the live simulation and retain the request for audit. Reuse the price and quantity constraints from the limit-order model. Venue protocols differ, so these Nasdaq rules should not be generalized to markets with different amendment semantics.
Test every terminal outcome
A robust simulator needs more than the successful path. Test an ignored request after the original has already left the book, a reused replacement identifier, an invalid proposed replacement that cancels the old order, and a rejection that leaves the old order active. Match each outcome to the protocol evidence for the venue and period being modeled.
The original stays live until venue-confirmed replacement or cancellation.
Executions never disappear when identifiers change.
A new timestamp resets queue priority when required.
Remaining quantity equals accepted chain liability minus cumulative executions.
Subsequent updates use the accepted replacement identifier.
Rejected or ignored requests do not create phantom orders.
When historical protocol evidence is incomplete, publish the assumption and test a sensitivity range. A replacement model is credible when every quantity, timestamp, identifier, and terminal state can be reconstructed from the event log.
