Order Type Coverage in Simulators

A live exchange supports dozens of order types — market, limit, stop, stop-limit, pegged, iceberg, fill-or-kill, immediate-or-cancel — each with its own rules for when and how it trades. A backtesting simulator, by contrast, usually only implements the handful its author needed for the last strategy they tested. That gap is invisible until you backtest a strategy that leans on an order type the simulator doesn't model correctly, at which point the backtest reports numbers a live desk could never actually achieve.

Why coverage gaps are dangerous, not just incomplete

The danger isn't that an unsupported order type throws an error — it's that most simulators silently approximate it with something close enough to compile but not close enough to be true. A stop order that isn't natively supported might get modeled as "convert to a market order the instant the stop price trades," ignoring that a real stop order, once triggered, still has to queue and walk the book like any other market order — during a fast move it can fill many ticks worse than the trigger price. An iceberg order modeled as a single resting limit order hides its replenishment behavior, understating how much information it leaks to onlookers watching the book refill. A pegged order that isn't modeled at all often gets silently rounded to a static limit price, erasing the entire point of pegging — following the market as it moves.

What full coverage requires

A simulator with real order-type coverage needs, at minimum: correct queue and trigger semantics for stops, replenishment logic for icebergs, tracking rules for pegged orders relative to a reference price, and time-in-force logic (IOC, FOK, GTC, day) that actually cancels or expires orders on schedule. Each missing piece is a place where backtest and live trading can diverge in the direction that flatters the backtest — unrealistically good fills, unrealistically low information leakage, or orders that never expire when they should have.

Worked example: a stop-loss strategy that looks better than it is

Suppose a strategy exits with a stop-loss set 2% below entry. A simulator without native stop support instead checks, at each bar close, whether the low of the bar breached the stop level, and if so fills the exit at the stop price exactly. Over a 500-trade backtest this produces an average exit slippage of $0.00 per share on stop-outs. In live trading, on a genuine 2% gap-down move, the stop triggers and then has to cross a thinning book — real fills come in $0.03–$0.15 worse than the trigger price on the volatile names, and on the worst days, an entire cluster of stops firing at once pushes the price further before any of them fill. The backtest's assumed zero-slippage stop exits overstate the strategy's Sharpe ratio meaningfully, purely because the simulator's order-type model was too simple, not because the trading logic was wrong.

What this means in practice

Before trusting a backtest, check which order types the strategy actually sends live and how the simulator handles each one — not just whether it's "supported," but what fill model backs it. If a strategy is stop-heavy, iceberg-heavy, or peg-heavy and the simulator treats all of those as immediate fills at the requested price, the backtest is measuring a strategy that doesn't exist. The fix is either extending the simulator's coverage before trusting its output, or applying a conservative worst-case overlay on top of the reported fills for any order type it doesn't genuinely model.