Intrabar Path Ambiguity in OHLC Bars

An OHLC bar compresses an entire minute, hour, or day of trading into four numbers. That's the whole point of the format — but it throws away the one thing a backtest with a stop-loss and a profit target both needs: the order in which prices were touched. If a bar's high would have hit your target and its low would have hit your stop, the bar alone cannot tell you which happened first. A backtest has to guess, and most guess wrong in a consistent direction.

Worked example: the bar that pays out twice

Enter long at 100 with a target at 105 and a stop at 95. The next bar prints Open 101, High 106, Low 94, Close 101 — both the target and the stop were touched somewhere inside that bar.

Assumed path	Result	P&L
High reached before Low	Target fills first	+5
Low reached before High	Stop fills first	−5

The true answer is unknowable from the bar alone — it depends on tick-by-tick data the backtest doesn't have. A naive engine that always checks "did we hit the target?" before "did we hit the stop?" will resolve every one of these ambiguous bars in the profitable direction, every single time. Run that over a few hundred trades and the strategy looks like it has a positive expectancy that is actually just a coin flip resolved in its own favor by the code's evaluation order.

Quantify it: suppose ambiguous bars (both levels touched) occur on 15% of the 400 trades a strategy takes per year, i.e. 60 trades. If the true intrabar order is a coin flip, the "always check target first" bug overstates annual P&L by roughly 60 trades × 10-point swing × 0.5 probability = 300 points of pure fiction, on top of whatever the strategy actually earns.

The honest fixes: use intrabar tick or sub-bar data where the strategy's economics depend on exit ordering, or, when only OHLC is available, resolve ambiguous bars pessimistically (stop wins ties) and report the pessimistic and optimistic bounds together so the reader sees how much of the edge depends on a guess.