Why tick data changes what an MT5 backtest can tell you

Real ticks and generated ticks represent different evidence

MetaTrader 5 can test using real ticks supplied through a broker, or using ticks generated from minute-bar data. MetaQuotes describes real-tick testing as the closest available mode to real conditions because the tester uses ticks accumulated by exchanges or liquidity providers. It also notes that when a minute bar exists without corresponding tick data, the tester can generate ticks for that interval.

That means a test labelled “every tick” still needs context. Was it every tick based on real ticks, or a generated sequence derived from M1 bars? Was the real-tick history complete across the full period? Which trade server and symbol supplied it?

Why the intrabar path matters

An OHLC bar records four prices, not their complete path. If both a stop and a target fall inside the same bar, their order may depend on ticks that the bar does not contain. The same is true for trailing logic, spread filters, rapid state changes, limit or stop orders, and strategies that read every tick.

MetaQuotes explicitly warns that simplified “1 minute OHLC” and “Open prices only” modes can create misleadingly attractive behaviour when a strategy exploits the deterministic structure of the generated points. Those modes can still be useful as fast diagnostic tools when the strategy logic genuinely permits them; they should not be treated as interchangeable with a tick-sensitive test.

Spread belongs to the model, not the footnote

Orders execute at Bid or Ask, even when a chart is constructed from another price representation. In real-tick mode, the spread may change within a minute; generated modes can represent it differently. A strategy with short holding periods, tight protective levels, or spread-based filters can therefore be highly sensitive to the chosen history.

Commission, swaps, slippage or execution delay, stop levels, contract specifications, and volume constraints add further layers. Tick granularity does not compensate for missing or unrealistic transaction assumptions.

Real tick data still needs an audit

“Real” describes how the prices were recorded; it does not make the dataset complete or universal. Different brokers can expose different feeds, symbol names, sessions, spreads, specifications, and historical depth. Corrections and gaps can occur. A platform may fall back to generated ticks for affected minutes.

A useful audit checks at least coverage, timestamp interpretation, discontinuities, duplicated records, Bid/Ask availability, spread behaviour, symbol settings, and any transformation performed before import.

A practical MT5 backtesting workflow

1. Match the mode to the strategy. Use quick modes for implementation diagnostics only when their simplifications cannot change the logic being tested.
2. Inspect the data interval. Confirm how much real-tick history exists and whether any section relies on generated ticks.
3. Record symbol settings. Preserve the specifications and test configuration that affect sizing, costs, sessions, and execution.
4. Verify event behaviour. Use targeted periods, logs, and visual tests to confirm that orders and state transitions follow the intended rules.
5. Vary reasonable assumptions. Examine how costs, spreads, parameters, and periods change the conclusion.
6. Keep the claim proportional. Report what happened in this simulation, not what must happen in live trading.

What a careful result can support

A well-documented tick-data backtest can provide stronger evidence about how an EA behaved under the tested historical path and assumptions. It can help identify implementation defects, cost sensitivity, unstable parameters, concentrated exposure, and scenarios worth deeper study.

It cannot prove future profitability, reproduce every live fill, or eliminate regime change and operational risk. The right conclusion is conditional: given this data, code, configuration, and model, this is what the system did.