When a single candle touches both take profit and stop loss, there is no "objectively correct" answer in backtesting—only which assumption you choose to adopt. A candle only records four prices: open, high, low, and close. It does not record whether the high or the low happened first. When both your take profit and stop loss fall within the price range of the same candle, the true price path information is already lost.

A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!!
My view is straightforward: if you are using a simplified backtesting framework, prioritize treating the stop loss as triggered first; if you have access to finer-grained data, use lower-timeframe data to reconstruct the path instead of relying on any assumption. The former is the conservative approach. The latter is the solution that gets closer to reality. Both are more reliable than "assume take profit triggers first."
Different backtesting frameworks have different default rules
This is not a unified standard. Different software handles it in clearly different ways. The tool you are using directly determines how your backtest results will be distorted.
TradingView's broker emulator uses a heuristic based on the position of the opening price: if the open is closer to the high, it assumes the path is "open → high → low → close," which means take profit triggers first for long positions. If the open is closer to the low, it assumes the path is "open → low → high → close," meaning stop loss triggers first. This rule is deterministic and verifiable, but it is still essentially a guess, not a measurement.
MultiCharts uses the same opening price heuristic. Wealth-Lab, when discussing "smart same-bar exits," reaches a more conservative conclusion: when the order cannot be determined, backtesting should lean toward the more pessimistic outcome—meaning stop loss first. Code comments in some independent backtesting engines also state "if a bar could hit both, the STOP is assumed first (conservative)."
freqtrade and banbot handle this by triggering the stop loss first. The situation with backtrader and vnpy is more complicated: take profit and stop loss are treated as child orders, and whichever is sent first triggers first—not necessarily stop loss or take profit. This means the same set of parameters and the same market data can produce completely different backtest results depending on which framework you use.
How much does this assumption affect backtest results?
One study ran a large-scale stress test: on Binance USDT perpetual contracts, using five markets—BTC, ETH, BNB, XRP, and SOL—with 4,882,500 configurations per market, running each twice: once with "take profit first" and once with "stop loss first."
Among the 37,168,124 configurations where total return changed, the median change was a 13.50 percentage point drop in total return, a 1.94 percentage point drop in win rate, and a 5.80 percentage point deepening of maximum drawdown. At the 10th percentile, the total return change reached -113.86 percentage points, reflecting the long-tail impact under compounding effects.
This shows that if your strategy frequently has candles where both take profit and stop loss are hit, a significant portion of your backtest results is determined by the framework's default assumption rather than by your strategy logic.
How to check how serious this problem is in your backtest
There is a simple self-check method. Using banbot as an example: when it detects that a single candle triggers both take profit and stop loss, it outputs a warning and counts the number of such orders. One record in Chinese showed that in a 10-day backtest on ETH with 259 orders, 183 orders had both take profit and stop loss satisfied within the same candle. That means over 70% of exits were determined by assumptions, making the backtest results essentially unreliable.
If your framework does not provide this warning, you can check manually: in your trade records, find exits where the candle's high and low both covered your take profit and stop loss prices. If these trades make up a high percentage, it means your stop loss and take profit settings are too narrow relative to candle volatility, or the timeframe you are using is too coarse.
A more reliable solution: use lower-timeframe data to reconstruct the path
If you need more accurate results rather than relying on assumptions, the right direction is to use lower-timeframe data to "zoom into" the candle. For example, if your strategy runs on 1-hour candles, you can import 1-minute candle data and have the backtesting engine check each 1-minute candle in chronological order to see whether take profit or stop loss was hit first.
PyneCore's Bar Magnifier feature does exactly this: the script still runs on 1-hour candles, but the order matching engine checks the OHLC of each lower-timeframe candle within that hour and determines which price level was touched first in sequence. TradingView also has a similar Bar Magnifier setting.
The cost is data and computation. You need to obtain additional lower-timeframe historical data, and backtesting speed will slow down. Moreover, lower-timeframe data is still not tick-by-tick data. If take profit and stop loss fall within the same 1-minute candle, the problem still exists—just with a much smaller probability.
For most users, a practical compromise is this: if your strategy runs on 1-hour or higher timeframes, make sure your take profit and stop loss distances are at least 2 to 3 times the average candle range. This significantly reduces the probability of both being hit within the same candle. This does not eliminate the problem, but it keeps it at an acceptable frequency. If you cannot do this—for example, with high-frequency or narrow-range oscillation strategies—then you must face the impact of this assumption on your backtest results and avoid treating backtest returns as evidence of real strategy performance.
Completion criteria
The standard for judging whether you have handled this issue well is not "you picked the right rule." It is whether you can answer: what percentage of your backtest trades had both take profit and stop loss triggered within the same candle? If this percentage exceeds 10% to 20%, your backtest results need to be viewed with a discount. If the percentage is low, the impact of the framework's default rule is limited, and continuing with your current settings is fine. If the percentage is high, either switch to lower-timeframe data or accept the fact that "this backtest result is only valid under conservative assumptions" and do not use it to estimate expected returns.

A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!!
References
- Wealth-Lab·Smart-Same-Bar-Exits-for-Backtests,2026-10-26
- MultiCharts·Intra-bar Price Movement Assumptions in Backtesting,2026-10-26
- Rulyfi·Does Your Backtest Survive the Adverse Same-Bar Fill? A 48.8 Million-Pair Stress Test,2026-10-26
- WeChat Public Platform·Have You Encountered the Stop Loss and Take Profit Pitfall in Backtesting?,2026-10-26
- AlfaTactix·Pine Strategy Risk: SL, TP, % Equity, Daily Trade Cap,2026-10-26
- PyneCore·Bar Magnifier,2026-10-26
- SiftingIO·Stop-loss and take-profit in the same candle: OHLC backtests,2026-10-26


