The first thing to check on any MT5 backtest report is not the profit factor. It is the modelling mode and the date range, both printed at the top of the report. A grid system tested in "Open prices only" across a quiet twelve months will produce a curve that a marketing page can use and that live trading will destroy in a week. The tester is an honest tool. It answers exactly the question you configured, and most people configure the wrong one.
Modelling modes decide whether the number means anything
MT5 offers five ways to feed prices to an expert advisor during a test, and they differ by how much of the intrabar path is real.
| Mode | What it does | Use it for |
|---|---|---|
| Every tick based on real ticks | Replays the tick history the broker actually stored, including the bid and ask spread that existed at each tick | Any system where fill price, stop placement or spread matters |
| Every tick | Generates a plausible tick sequence from M1 bars using a fixed interpolation | Rough checks when real ticks are unavailable for the period |
| 1 minute OHLC | Feeds four prices per minute | Fast sanity checks on bar-based logic |
| Open prices only | One price per bar of the working timeframe | Debugging logic and catching compile-time silliness |
| Math calculations | No market data at all, runs OnTester maths | Optimising a formula that does not place trades |
Real tick quality is a property of the broker, not of MT5. Some servers hold years of tick history, some hold a few months, some backfill gaps with generated data. Download the history first, check where it actually starts, and treat any period before that as untested rather than tested.
Spread, commission and swap are settings, not facts
The tester takes its symbol specification from the server you are connected to. Contract size, tick value, minimum stop distance, freeze level, swap rates and commission come from that specification, and they are not the same across brokers. A scalping EA that clears a 0.6 pip average spread on one server loses money on another where the same symbol averages 1.4 pips, and nothing in the code changed.
Two settings deserve attention every single run. Set the spread to "Current" only if you understand that it pins one snapshot value across the whole test, which flatters any system that trades around news or the rollover window. Real tick mode is better here because it carries the historical spread. And check that commission is actually configured on the test symbol. A great many published EA results were produced with commission at zero on an account type that charges per lot round turn.
A backtest is a description of the past under assumptions you chose. It is not a forecast, it carries no guarantee of any future outcome, and trading an automated system carries the same risk of loss as trading by hand.
Optimisation, and the shape of the result
MT5 runs optimisation either as a slow complete pass over every combination or as a faster genetic search, and it can distribute the work across local cores, other machines on the network or the MQL5 cloud agents. That speed is the danger. It is trivially easy to run 40,000 passes over four inputs and find a combination that turned a losing idea into a beautiful curve.
The defence is to look at the optimisation surface instead of the top row of the table. Sort by your criterion, then plot two inputs against the result in the 2D graph. What you want is a broad region where neighbouring values all behave similarly. A single bright cell surrounded by losses is a fitted artefact, and it will not repeat. Reducing the input count helps more than any statistical trick: four parameters over five years of data is defensible, eleven parameters is not.
The forward period control is the cheapest protection MT5 gives you. Set it to a quarter or a third of the range and the optimiser only sees the front portion, then reports how each candidate behaved on the held-back tail. Candidates that rank high in both halves are the short list. This is still in-sample discipline rather than proof, which is why it belongs alongside forward testing on a live feed rather than instead of it.
Reading the report without fooling yourself
Profit factor and net profit are the two numbers everybody quotes and the two least useful in isolation. Start with trade count. Under about 100 trades the statistics carry almost no weight, whatever they say. Then look at maximal equity drawdown as a percentage, not balance drawdown, because balance drawdown ignores open floating losses and a martingale system can show a tiny balance drawdown while sitting on an account-ending float. Then the recovery factor, which relates net profit to that worst drawdown, and the expected payoff per trade compared with the round turn cost.
Finally, open the trade list and read the largest ten winners. If removing them turns the system negative, you have a strategy that depends on rare events, which is a legitimate design but requires a completely different position sizing conversation. MT5 also lets you define a custom criterion in OnTester, so if your real objective is something like return divided by worst month, you can optimise for it directly instead of for net profit.
What the tester cannot model
Requotes and rejections do not exist in the tester. Neither does variable latency, partial fills on larger sizes, dealer intervention, or a stop hunt in illiquid hours. Spread widening around the daily rollover is present only in real tick mode. Swap rates are applied as they stand today, not as they stood in 2021. Server time offsets change candle boundaries between brokers, and a strategy that reads the daily close will trade differently on a server whose day rolls at a different hour, which is worth understanding before you compare two reports side by side: see how broker offsets shift candle closes.
None of this makes the tester useless. It makes it a filter. It kills bad ideas cheaply, and a system that fails a clean real tick backtest never needs to be tested any further. Passing it earns the right to the next stage, not a conclusion. If you want to see how the MT5 tester compares with Python frameworks and third-party engines, we covered the tool options in more depth separately.
"If a backtest looks incredible, my first assumption is that I misconfigured something. That assumption has been right more often than not."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- Only "Every tick based on real ticks" replays genuine intrabar movement and the historical spread.
- Results are bound to one broker's symbol specification, so commission, swap and stop levels must be set correctly.
- Judge optimisation by the breadth of the surface and the forward period, never by the top row of the table.
- Slippage, requotes, latency and partial fills are absent from the tester, so a pass is a filter and not a verdict.
Frequently Asked Questions
Which MT5 modelling mode should I use to backtest an EA?
Every tick based on real ticks is the only mode worth trusting for anything sensitive to entry price, because it replays the broker's stored tick history instead of generating ticks from bars. Open prices only is fine for a bar-close system while you are still debugging logic, since it runs far faster. The 1 minute OHLC and generated every tick modes sit in between and quietly invent intrabar movement that never happened.
Why does the same EA give different results on two brokers?
Because the test is run against that broker's own symbol specification and tick history. Contract size, tick value, stop level, swap rates, commission, quote precision, server time offset and the number of bars in a trading day all differ between servers. An EA whose logic depends on candle boundaries can produce a different trade list simply because one server closes the daily bar at a different hour.
How do I stop optimisation from curve fitting?
Reduce the number of parameters, use coarse steps rather than fine ones, and turn on the forward period so part of the range is held back from the optimiser. Then look at the surface rather than the peak: a setting that works across a wide plateau of neighbouring values is more likely to survive live conditions than a single spike that collapses when one input moves by a step.