Current Blog
How to Model Pegged Orders in a Trading Backtest
A pegged-order backtest recomputes eligible price from time-ordered quote events, applies the order's limit and venue rules, and records every repricing and priority change.
This article was prepared with AI assistance and checked through automated editorial and source review. No named human review is recorded.
A pegged-order backtest should recompute the order's eligible price whenever its reference quote changes. It should then apply the order's limit, offset, venue, session, and protocol rules before testing execution. A bar close or a quote observed later cannot stand in for that event sequence.
Store the submitted instruction separately from its working state. The instruction contains side, peg type, limit, offset, size, venue, protocol, and time in force. The working state contains the reference bid and offer, calculated peg price, effective book price, availability, priority timestamp, and remaining quantity.
Reprice from time-ordered reference quotes
The current Nasdaq Equity 4 rules describe primary pegging with reference to the inside quotation on the same side, market pegging with reference to the opposite side, and midpoint pegging with reference to the midpoint between the inside bid and offer. The order's exact behavior still depends on its other attributes and entry protocol.
Process each quote update at its source timestamp. Calculate the reference value only from the bid and offer available at that instant. Apply any documented peg offset, then enforce the order's limit price. Keep the raw quote, calculated price, rounded price, and final working price as separate ledger fields so a later review can reproduce every step.
Work a three-quote example
Assume a synthetic buy order entered through a protocol whose venue rule reprices the selected peg. Use no offset, a $50.06 buy limit, one-share price increments of $0.01 except where midpoint pricing is allowed, no routing, and no execution before the final quote event.
At 09:30:00.000 ET, the national best bid and offer are $50.00 and $50.04. A primary buy peg references $50.00, a market buy peg references $50.04, and a midpoint buy peg references $50.02. At 09:30:00.125, the quote becomes $50.01 by $50.05, so the three reference prices become $50.01, $50.05, and $50.03.
At 09:30:00.240, the quote becomes $50.03 by $50.08. The primary reference becomes $50.03. The market reference is $50.08, but the $50.06 limit prevents the buy order from working above $50.06. The midpoint is $50.055 before any venue-specific price handling. This is illustrative arithmetic, not an observed Nasdaq fill.
Treat repricing as an order-state event
Do not overwrite the old price in place. Append a reprice event with the triggering quote, old price, new price, venue time, local receipt time, and resulting priority. Nasdaq's current rule says an order entered through RASH or FIX with pegging receives a new timestamp when its price is updated. Other protocols and order variants can behave differently, so a simulator needs a versioned rule table rather than one universal priority shortcut.
The current Nasdaq OUCH 5.0 specification exposes distinct price-type values for market, midpoint, primary, and market-maker pegs, plus a signed peg-offset field. Preserve those entered attributes. A normalized label such as “pegged” is not enough to reconstruct price or priority.
When price changes reset priority, connect the new state to the queue-position model. When a venue or protocol preserves priority in a documented case, record that rule explicitly. Never infer priority retention merely because the order identifier did not change in a normalized dataset.
Handle missing, locked, and crossed markets explicitly
A midpoint calculation needs both sides of the reference market. Nasdaq's current rules distinguish locked, crossed, and missing inside markets, and they describe rejection, temporary unavailability, removal, re-entry, or cancellation in different circumstances. Model those as named states. Do not carry forward a stale midpoint through a period when the rule makes the order unavailable.
The rule also states that a midpoint-pegged order can be ranked at its limit when the buy limit is below the midpoint or the sell limit is above it. That is why the simulator must calculate the reference first and apply the limit second. A limit is a protection boundary, not a replacement reference.
Separate venue time from strategy time
The book may reprice the order before the strategy receives the quote or acknowledgment. Preserve venue event time and local receipt time as described in the latency model. Venue state follows venue sequence. The strategy can react only when the information reaches its clock.
Historical top-of-book data can reproduce a reference path, but it does not prove a fill or exact queue allocation. Test execution using observable trades, depth, and venue rules, then report uncertainty. Enforce the original cap through the limit-order model and terminate the order through the time-in-force model.
Validate the state machine
No calculated buy price exceeds its limit, and no calculated sell price falls below its limit.
Every reprice cites the quote event and rule version that caused it.
Midpoint arithmetic uses contemporaneous bid and offer values with documented precision.
Priority changes match the venue, protocol, and order variant.
Missing or crossed references create the documented unavailable, reject, cancel, or re-entry state.
Venue time and local receipt time remain distinct.
A fill is never inferred from the peg price alone.
Test a steady market, one-tick moves, a limit-bound peg, locked and crossed quotes, a missing side, rapid quote changes, delayed messages, cancellation during repricing, session boundaries, and out-of-order local receipt. If the historical feed cannot reconstruct the required reference or priority rule, mark the result unverified instead of filling the gap with a later quote.
