Quant Memo
Core

Tick-Driven Versus Bar-Driven Simulation

A backtest engine can process markets one price change (tick) at a time, or one aggregated OHLC bar at a time — the choice trades simulation fidelity for speed and data cost, and picking the wrong one for a given strategy quietly changes what the backtest is even capable of catching.

Prerequisites: Intrabar Path Ambiguity in OHLC Bars

An OHLC bar collapses everything that happened in, say, a five-minute window into four numbers: open, high, low, close. That's enormously convenient — small data, fast backtests, simple logic — but it's also a lossy compression of reality: the bar doesn't tell you when within those five minutes the high and low occurred, or whether the price touched your limit order once briefly or sat through it for two minutes. Tick-driven simulation avoids that loss by processing every individual price or quote update as it actually occurred, at the cost of vastly more data and compute.

What each approach can and can't see

Bar-driven simulation is fine for strategies that trade at a similarly coarse timescale and don't depend on intrabar sequencing — a daily rebalancing strategy doesn't care whether the day's low came before or after the high. It breaks down for anything that reasons about order within the bar: a stop-loss and a take-profit both inside one bar's high-low range creates real path ambiguity — did price hit the stop first or the target first? — that a bar alone cannot answer, forcing the backtest to guess (see intrabar path ambiguity). Tick-driven simulation resolves this by construction, since it processes the actual sequence of price changes, but it costs orders of magnitude more storage and runtime, and for many candidate signals that extra fidelity buys nothing because the strategy's own logic doesn't operate at that resolution anyway.

high low tick path (actual order of events) O 120H 60L 160C 100 one OHLC bar
The tick path shows exactly when and in what order the high and low occurred, and how many times each level was touched; the OHLC bar keeps only four numbers, discarding the sequencing entirely.

Worked example: a stop-and-target strategy

A strategy enters long at 100, with a stop at 95 and a target at 108. On a bar-driven backtest, the day's bar shows open 100, high 110, low 93, close 105 — both the stop and target were "hit" somewhere in that range, but the bar alone can't say which came first. A naive bar-driven engine has to pick a convention (often "assume the worse outcome" or "assume open-to-close direction"), and that convention becomes a hidden assumption baked into every such trade in the backtest. A tick-driven replay of the same day shows the actual sequence: price dropped to 93 at 10:15am (stop triggered, loss realized) before ever reaching 108, which only came at 2:30pm — after the position was already closed. The bar-driven version, using an optimistic convention, might have booked the win instead, materially overstating performance on every trade where this ambiguity arises.

What this means in practice

Choose granularity based on what the strategy's logic actually depends on: pure end-of-bar signals with no intrabar order-dependent rules are safe on bars; anything with stops, targets, or same-bar entry-and-exit logic needs tick data or an explicit, conservative convention for resolving the ambiguity. When bar data is used for expedience, document the assumption used for path ambiguity and stress-test the backtest under the opposite (worse-case) convention to see how much of the edge depends on the guess.

Bar-driven simulation is fast and lightweight but discards the order in which events happened within each bar; tick-driven simulation preserves that order at much higher data and compute cost. Any strategy logic that depends on intrabar sequencing — same-bar stops and targets being the classic case — needs tick data or an explicit, stated convention, not a silent default.

Related concepts

Practice in interviews

Further reading

  • Harris, Trading and Exchanges, ch. 2
ShareTwitterLinkedIn