One-Tick Reality Check: Add Delay, Slippage and Limit-Fill Rules to a 1-Min Backtest

Define the Simulation Evidence Boundary

What can a one-minute backtest actually establish?

A one-minute backtest can compare strategy behaviour on historical chart data under recorded emulator assumptions. It can show sensitivity when one documented input changes. It cannot establish a live broker fill, measured latency, executable quantity, queue priority, strategy edge, profitability or a universally correct configuration.

TradingView distinguishes backtesting on historical data from forward testing while chart data updates. Both are platform test modes, not authenticated broker execution records. The National Futures Association separately cautions that hypothetical results have inherent limitations, but that United States rulebook source is cited narrowly and is not presented as UK legal advice.

Source: TradingView, “What are strategies, backtesting and forward testing?” — https://www.tradingview.com/support/solutions/43000562362-what-are-strategies-backtesting-and-forward-testing/

Source: National Futures Association, “Compliance Rule 2-29” — https://www.nfa.futures.org/rulebooksql/rules.aspx?RuleID=RULE%202-29&Section=4

Call every result conditional on its code, data, period and settings. With those evidence labels fixed, freeze every baseline field before changing one.

Freeze the Untouched Baseline

Which settings belong on the baseline card?

Record platform and code versions, symbol, feed, session, timeframe, test range, chart type, historical detail, calculation timing, tick size, delay, slippage, commission, limit-fill mode and export identifier. Save the original before editing. Mark any unsupported value DATA_NOT_AVAILABLE; never recreate it from memory.

TradingView documents delay, slippage, commission and limit-order execution as separate broker-emulator controls. Its strategy manual also describes historical-fill assumptions and report properties. These fields make a comparison reproducible inside the platform; they do not prove that defaults are neutral or that recorded settings match a broker, data feed or venue.

Source: TradingView, “Broker emulator” — https://www.tradingview.com/support/solutions/43000786181-broker-emulator/

Create four branches—DELAY-01, SLIPPAGE-01, COMMISSION-01 and LIMIT-01—from the same protected baseline. Never overwrite BASELINE-00.

The unchanged reference prevents hindsight from becoming an invisible setting. Once BASELINE-00 is fixed, isolate timing without changing costs or fill strictness.

Add Order Delay Deliberately

How does one-tick delay alter simulated timing?

DELAY-01 changes only the documented order-delay setting and compares every order with BASELINE-00. One tick is a simulator timing option, not measured network, broker, queue or venue latency. Retain moved, missing and unchanged fills so the comparison does not favour a convenient outcome.

TradingView’s Pine Script manual explains next-tick order timing and the alternative of processing an order on a bar’s closing tick. The mechanism concerns simulated eligibility, not infrastructure speed. A fictional example can clarify the sequence, but it supplies no evidence about a real trader, account or order path.

Imagine a clearly fictional order created at a one-minute bar close. The delay variant moves its eligible simulated fill to a later event, while every other field remains fixed. You can conclude only that the result is sensitive to the platform timing rule—not that the later fill is more realistic.

Source: TradingView, “Strategies”, Pine Script manual — https://www.tradingview.com/pine-script-docs/concepts/strategies/

Timing asks when an eligible simulated order may execute. Limit verification asks what price movement makes it eligible. After timing is isolated, reset to BASELINE-00 and test price friction and fees separately.

Stress-Test Slippage and Commission

What changes when costs enter the model?

Run two separate comparisons. SLIPPAGE-01 changes only fixed-tick slippage; COMMISSION-01 changes only the recorded commission mode and amount. Each value is a model input, not measured live cost. Neither run automatically captures spread, liquidity, market impact, rejection, partial fills or every account charge.

TradingView documents slippage in fixed ticks and commission as percentage, fixed-per-order or per-contract modes. Its manual says real-world slippage is dynamic and unpredictable, so a fixed input cannot reproduce it precisely. It also warns that excessive constant slippage can place simulated fills outside a candle’s range and make results unrealistically worse.

Retain adverse, favourable and unchanged order-level differences. A harsher-looking report is not automatically more accurate. Reset to the protected baseline before each test.

Modelled timing, price and fees still do not answer whether a touched limit was executable. That requires a separate eligibility comparison.

Separate Touch From Limit Fill

When does a touched limit become a fill?

Requested-price mode and one-tick-beyond mode apply different simulator eligibility rules. Compare both from BASELINE-00 and record orders that disappear, move or remain unchanged. Neither rule proves live queue priority, available size, liquidity, rejection, price improvement or partial execution for an actual order.

TradingView documents one mode in which reaching the requested price is sufficient and another requiring price to move one tick beyond the level before the emulator fills at the requested price. Lower-timeframe historical detail can add price points when available, but it still cannot reconstruct an order book, queue or executable quantity.

Interactive fictional scenario: A one-minute candle touches a limit. Requested-price mode records a fill, while one-tick-beyond mode does not. Which evidence would you seek before calling it filled: the chart range, both emulator outputs, or an authenticated broker order-and-fill record? The scenario describes no real trade or student.

Do not rename one-tick-beyond as a universal worst case. The final comparison can now observe chart-data behaviour while preserving the broker-evidence gap.

Compare Forward Evidence Carefully

What can forward testing verify about execution?

Forward testing can reveal how a TradingView strategy and broker emulator behave as chart data updates, including matches, mismatches and non-fills. It cannot by itself prove broker routing, queue position, live latency, liquidity, universal transferability, strategy edge, profitability or future performance. Authenticated execution needs separate evidence.

TradingView says strategy parameters can change both historical and forward-test results. The NFA rulebook provides a narrow official caution about hypothetical performance, but it supplies no TradingView configuration and no UK applicability conclusion. Agreement remains sample-bound; disagreement becomes an evidence question rather than a story about why it occurred.

Preserve matches and mismatches equally. No script, dataset, spread series, commission schedule, order size or broker fill record was supplied, so no performance result or preferred value is available.

Every conclusion should read: under this recorded code, dataset, period and set of fill assumptions, this order-level difference appeared. That closes the audit without upgrading simulation to market fact.

FAQs