Backtesting8 min read
When a Backtest Bar Hits Both Stop and Target
Learn how to flag bars that touch both stop and target, document backtest fill assumptions, and audit their effect on results.
By TerraTrade Team
What the bar can—and cannot—tell you#
If a historical bar’s high reaches your target and its low reaches your stop, OHLC data shows that both prices were within the bar’s range. It does not show which level price reached first. Unless you have finer-grained data or apply a documented simulation rule, the correct observation is sequence unknown—not a factual stop-first or target-first fill. Concepts / Strategies
That distinction matters because a backtest still needs to calculate an exit. A trading engine may infer a path from the bar, apply its own order-matching rules, or inspect lower-timeframe data. Each produces a modeled answer under stated assumptions; none should be mislabeled as a sequence directly observed in the OHLC bar. Concepts / Strategies What is bar magnifier backtesting mode — TradingView Orders - Creation/Execution - Backtrader
This guide focuses on the backtest stop and target hit same bar problem: how to flag affected trades, document the engine’s fill convention, and measure how alternative outcomes change the results. It is about uncertainty inside an individual bar—not rolling fit/test windows or strategy retraining.
A simple example: two plausible outcomes#
Suppose a hypothetical long position entered at 100 has a stop at 98 and a target at 104. A later bar opens at 100, reaches a high of 105, a low of 97, and closes at 103. Both exit levels were touched, but this bar’s OHLC does not identify which came first.
For a simplified one-unit illustration that ignores fees, spread, slippage, and any gap-specific execution rule, a stop-first scenario records an exit at 98 (−2 from entry); a target-first scenario records an exit at 104 (+4). Those are sensitivity cases, not evidence that either exit happened first. Real modeled fills can differ when the opening price gaps through a level or when the engine applies specific stop and limit matching rules. Backtrader documents its own OHLC-based matching conventions, including the effect an opening gap can have on a modeled execution price. Orders - Creation/Execution - Backtrader
There is no single universal fill convention across backtest engines. Compare the documented rule actually used by your platform with transparent alternatives, rather than assuming one engine’s convention is market fact. For instance, TradingView documents emulator settings related to slippage, limit-order fills, and execution delay; record the relevant settings with the result. Broker emulator — TradingView
| Policy | What to record | What it means |
|---|---|---|
| Engine-inferred path | Engine, version, settings, and stated path or fill rule | A reproducible model result; not observed chronology. TradingView’s broker emulator, for example, infers intrabar movement from OHLC under its documented rules. Concepts / Strategies Broker emulator — TradingView |
| Stop-first sensitivity | Stop outcome and costs using the same accounting rules | A conservative comparison for this long-trade example, not a claim about the actual sequence. |
| Target-first sensitivity | Target outcome and costs using the same accounting rules | An optimistic comparison for this long-trade example, not a claim about the actual sequence. |
| Finer-grained review | Data timeframe or type, coverage, and remaining unresolved cases | Lower-timeframe bars may clarify sequence across smaller bars, but a bar that touches both levels can remain ambiguous even at that resolution. What is bar magnifier backtesting mode — TradingView |
Use one row per potentially ambiguous trade. The goal is reproducibility: another reviewer should be able to identify why the row was flagged and recalculate each scenario.
- Define a flag before reviewing outcomes. For a long position with active stop and target, flag a bar when its low is at or below the stop and its high is at or above the target. Reverse the price comparisons for a short. Apply the rule only when both exits were active during that bar.
- Save the bar facts. Record trade ID, instrument, timestamp and timeframe, direction, size, entry, stop, target, and OHLC. Record whether the open gapped through either level; do not assume a touch at the open has the same fill treatment as an intrabar touch.
- Record the data and engine. Note whether the test used OHLC only, lower-timeframe bars, or tick/quote data, along with the backtester and version. Add the documented path, order-matching, limit-fill, slippage, and execution-delay settings that apply. Concepts / Strategies What is bar magnifier backtesting mode — TradingView Broker emulator — TradingView Orders - Creation/Execution - Backtrader
- Calculate the primary result using a policy declared in advance. Label it plainly—for example, “engine-inferred using [engine/version/settings]” or “stop-first sensitivity”—and apply your stated costs consistently.
- Calculate at least one alternative outcome for each flagged trade. If comparing stop-first and target-first, keep size, fees, spread, and slippage treatment consistent. When the actual modeled fill could depend on a gap or other order rule, record that rule rather than forcing a simplified price.
- Summarize both the flagged trades and the test-level impact. Report the number and share of closed trades flagged, net P&L under each policy, changes versus the primary case, and whether win rate, average trade, or drawdown changes. State how many flags finer data resolved and how many remained unresolved.
- Preserve the audit trail. Store the policy, data coverage, assumptions, and review date with the test. Do not quietly change the rule after seeing which version makes the strategy look better.
Copy this worksheet into a spreadsheet or test log. Use a consistent accounting basis across scenario columns; otherwise, a difference attributed to ambiguity may actually come from different cost treatment.
| Audit field | Record |
|---|---|
| Trade identity | Trade ID; instrument; date; direction; position size |
| Timing and entry | Bar timeframe and timestamp; entry time and price; were both exits active before this bar? |
| Bar and exits | Open, high, low, close; stop and target levels; stop touched? target touched? open gapped through either level? |
| Flag explanation | Example: “Both levels inside range; OHLC does not show sequence.” |
| Data and engine | OHLC / lower-timeframe / tick or quote data; data coverage; backtester and version |
| Declared assumptions | Engine path and order-fill rules; relevant settings; primary policy and its documentation |
| Scenario results | Primary exit and P&L; alternative exit and P&L; incremental P&L versus primary |
| Cost treatment and review | Fees, spread, and slippage; reviewer; review date; notes |
Finer data helps, but may not settle every case#
Lower-timeframe inspection can narrow the uncertainty, but it does not automatically eliminate it. If both levels are touched inside one of the smaller bars, that bar still lacks the sequence. TradingView also notes that Bar Magnifier’s lower-timeframe requests have a coverage limit, so finer-grained simulation may not cover every bar in a long history. Record which trades were covered, which were not, and which remain ambiguous. What is bar magnifier backtesting mode — TradingView
Even tick or quote data needs an execution model to translate observations into fills: data availability, order type, queue position, and costs affect what a simulation can claim. Keep the claim proportional to the evidence—“resolved under this data and model” is safer than “the historical fill is certain.”
An ambiguity range is a sensitivity analysis, not a guaranteed bound on live performance. It isolates one uncertainty under the scenarios you chose; it does not account for every difference between historical simulation and real execution. Present the primary model result beside the alternatives, not in place of them.
- How many closed trades were flagged, and what share of closed trades was that?
- What was net P&L under the primary and alternative policies, using the same cost assumptions?
- Did win rate, average trade, or drawdown change materially across the scenarios?
- How many ambiguities were narrowed by finer data, and how many remain unresolved?
The audit does not reveal the unknowable path inside an OHLC bar. Its value is that it makes the uncertainty visible, documents the model used, and shows how much the conclusion changes when a different plausible outcome is applied.
A useful audit clarifies uncertainty
Strengths
- ✓A declared engine rule makes a backtest reproducible.
- ✓Scenario comparisons show whether a result depends heavily on unresolved bars.
- ✓Lower-timeframe data can refine some historical fill simulations.
Limitations
- —The audit cannot determine the actual tick-by-tick sequence from OHLC alone.
- —Readers may misread scenario ranges as guarantees if labels and assumptions are not prominent.
- —Results remain dependent on the backtester’s documented settings (path, order-matching, slippage).
Strengths and limitations
Strengths
- ✓The worksheet standardizes flags and makes reviews reproducible.
- ✓Separating bar facts, engine result, and sensitivity cases reduces hidden assumptions.
- ✓Recording engine/version/settings enables others to replicate fills.
Limitations
- —OHLC alone cannot establish which level was reached first.
- —Finer bars may still leave ambiguity and may not cover the full test history.
- —A sensitivity case is not proof of a real execution.
Frequently asked questions#
What should I record when a backtest stop and target hit the same bar?
If the bar’s high and low include both active exit levels, OHLC shows both were touched but not the order. Record the sequence as unknown unless finer data or a declared simulation rule supplies a modeled answer. Concepts / Strategies
Does Bar Magnifier prove which order happened first?
It can refine historical fill simulation using lower-timeframe bars. A smaller bar can still touch both levels, and coverage may not extend across the entire history. Record the data resolution and unresolved cases. What is bar magnifier backtesting mode — TradingView
Is stop-first always the correct conservative result?
No. Stop-first and target-first are sensitivity cases unless the sequence is supported by finer data. An engine-inferred outcome is also a modeled result under that engine’s documented assumptions, not proof of the original path. Concepts / Strategies Broker emulator — TradingView
Which backtest settings belong in the audit?
Record the engine, version, data resolution, path and order-matching rules, and relevant fill settings such as slippage or limit-fill assumptions. Applying the same documented policy makes the test easier to reproduce. Broker emulator — TradingView Orders - Creation/Execution - Backtrader
Aggregate impact summary#
Aggregate results should show how unresolved intrabar ambiguity changes key metrics under clearly labeled policies. Present the primary engine-model result beside transparent alternatives; do not substitute one for the other.
Sources#
- Concepts / Strategies — tradingview.com
- What is bar magnifier backtesting mode — TradingView — tradingview.com
- Broker emulator — TradingView — tradingview.com
- Orders - Creation/Execution - Backtrader — backtrader.com
- https://ar.tradingview.com/pine-script-docs/v5/concepts/strategies/ — ar.tradingview.com
- https://tradevidence.com/backtest-order-fill-assumptions/ — tradevidence.com
- https://backtrader.com/docu/strategy/ — backtrader.com
- https://help.tradestation.com/10_00/eng/tradestationhelp/chart_analysis/intrabar_order_generation.htm — help.tradestation.com
- https://github.com/ml4t/backtest/blob/main/docs/user-guide/execution-semantics.md — github.com
- https://kjtradingsystems.com/EL_Ref_Guide.pdf — kjtradingsystems.com
- https://www.mhptrading.com/docs/RealTest%20User%20Guide.pdf — mhptrading.com
- https://www.multicharts.com/trading-software/index.php?title=Intra-bar_Price_Movement_Assumptions — multicharts.com
- https://backtest.ai/docs/backtests/backtest-assumptions-and-realism — backtest.ai
- https://nruno.com/knowledge/tradingview-bar-magnifier-strategy-fills/ — nruno.com
- https://docs.ninjatrader.com/ninjascript/backtesting_ninjascript_strategies_with_an_intrabar_granularity — docs.ninjatrader.com
- https://cdn.tradestation.com/uploads/Learning-EasyLanguage-Strategies.pdf — cdn.tradestation.com
KEEP READING
Backtesting7 min read
A Backtest Experiment Log for Every Strategy Trial
Use a backtest experiment log template to record hypotheses, parameter changes, metrics, decisions, and unsuccessful trials in a traceable search history.
Read post
Backtesting7 min read
How to Build a Futures Price Series for Backtesting
Build a reproducible futures continuous series for backtesting: define the roll rule, adjustment method, switch ledger, and contract-level simulated fills.
Read post
Strategies9 min read
Make Support and Resistance Rules Measurable
Build repeatable support and resistance strategy rules with objective pivots, explicit zone tolerance, setup definitions, and a reproducible test plan.
Read post