MT5 Strategy Tester: Every Tick vs Every Tick Based on Real Ticks vs OHLC
The three tick modeling modes in MT5 don't just differ in speed — they differ in whether your backtest can see the exact price path your stop and target are racing against.
The setting most people skip past
When you open the Strategy Tester in MT5, the modeling mode dropdown sits right above the date range, and most people leave it on whatever the default happens to be and move on to the parameters they actually care about — lot size, stop distance, session hours. That’s a mistake, because the modeling mode determines what “price” even means during the test. It decides how many synthetic data points exist between the open and close of each bar, and by extension, whether your stop-loss and take-profit levels are being evaluated against something resembling the real intrabar path or against a crude reconstruction of one.
OHLC: four points standing in for the whole bar
The OHLC mode generates a backtest using only the open, high, low, and close of each historical bar, then simulates a plausible path between those four points using a fixed algorithm — typically something like open to high to low to close, or open to low to high to close, depending on which produces the larger range. This is fast, and for a strategy that only cares about closing prices — something that enters and exits strictly on bar close, with no intrabar stop or target — it can be adequate.
The problem shows up the moment your strategy has an sl and tp sitting inside the bar. OHLC mode has no way of knowing whether price actually touched your stop before your target, or your target before your stop, within a bar where both levels fall inside the high-low range. It picks one, based on the synthetic path algorithm, not based on what actually happened. On a bar with a wide range — the kind you get disproportionately often during the London open or the New York overlap — this isn’t a rare edge case. It’s a coin flip on every single trade where both levels are inside that bar’s range, and the backtest will confidently report a result either way.
Every Tick: synthetic granularity, still not the truth
“Every Tick” mode generates intrabar ticks synthetically, using a more granular internal model than OHLC’s four-point reconstruction, typically working down to a smaller timeframe (M1) and simulating a price path within it. This gets you a smoother equity curve and resolves some of the coin-flip ambiguity from OHLC mode, because there are now many more synthetic points to check your stop and target against. But the ticks are still generated, not observed. They’re MetaQuotes’ model of what price probably did, built from lower-timeframe OHLC data, not from the actual quote stream your broker’s server produced. A pattern that depends on the specific shape of a spike — a stop run that reverses within seconds, for instance — can pass a backtest in Every Tick mode by exploiting a synthetic price path that never occurred, and then fail live because the real tick sequence looked nothing like the reconstruction.
Every Tick Based on Real Ticks: what actually traded
This is the mode that uses genuine historical tick data, when it’s available for your symbol and broker, rather than a synthetic reconstruction. Every price point in the test is a tick that was actually quoted, in the actual sequence it occurred, which means your stop-loss and take-profit are being checked against reality rather than an algorithm’s best guess at reality. This is the only mode where the answer to “did price touch the stop before the target inside this bar” is a fact rather than a modeled inference.
The catch is data availability and cost. Real tick history has to have been recorded and stored somewhere, and for many symbol/broker combinations — especially anything outside major forex pairs, or history going back more than a couple of years — it simply doesn’t exist or has gaps. When it’s not available, MT5 falls back to a synthetic method and will tell you so in the test results as a “modeling quality” percentage. That number is worth reading. A modeling quality below roughly 90% on a strategy that lives or dies by intrabar stop placement is a sign your backtest results are, to some real degree, still a reconstruction rather than a record.
| Mode | Data source | Intrabar accuracy | Typical use case |
|---|---|---|---|
| OHLC | 4 points per bar | Lowest — picks one synthetic path | Close-only entries/exits, quick parameter screening |
| Every Tick | Synthetic, generated from M1 data | Medium — smoother but modeled | Faster iteration when real ticks are unavailable |
| Every Tick (Real Ticks) | Actual historical quotes | Highest — matches recorded price path | Final validation before going live |
Why this connects directly to your cost assumptions
Spread, slippage, and commission are usually discussed as a separate line item from tick modeling, but they’re mechanically linked. Real tick data carries the actual bid/ask spread at each moment, which varies through the session — tight during the London/New York overlap window, wider during the Asian session’s lower liquidity hours, and prone to spiking around news releases regardless of session. A synthetic OHLC or Every Tick backtest typically applies a flat, average spread across the whole test, which understates cost exactly when it matters most: during the volatile, wide-range bars where your stop and target are both close to being hit, and where a wider real spread would have changed which one triggered first. This is a large part of why backtests run on cheaper modeling modes tend to overstate performance in ways that don’t show up as an obvious red flag — it’s not that the win rate is wildly inflated, it’s that the cost drag is quietly understated on exactly the trades where it mattered.
What this means for validation order
The practical workflow most people land on, once they’ve been burned by this once, is to use OHLC or Every Tick for the first pass of parameter search — sweeping wide ranges of sl, tp, and session hours is faster this way and the noise floor doesn’t matter much when you’re just narrowing down a search space. But the walk-forward segments and the final out-of-sample test that actually inform a go/no-go decision should run on Every Tick Based on Real Ticks, modeling quality permitting. A strategy that shows a 58% win rate on real ticks and a 71% win rate on synthetic Every Tick isn’t two different strategies — it’s one strategy and two different levels of honesty about how it was tested, and the gap between those two numbers is telling you exactly how much of your edge was manufactured by the tester rather than earned in the market.
One more wrinkle: modeling quality isn’t uniform across sessions
Modeling quality percentages are usually reported as a single number for the whole test range, but the real ticks a broker has actually recorded aren’t evenly distributed across the day. Liquidity providers stream far more quote updates during London hours (08:00–16:00 UTC) and the New York overlap (13:00–16:00 UTC) than they do during the thinner stretches of the Asian session (00:00–08:00 UTC), simply because more participants are actively quoting. That means the real-tick reconstruction is usually most faithful precisely during the hours a session-based strategy is most likely to be trading, and comparatively thinner during off-session hours. If your JSON config restricts start_hour and end_hour to the overlap window specifically, you’re incidentally testing during the part of the day where real tick data is most complete — which is one more reason session-scoped strategies tend to produce backtests you can actually trust, provided you’ve confirmed the modeling quality figure rather than assumed it.