4. The Bar Resolution Problem

4.1 Why Every Bar Conceals Information

Every OHLC bar, regardless of its timeframe, is a lossy compression of the true price path. A bar records the open, the high, the low, and the close, but nothing about the trajectory between them. Any order that could have been triggered at some point within the bar (a stop-loss, a limit entry, a profit target) must be evaluated against a price path that the bar does not fully describe. The backtesting engine must therefore make assumptions about what happened inside the bar, and those assumptions may or may not correspond to reality.

This problem exists at every level of aggregation, but its severity is a direct function of bar size. At fine granularity (one-minute or five-minute bars) the price range within each bar is typically small, the number of plausible intra-bar paths is tightly constrained, and the assumptions required to evaluate orders introduce only modest error. For the vast majority of retail systematic trading, backtesting with bars of this granularity provides results that sufficiently approximate reality. The exception is high-frequency scalping, where even sub-minute price dynamics and order book position matter, but this is generally outside the domain of the retail trader.

As bar size increases, so does the divergence between what the backtest assumes and what would have occurred in live trading. An hourly bar conceals more than twelve five-minute bars; a daily bar conceals far more than all its hourly bars. The high-to-low range of a daily bar in a liquid futures contract can easily span two or three percent, a range within which stops and profit targets may both have been triggered, but the bar provides no information about the sequence in which prices were visited. Over thousands of trades across a multi-year backtest, these guesses compound into a systematic bias. The intuition that these errors should cancel out (that random guesses about intra-bar paths would overstate some trades and understate others in roughly equal measure) is understandable but wrong. The net effect is an optimistic overstatement of performance. The mechanism is survivorship within the backtest itself: when the engine guesses that a stop was not triggered (because it cannot see the intraday breach), the position survives and participates in subsequent price recovery. The symmetric error (guessing that a profitable target was not reached) is less consequential, because the position simply remains open and is eventually closed by another signal. In net, errors on the loss side tend to be eliminated from the record while errors on the profit side tend to be deferred rather than eliminated, producing a directional bias that systematically flatters the equity curve. This error is most visible on systems that can have a profitable exit or stop loss triggered on the same bar.

This failure is most acute, and most widespread, at the daily bar level, because a large number of retail traders use end-of-day (EOD) daily bars data as the foundation for their backtesting. Many do so in the belief that, because they are developing longer-term strategies with weekly or monthly signals, the intraday price path is irrelevant.

This belief is fundamentally incorrect.

A strategy’s signal generation timeframe and its order evaluation timeframe are separate concerns. A trader may generate signals from daily or weekly bars, but the orders those signals produce (stops, limits, targets) interact with the market continuously, not at daily intervals. Any strategy that places a stop-loss is implicitly asking the market a question about the intraday path: “did price reach this level at any point during the session?” End-of-day data cannot answer that question reliably.

Consider a long-term trend-following system that uses a trailing stop. The daily close may show a price comfortably above the stop level, but the intraday low may have breached it. If the strategy is implemented live with a resting stop order, the stop will be triggered by the intraday breach; if the backtest only sees the daily close, it will show the position as still open. Over a multi-year test, this discrepancy accumulates. The backtest will show a strategy that holds through intraday volatility and captures the subsequent recovery, while the live strategy will have been stopped out. The result is a systematic positive bias in the backtested equity curve relative to achievable performance. The specific failure mode this creates (the OHLC sequence ambiguity, in which multiple orders could all have been triggered within a single bar but in an unknowable order) is examined in detail in Section 4.2 .

The stop-concealment problem is compounded on some platforms by the complete absence of out-of-session order evaluation. In TradeStation, for example, a stop order placed at the session close is simply not evaluated until the next session opens. For futures contracts that trade nearly twenty-three hours per day (the remaining hour being a maintenance window that most traders forget exists until it catches them), this means that overnight price movement through a stop level is invisible to the backtesting engine: the stop is never triggered, the position survives, and the backtest records a different outcome than would have been produced in live trading.

This limitation would not arise if the backtest were configured to use the full trading session, the entire period during which the exchange accepts orders. But many traders do not want to execute entries outside of regular trading hours (RTH), preferring to restrict their algorithms to a subset of the full trading day, such as the equity regular session from 9:30am to 4:00pm Eastern time. This is a legitimate design choice: RTH sessions typically offer deeper liquidity and more representative price discovery. Restricting entries to the RTH session while still evaluating protective exits across the full session is, in fact, the way most traders would operate in live markets. But implementing this distinction (entries only during RTH, exits active at all times) requires the platform to treat entry and exit orders differently with respect to session boundaries, and platforms that lack this capability force the trader to choose between two unsatisfactory alternatives: use the full session for everything (accepting entries at potentially illiquid overnight prices) or restrict the entire strategy to RTH (leaving stops unevaluated outside those hours).

The trader who chooses the latter, restricting the session to RTH, eliminates the need for complex time-of-day management in the strategy code. Without this restriction, the code must determine whether the current bar falls within the desired trading window, whether the next bar will be the last bar before the window closes, and so on. This is already non-trivial for a single instrument, but it becomes especially difficult when trading symbols across multiple time zones, where the RTH windows in the trader’s local time shift with daylight saving transitions in both the trader’s location and the exchange’s location.

Platforms like TradeStation make this difficulty worse still by requiring all time references in strategy code to be expressed in the user’s local computer time, regardless of where the traded instrument’s exchange is located. This means the researcher must manually convert every session boundary and time-based condition from the exchange’s native time zone to their own, and must track the daylight saving schedules of both zones to ensure the conversion remains correct throughout the year. The variations are not negligible: depending on whether the local user’s time zone and the exchange’s time zone are independently entering or leaving daylight saving time, the apparent start time of a session can shift by one hour or, in some cases, two hours relative to the user’s clock. This can be the difference between evaluating a bar at 9:00am and evaluating one at 11:00am, a distinction with material consequences for any strategy that references time of day. The issue can be worked around with careful coding, but it represents an extra source of logic errors and needless overhead, one that is entirely a platform artefact rather than an inherent difficulty of the problem. In practice, most traders either give up on strategies that require this kind of cross-timezone session management, or proceed without realising that the underlying time-conversion issues exist at all, silently corrupting their backtest results in ways that may never be detected.

4.2 The OHLC Sequence Ambiguity

The information loss described above produces a specific and well-defined failure mode when a strategy generates multiple price-contingent orders that could both trigger within a single bar. A bar compresses an entire continuous price path into four numbers: open, high, low, close. The true tick-by-tick sequence between the open and the close is destroyed, but during the bar price visited some ordered path that touched both the high and the low. At least two paths are consistent with any given OHLC quadruple:

• Path A: open $\to$ high $\to$ low $\to$ close.
• Path B: open $\to$ low $\to$ high $\to$ close.

These are not equivalent for a strategy that has both a profit target and a stop loss live inside the bar. On Path A the target fills first; on Path B the stop fills first. The realised profit and loss from those two paths can have opposite signs, yet the bar looks identical in the data file.

Consider a concrete example: a system enters long at the open at 100, with a stop at 98 and a target at 104. The day’s OHLC is 100/105/97/103. Both the stop and the target were reached during the session. The system’s result depends entirely on which was hit first. If the market rallied to 105 before declining to 97, the target was achieved and the trade is a winner. If the market dropped to 97 first, the stop was triggered and the trade is a loser. The daily bar does not contain this information.

4.2.1 Why engines have to guess, and why they guess optimistically

Without tick or sub-bar data, a backtester cannot know in which order the high and the low occurred. It has to adopt a convention. Four conventions are common, and each is unsatisfactory in its own way:

1. Assume high-before-low on up bars (close $\geq$ open) and low-before-high on down bars. Superficially reasonable but completely unjustified at intra-bar resolution. Plenty of up bars spike down first; plenty of down bars spike up first. The convention encodes a folk belief about intra-bar dynamics that the data themselves cannot support.
2. Assume the favourable level is hit first (target before stop on a long trade, stop before target where the stop is the upside). Wishful thinking, and the one that inflates equity curves most dramatically.
3. Assume the unfavourable level is hit first. Conservative, and the only safe default. It under-reports profitability rather than over-reporting it, which is the right direction for the error to point.
4. Fill both orders on the same bar in entry order, or net them out. Incoherent: both orders cannot have executed at their respective trigger prices on the same realised path unless the path order is known.

Most retail engines end up at something close to convention 1 or convention 2 in their default configuration. Backtrader, for example, processes intra-bar orders in queue submission order, with the consequence that an entry, target, and stop submitted together cannot all be honoured correctly within the entry bar; the limitation is discussed further in Section 7 . The practical effect of the default behaviour is the same regardless of how it is rationalised: when a bar’s range straddles both the target and the stop, the engine tends to book the winner.

A small number of better-designed engines surface the choice as an explicit setting on the strategy, with four typical values that correspond directly to the four conventions above. A “best-guess” mode uses the close-versus-open heuristic of convention 1: if the bar closed above its open the low is assumed to have come first, and vice versa. A “stop-first” mode hard-wires convention 3: whenever a bar’s range contains both levels, the stop is assumed to have been hit, regardless of where the bar closed. A “target-first” mode hard-wires convention 2 in the opposite direction, assuming the favourable level was hit first. A “neither” mode declines to resolve the ambiguity at all: if the sequence cannot be inferred without guessing, the bar simply produces no exit, and the position carries forward to be resolved by the next bar or by some other exit rule. Exposing the choice as a strategy parameter is a marked improvement over silently encoding it as a default, because it forces the researcher to think about which assumption is being made and to live with the consequences. The “stop-first” and “neither” modes are the only defensible choices; the “best-guess” mode is a folk heuristic dressed up as a default; the “target-first” mode is an active misrepresentation of the strategy’s performance and should never be used.

4.2.2 Why this overstates profitability rather than just adding noise

If the convention were unbiased – equivalent to flipping a fair coin per bar to decide which level was hit first – the resulting error would be noise around the true expectancy and would shrink with sample size. The trap is that the bias is systematically in the strategy’s favour, for three independent and compounding reasons.

The first is conditional sampling. The path assumption only matters on bars whose range contains both the target and the stop. On every other bar the outcome is unambiguous and the convention is irrelevant. The engine’s guess is therefore not being averaged over all bars but over the subset of bars where reality is itself a coin flip between $+kR$ and $-R$, where $R$ is the risk per unit and $k$ is the reward-to-risk ratio. If the engine resolves all of those ambiguous bars as wins, the error per ambiguous bar is not “$+kR$ half the time, $-R$ half the time, mean zero”. It is “$+kR$ every time, when truth is $+kR$ half the time and $-R$ half the time”, and the expected error per ambiguous bar is:

That is strictly one-signed (positive) and scales with the strategy’s reward-to-risk ratio. It does not cancel across bars because every draw is biased in the same direction. Running more bars tightens the estimate of a positive number, not of zero. Worse, the cleaner the strategy looks, the more acute the problem: a tight stop and a tight target relative to typical bar range increase the fraction of bars that are ambiguous, and therefore the fraction of trades that are subject to the bias. Scalping systems on hourly bars and mean-reversion systems on daily bars are the worst offenders, because the daily range routinely engulfs both bracket levels.

The second reason is asymmetric, discontinuous payoffs. Even if the engine’s path guess were genuinely unbiased – a fair coin per ambiguous bar – the payoffs themselves are not symmetric around the entry. A bracket trade pays $+kR$ on a target hit and $-R$ on a stop hit, where $k$ is generally not 1 and the distribution of which level is closer to entry is itself skewed by how the strategy was designed. Strategies are almost never built with target and stop equidistant from entry in tick terms; they are built around an asymmetric reward-to-risk ratio that the trader believes carries positive expectancy. The engine’s guess interacts with that asymmetry, and the interaction has a non-zero mean unless the path distribution is exactly the inverse of the payoff asymmetry, which would require knowing the true intra-bar process. Even an unbiased coin produces biased profit and loss, because the expectation of a product is not the product of expectations when the terms are correlated with the strategy’s structure.

The third reason is survivorship through the optimisation loop, and it is the one that turns a small per-bar bias into a catastrophic equity-curve illusion. A strategy is not backtested once. It is backtested across hundreds of parameter combinations, of which the best is kept. The path-assumption bias is largest for parameter sets with tight stops and tight targets relative to bar range – exactly the parameter sets that look most attractive on the inflated metric. The optimiser therefore preferentially selects strategies whose apparent edge is the most contaminated. The bias is not just non-zero on average; it is concentrated in the region of parameter space the search is going to pick. This is a close cousin of the Bailey and López de Prado backtest-overfitting argument discussed in Section 5 , but with a sharper edge: it is not only that the search is data-mining noise, it is that the search is data-mining a systematically positive artefact. Even an honest, non-overfit search procedure will be pulled toward the contaminated region because that region has the highest reported Sharpe ratio by construction.

The symmetry intuition that “the errors should cancel” implicitly assumes the error is additive Gaussian noise on a fixed underlying signal: engine profit and loss equals true profit and loss plus an independent zero-mean disturbance. Under that model the disturbance averages out and its standard error shrinks like $1/\sqrt{N}$. The actual error model is multiplicative and conditional: the error is non-zero only on ambiguous bars, the indicator for “bar is ambiguous” is not independent of the strategy’s parameters, the bracketed payoff difference has strictly non-negative mean under any optimistic convention, and the whole expression is then maximised over a parameter grid. None of those three properties is present in the additive-noise mental model that makes “it averages out” feel obvious. Stated formally, the path assumption is a biased estimator of a path-dependent functional, and bias does not vanish with sample size. Variance vanishes; bias persists. A long backtest of a path-sensitive strategy on OHLC data converges, with high confidence, to the wrong answer.

4.2.3 What it looks like in equity

A strategy that is genuinely break-even after costs can show a smooth, monotonic equity curve in a naive event-driven backtest with intra-bar exits enabled. Sharpe ratios in the 2 to 4 range on daily bars for a mean-reversion system with tight stops are almost always this artefact. When the same logic is re-run against tick data, or against minute data honestly resampled, the curve typically collapses to a random walk or worse, because the ambiguous bars redistribute roughly 50/50 and the cost structure (commissions, the real fill price on stops) accounts for the rest. The diagnostic in Section 4.5 , which compares a daily-bar backtest of a strategy to the same strategy run with orders evaluated against the underlying minute data, is the direct empirical manifestation of this bias.

4.2.4 Honest mitigations

The trader who acknowledges the ambiguity has several options, ordered roughly from cheapest to most rigorous:

• Pessimistic resolution. When a bar contains both bracket levels, always assume the stop was hit first. This is the “stop-first” mode described above. It produces a lower bound on strategy profit and loss and is the only convention that does not lie to the researcher. Where the engine also offers a “neither” mode that declines to resolve the ambiguity at all, that is more conservative still: it produces no exit from the ambiguous bar and defers resolution to a subsequent bar or exit rule, at the cost of holding the position through an interval the strategy may have intended to close.
• Sub-bar data. Drop to a granularity at which the ambiguity is rare. If the target and the stop are 50 basis points apart, the backtest needs bars whose typical range is much smaller than 50 basis points, not larger.
• Tick or quote replay on ambiguous bars. A hybrid approach that keeps the bulk of the backtest cheap by running at bar resolution, while resolving the ambiguous bars honestly against the recorded intra-bar path.
• Explicit bracket-order semantics. Model the bracket as a single atomic construct rather than as two independent orders that the engine arbitrates between, and acknowledge that on the entry bar itself most retail engines cannot honour an intra-bar exit at all (the Backtrader IBOG limitation discussed in Section 7 ).
• Report the spread. Run the backtest twice, once with the optimistic convention and once with the pessimistic one. If the two equity curves diverge meaningfully, the strategy’s edge is inside the simulator’s measurement error, and no edge has actually been demonstrated.

The deeper point is that this is not a bug in any particular backtesting engine. It is an information-theoretic limit. OHLC is a lossy compression of the price process, and any strategy whose payoff is sensitive to intra-bar ordering is computing a function the input data cannot support. The engine is forced to fabricate the missing information, and the fabrication is not neutral. For the trader constrained to coarse bar data, the operational conclusion is straightforward: either move to intra-bar order evaluation along the lines discussed in Section 4.5 , or design strategies whose order logic does not generate multiple price-contingent orders that could both trigger within a single bar.

4.3 Settlement Price versus Last Trade

In futures markets, a further subtlety arises from the distinction between the settlement price and the last traded price. The daily settlement price is determined by the exchange using a methodology that may incorporate trades, bids, offers, and spread relationships during a defined settlement window. It is not simply the last trade of the day. In illiquid contracts or far-dated maturities, the settlement price may differ significantly from any price at which a trade actually occurred. A backtest that treats the settlement price as an achievable execution level is implicitly assuming liquidity that may not have existed.

This distinction is particularly important for calendar spread strategies and relative-value approaches, where the settlement prices of individual legs are used to calculate spread values. Because settlement prices are determined by a formulaic process, the implied spread may never have been directly tradable at the reported level.

An analogous problem exists in equity markets, where the “close” price in a daily bar is typically the result of a closing auction, a discrete price-setting mechanism with different fill dynamics than continuous trading. Closing auctions concentrate substantial volume into a narrow window, and participation requires submitting orders that compete for priority in the auction’s matching algorithm. A backtest that assumes the strategy can execute at the official closing price is implicitly assuming the strategy has priority in an auction that may be dominated by index funds, ETF creation/redemption flows, and institutional rebalancing activity. For strategies that generate signals from the daily close and assume execution at or near that price, the gap between the auction print and the price achievable by a retail participant submitting a market order in the final minutes of continuous trading can be material, particularly on days with large index reconstitution or options expiry flows. This is one of the most common institutional-versus-retail backtest discrepancies, and it is almost never modelled in retail backtesting engines.

4.4 Volatility and Risk Estimation

Position sizing in many systematic strategies is based on volatility estimates, commonly derived from daily close-to-close returns. But close-to-close volatility understates true intraday risk exposure. A market that opens sharply against a position, trades at extreme levels during the session, and then recovers to close near the prior day’s level will appear benign in a close-to-close volatility calculation. The position holder, however, experienced substantial mark-to-market drawdown and, if leveraged, may have faced margin calls that forced liquidation at the worst possible time. Strategies sized on close-to-close volatility will systematically underestimate risk and overstate risk-adjusted returns.

Parkinson (1980) and Garman and Klass (1980) proposed range-based volatility estimators that incorporate the high and low of each bar, offering a more accurate picture of true volatility. However, these estimators are rarely used in standard backtesting practice, and even they cannot capture the gap risk between sessions or the path-dependent risk experienced during the session. For strategies with leverage or nonlinear payoff profiles, the underestimation of intraday volatility can lead to dangerously oversized positions.

The problem extends beyond position sizing to the way that strategy performance is reported and evaluated. The vast majority of backtested performance metrics, including drawdown statistics and risk-adjusted return ratios, are computed on a close-to-close or monthly-close basis. These figures describe the strategy’s behaviour as observed through the narrow lens of periodic snapshots. But the trader’s lived experience is a continuous exposure to intraday price movement, not a series of snapshots. A strategy that reports a maximum drawdown of 15% on a close-to-close basis may have experienced intraday mark-to-market drawdowns of 25% or more, drawdowns that triggered real margin calls, real psychological distress, real risk of forced liquidation, and potentially real capitulation, none of which appear in the published performance summary. The intraday volatility at the smallest observable resolution is the actual experience of the position holder, and any performance reporting that smooths over this reality by measuring only at periodic intervals is presenting an incomplete and systematically flattering picture of the strategy’s risk profile.

4.5 The Rationalisation of Coarse Data

The technical problems described above (concealed stop triggers, OHLC sequence ambiguity, settlement price artefacts, and understated volatility) grow more severe as bar size increases, and are at their worst with end-of-day data. Yet many retail systematic traders continue to develop and evaluate strategies using exclusively daily bars. This persistence owes less to ignorance than to motivated reasoning. The trader who lacks access to intraday data, or who does not wish to pay for it, or who lacks the storage and computational resources to process it, faces a choice: acknowledge a material limitation in their research infrastructure, or construct a narrative in which the limitation does not matter. Most choose the latter.

The narrative takes a characteristic form. The trader argues that their strategy operates on a sufficiently long timeframe (weekly signals, monthly rebalancing) that intraday price movements are irrelevant noise. Decisions are made at the daily close; orders are placed at or near the next open; the intraday path between one close and the next is, on this account, immaterial. The argument sounds reasonable. It is also delivered with considerable confidence, sometimes with a note of indignation at the suggestion that more granular data might be necessary.

But, the argument is almost never tested empirically by those who make it. The trader who asserts that daily data is sufficient for their medium-term strategy has, in most cases, never run that same strategy on minute-level data to verify the claim.

This is the critical omission.

When the comparison is performed, the results frequently differ not in degree but in kind. The equity curves diverge, sometimes dramatically, because the guesswork required to interpolate prices within daily bars compounds across thousands of simulated trades over a multi-year backtest. Every time the backtesting engine must resolve an ambiguous fill (did the stop or the target get hit first? was the limit order reached before or after the reversal?), it is making an assumption that may or may not correspond to what actually happened. With intraday data, many of these assumptions become unnecessary: the price path is observed rather than inferred, and fills can be evaluated against actual traded prices at actual times. The accumulated difference can alter the fundamental shape of the equity curve, turning apparent winners into losers, and causing trades that would have been taken to be missed, transforming smooth upward trajectories into sequences interrupted by drawdowns that the daily-bar version never revealed.

A concrete diagnostic is available to any trader with access to both daily and minute-level data: take any strategy that uses stop-loss or profit-target orders, run it once with signals generated from daily bars and orders evaluated against daily OHLC using the platform’s default bar-resolution convention, then run the identical strategy with signals still generated from daily bars but orders evaluated against the underlying minute-level data within each bar. Compare the trade-by-trade outcomes. The distribution of mismatches (trades classified as winners in the daily-bar version that are losers in the minute-resolution version, and vice versa) and the net direction of the aggregate performance difference provide a direct, reproducible measure of the bias introduced by coarse-bar order evaluation. In practice, this comparison almost invariably reveals a systematic optimistic bias in the daily-bar version, consistent with the stop-concealment mechanism described above.¹ Any trader who has not performed this comparison on their own strategies is operating on an untested assumption about the fidelity of their simulation.

The technology to eliminate this problem already exists and is simple in design. A properly architected backtesting engine stores (at least) minute-level data as its foundational layer and aggregates upward to whatever bar interval the strategy requests. When the trader specifies daily bars, the engine builds each daily bar from the underlying minute records, presents the aggregated bar to the strategy logic for signal generation, and then evaluates all resulting orders against the original minute-level data within that bar. The trader writes and thinks in terms of daily bars (daily closes, daily ranges, and daily indicators), but the execution simulation operates at minute resolution transparently, without any additional effort from the user. This architecture means that even a strategy designed around weekly signals and monthly rebalancing benefits from intra-bar order resolution: stops are evaluated against the actual intraday path, limit orders are filled at the price and time they would have been reached in the real market, and the OHLC sequence ambiguity described earlier is resolved by observation rather than convention. The computational overhead of this approach is modest for the typical retail use case: a decade of one-minute bars for a single liquid futures contract occupies a few hundred megabytes, and even a diversified portfolio of twenty to thirty instruments remains well within consumer-grade storage and processing capacity.² (Tick-level or Level 2 depth-of-book data, and large multi-asset universes, can become operationally heavier, but these are not required for the order-evaluation improvements described here.) The accuracy gain is substantial. That many traders continue to resist this approach owes more to motivated reasoning than to any genuine technical constraint. Havin

The question that daily-data advocates ask is “why would I need anything more granular?” But this formulation inverts the burden of proof. The correct question is the opposite: if more granular data is available, why would you not use it? The downside cost of using minute-level data (somewhat larger storage requirements and modestly longer processing times) is trivial relative to the capital at risk. The downside cost of not using it (a backtest whose results may diverge badly from achievable live performance) is potentially catastrophic. In an era when minute-bar data for most liquid futures and equities is readily available at modest cost, and when even consumer-grade hardware can store and process decades of minute-level history without difficulty, the case for relying exclusively on daily data is far weaker than most traders assume. Many sound approaches to systematic trading can be designed around the constraints of daily data, provided the researcher understands what those constraints are and designs their strategy accordingly. But the trader who uses daily data without acknowledging its limitations, who does not verify their results against more granular data when it is available, and who rationalises the omission as a principled choice rather than a convenience, is accepting an unnecessary and unquantified source of error.