- Problem statement
- Neural network training
- Statistical analysis and fuzzy logic tools
- 2026.06.13
- www.mql5.com
The overfitting risk doesn't go away, it just moves up a level. Instead of tuning entries and exits, you end up tuning the number of regimes, the lookback windows, and the transition rules — same problem, more moving parts.
What I'd avoid is optimizing the classifier and the trading logic together against net profit. That pretty much guarantees the "regime" it finds is just whatever gives the best curve, not a real one.
Tested a range-oriented system on BTCUSDT a while back, and 11 of its first 15 positions were shorts during the Oct-Nov 2020 rally. The range filter kept giving the green light in the middle of a clear trend. Made me trust a lot less any classifier that isn't validated separately from the strategy it's feeding.
One category of bug that specifically shows up when people bolt a regime classifier onto an existing EA in MQL5: the classifier gets computed in OnTick() using CopyRates() over the last N bars including the still-forming bar (index 0). In the strategy tester that's fine because bars replay deterministically once closed — but on live/some brokers the lookback window silently includes a bar whose high/low/close are still moving, so the "regime" the EA reacts to on bar N can differ from what it would've detected once bar N actually closed. That's not curve-fitting in the walk-forward sense, it's leakage that only shows up as a live/backtest performance gap, and it's easy to miss because the backtest itself still looks clean.
Simple check: log the exact bar-close timestamp your classifier last used and diff it against the current bar's open time. If they match, you're reading a moving target.
Separately — +1 to validating the classifier on data the strategy tuning never touched. I've audited EAs where the "regime" boundaries were effectively memorized from the same in-sample window used to tune entries, which is the meta-overfitting Jasiel described — just hidden inside a feature-engineering step instead of a parameter.
From my own experience, I would answer: yes, adaptability can be seen as a kind of hidden optimization — but in practice, I have found the results to be very different.
For years, I tested thousands of strategies, especially through optimization. And again and again, I ended up with overfitting. Some strategies worked well for a certain period on live, but sooner or later they started to fail. Apart from being extremely time-consuming, optimization never gave me any real guarantee that the result would remain robust.
Because of that, I gradually moved away from optimizing EAs and started looking for mechanisms that adapt by themselves.
You can argue that this is still a form of optimization, just hidden inside another mechanism. I agree. But there is an important difference in what I have observed.
When I find an adaptive mechanism that performs well on its very first backtest, without searching for the best historical parameters, it tends to remain much more robust on out-of-sample data as well.
After that, I may do some fine tuning to improve profitability, but that is not the same as searching for a single perfect combination of parameters.
With traditional optimization, you often find a sharp peak surrounded by a valley — a result that looks excellent at one specific point, but deteriorates quickly around it.
With the adaptive mechanisms I have been working with, I am looking for something different: not a sharp peak, but a solid hill. The foundation itself already works reasonably well, and the tuning is only used to improve it.
So my answer would be:
Yes, adaptability can be considered a masked form of optimization. But in my experience, it can produce a much more robust result, because the foundation is a solid hill rather than a sharp peak surrounded by valleys.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use