Discussing the article: "Native Isolation Forest for Execution-Quality Anomaly Detection in MQL5"
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Check out the new article: Native Isolation Forest for Execution-Quality Anomaly Detection in MQL5.
A step-by-step guide to a native Isolation Forest in MQL5 focused on execution metrics rather than price. It details five features, tree construction and path‑length scoring, rolling‑window training, CSV logging, and FILE_COMMON persistence, all integrated into OnTradeTransaction(). The resulting circuit breaker flags unusual fills in real time and applies controlled responses to stabilize live trading under changing execution conditions.
If you've ever compared a strategy tester report to a live account statement and wondered where the difference came from, you already know the problem. Backtests assume a fixed, well-behaved execution model; live trading gives you a distribution where the tail matters more than the average. A single 40-point slippage event during a news spike, or a run of 2-second fill delays during a liquidity gap, can do more damage than a hundred ordinary trades combined, and it usually happens quietly enough that nobody notices until the equity curve has already bent.
The instinct is to set a hard slippage cap and reject fills beyond it. That works for single-feature problems, but execution quality is genuinely multivariate - a fill can be individually "fine" on slippage, latency, and spread, and still be jointly unusual in a way that a single threshold per feature will never catch. That's the case for an unsupervised, multivariate detector rather than a stack of independent guardrails.
It's worth naming the alternatives rather than skipping straight to the answer. A per-feature z-score misses the jointly unusual case described above. DBSCAN or Local Outlier Factor need a distance metric and a neighborhood-size parameter that's awkward to keep meaningful as the rolling window ages. A One-Class SVM needs a kernel and margin parameter tuned per dataset, and none of the three ships with a native, dependency-free MQL5 implementation the way a random-split tree ensemble does. Isolation Forest fits because it's parameter-light, needs no distance metric or kernel, degrades gracefully on small samples, and is simple to implement natively with no numerical library behind it.
Isolation Forest is a good fit here for a reason easy to lose track of: it doesn't need labeled anomalies to train on, and execution anomalies are exactly the kind of thing you rarely have clean labels for in advance. Scoring takes O(num_trees x height_limit) comparisons per point - roughly 100 x 8, under a thousand comparisons in the default configuration. This is why it can run inside OnTradeTransaction(). This is Big-O, not a measured benchmark: rather than assert a number I can't back up, the EA carries an InpLogTimings input that prints real elapsed milliseconds for scoring and retraining to the Journal on your own hardware - see "How to run and reproduce" for the steps.
A hard slippage cap in your trade-execution code is still worth keeping - it's a different layer catching a different problem. The cap protects one trade from an extreme fill; the forest watches for a pattern across many fills that individually pass every hard check but are, taken together, unlike anything the strategy has seen before. Neither substitutes for the other.
Author: Olamide Daniel Adebayo