Your scalping backtest is mostly an assumption
Scalping is where TradingView's backtest is least able to tell you what you want to know, and the reason is specific rather than general.
The emulator has to guess, and on a scalp it guesses constantly
When a bar's range contains both your stop and your target, the backtest has to decide which was reached first. It does so by inferring the path price took through the bar from where the open sits relative to the high and the low [2]:
If the opening price of a bar is closer to the high than it is to the low, the emulator assumes that the market price moved in this order: open → high → low → close. If the opening price of a bar is closer to the low than it is to the high, the emulator assumes that the market price moved in this order: open → low → high → close. [2]
Now notice what scalping does. A tight stop and a tight target on a short timeframe means both levels usually sit inside one bar's range. So the case the emulator resolves by assumption is not an edge case in a scalping strategy — it is the normal case.
You can measure your own exposure to this. Open the List of Trades, and for each exit check whether that bar's range contained both your levels. On a scalping strategy the fraction is often most of them. That fraction is how much of your equity curve is the rule above rather than the market.
This is also exactly where MetaTrader differs: its tester can replay real broker-accumulated ticks with no simulation [3], so it does not have to infer the path. For a scalping idea specifically, that is not a minor difference — the engine comparison sets out why the two cannot agree.
Two platform limits that bind here first
The order cap. A script can place a maximum of 9,000 orders in a backtest, rising to 1,000,000 with Deep Backtesting [1]. A scalping strategy on a short timeframe over a long range reaches 9,000 and simply stops adding trades — the curve flattens and the statistics stay plausible. Always check the trade count against the cap before concluding the strategy stopped working.
The execution-time limit. 20 seconds for basic accounts, 40 for others [1]. Short timeframes mean more bars per unit of history, so this binds sooner here than on a daily strategy.
The arithmetic that decides scalping
Costs are not a detail at this horizon, they are the strategy. If your target is a small number of ticks and your commission plus slippage is a meaningful fraction of it, you need a large directional edge just to break even.
So run the doubling test before anything else: double commission and slippage and re-run. On a scalping strategy this frequently removes the entire edge, and finding that out in an afternoon is the best possible outcome — the cost sensitivity test.
If you still want to build it
| Field | Value | Note |
|---|---|---|
| Timeframe | 1–15 minutes | more bars, so more exposure to every limit above |
| Entry | one condition, not three | fewer parameters at the horizon with the least data per trade |
| Stop and target | separated enough not to share a bar | reduces how much the emulator decides |
| Costs | commission and slippage set honestly | the single most important field |
| Session filter | yes | spreads widen outside liquid hours |
The third row is the actionable one. Widening the gap between stop and target is not about better risk-reward — it is about leaving the emulator less to guess about, which makes your backtest mean more.
The break-even arithmetic
The section above says costs decide a scalping strategy. Here is the arithmetic, worked on EURUSD, the pair most scalping ideas start on.
Assume a symmetrical strategy — target and stop the same distance — and a round-trip cost of spread plus slippage plus commission. The win rate you need just to break even is:
| Target | Round-trip cost | Break-even win rate |
|---|---|---|
| 20 pips | 1 pip | ~52.5% |
| 10 pips | 1 pip | ~55% |
| 5 pips | 1 pip | ~60% |
| 3 pips | 1 pip | ~66.7% |
| 5 pips | 2 pips | ~70% |
Read the last two rows together. A 5-pip target with a 2-pip round trip needs you to be right seven times out of ten just to break even. Very few directional signals are that good, and the ones that claim to be are usually measuring a backtest with costs left unset. That is the real constraint on scalping, and it is why the doubling test above matters so much here.
Why the cost side is worse than the table suggests
The table assumes a fixed round-trip cost. In practice it varies in exactly the wrong way:
- spreads widen outside liquid hours, and widen sharply around news
- slippage is largest when the move is fastest — which is when your signal most often fires
slippagein Pine is counted in ticks, so a number you carried over from another instrument means something different here
The third is worth checking in your own export. A slippage = 3 calibrated on
an index CFD is not 3 of the same thing on EURUSD, because a tick is not the
same size — the general point is in
the cost parameters.
What the arithmetic implies for a EURUSD build
It pushes you toward a larger target, which is a different strategy rather than a tuned one:
| Field | Value | Why |
|---|---|---|
| Timeframe | 5–15 minutes | fewer, larger moves per trade |
| Target | at least 10× the round-trip cost | keeps the break-even win rate near 55% |
| Stop | ATR-based, not fixed pips | scales when volatility changes |
| Session filter | London and New York overlap only | the hours where the spread is tightest |
| Costs | set from your own broker's typical spread | not a default |
The session filter is doing real work here rather than being a refinement: it removes the hours in which the cost side of the table is worst. The timezone trap in building one is covered in the London session breakout.
The measurement to run before you build anything
Take your broker's typical EURUSD spread at the hours you intend to trade, add your expected slippage, and put it against the target you have in mind. If the break-even win rate that falls out is above 60%, the idea needs a bigger target or a cheaper execution route, and no amount of indicator tuning changes that.
This is the same reasoning that makes most published scalping results unverifiable: the surveyed academic evidence on technical trading rules weakens sharply once transaction costs are included [4], and scalping is the horizon where costs are largest relative to the move.