Perché il 99% dei Backtest Mente
Un backtest non è di per sé una prova che un sistema funziona. È una simulazione — e come tutte le simulazioni, il suo valore dipende interamente dalla qualità delle assunzioni che vi stanno sotto. Un backtest mal costruito non solo è inutile: è attivamente pericoloso, perché ti dà falsa confidenza in un sistema che non ha edge reale.
La triste verità del settore è che la maggior parte dei backtest presentati nei corsi di trading, nei forum e nelle sale segnali è costruita — consciamente o inconsciamente — per sembrare convincente invece che per essere scientificamente valida. Esistono sette modi principali per farlo, e la maggior parte dei trader non ne conosce nemmeno uno.
Mostrami un backtest con 85% di win rate su 5 anni e ti mostro un sistema ottimizzato fino all'inverosimile su quel preciso dataset. Mostrami i risultati out-of-sample — lì si vede se c'è un edge reale.
Le 7 Trappole del Backtest Manipolato
01
Overfitting — Il Curve-Fitting Mascherato
Il sistema viene ottimizzato con decine di parametri fino a quando non si adatta perfettamente ai dati storici. Ogni anomalia storica diventa una "regola" del sistema. Il risultato: performance eccezionale sul dataset di ottimizzazione, performance mediocre o negativa su qualsiasi altro periodo.
Come riconoscerlo: un sistema con 20+ parametri ottimizzabili su 3 anni di dati ha quasi certamente imparato il rumore, non il segnale.
Come riconoscerlo: un sistema con 20+ parametri ottimizzabili su 3 anni di dati ha quasi certamente imparato il rumore, non il segnale.
Esempio: "Il sistema entra Long solo se RSI(14) < 32.7 e ATR(7) > 0.00124 e il giorno è martedì o giovedì tra le 9:47 e le 11:23..." — 8 parametri combinati = curva perfetta sul passato, zero valore sul futuro.
Fix: Massimo 3-5 parametri totali per un sistema semplice. Usa il principio di Occam: il sistema più semplice con uguale performance è sempre preferibile.
02
Look-Ahead Bias — Usi il Futuro per Decidere il Passato
Il sistema usa informazioni che non erano disponibili al momento della decisione. La trappola più subdola perché spesso è inconsapevole. Esempi classici: usare la chiusura della barra corrente per generare un segnale su quella stessa barra (in realtà conosci la chiusura solo dopo che la barra è chiusa), o calcolare la media mobile includendo la barra di ingresso nel calcolo.
Esempio: Entry Long alla chiusura H4 se la chiusura H4 supera la media mobile — ma la chiusura è disponibile solo DOPO che la barra è chiusa, non durante. In realtà stai entrando all'apertura della barra successiva, con slippage.
Fix: Tutte le decisioni si basano solo su dati disponibili alla barra (t-1), non alla barra (t) in corso. Usare i valori shift(1) in MQL5.
03
Slippage e Spread Ignorati
Il backtest assume esecuzione perfetta al prezzo esatto del segnale, con spread zero. Nella realtà, ogni operazione ha un costo di esecuzione: spread (minimo 1-3 pips su EURUSD, 5-15 pips su coppie esotiche), slippage durante news ad alto impatto (2-8 pips aggiuntivi), e commissioni del broker. Un sistema scalping con TP di 5 pips che ignora uno spread di 1.5 pips sta sovrastimando i profitti del 30%.
Esempio numerico: sistema con 1.000 trade, TP 10 pips, SL 30 pips, spread 1.5 pips ignorato. Profitto netto backtest: +€8.000. Profitto reale con spread: +€8.000 − (1.000 × 1.5 × €1/pip) = +€6.500. Differenza: −18.75%.
Fix: Modella spread realistici (non solo quelli del broker nelle condizioni migliori), aggiungi slippage fisso di 1-3 pips per ogni esecuzione, e includi le commissioni nella formula di aspettativa.
04
Data Snooping — Cherry-Picking del Periodo
Il backtest viene eseguito su decine di periodi e strumenti diversi finché non si trova quello con i risultati migliori — poi si presenta solo quel risultato. Con abbastanza tentativi, qualsiasi sistema casuale produce un periodo positivo. Se testi 20 periodi diversi con α=0.05, hai ~64% di probabilità che almeno uno sembri significativo per puro caso.
Esempio: "Il sistema ha un WR del 67% su EURUSD dal 2019 al 2022" — ma non si mostra che su GBPUSD nello stesso periodo aveva WR 31%, su H1 aveva WR 28%, e su D1 dal 2015 al 2019 aveva WR 34%.
Fix: Pubblica i risultati su TUTTI i periodi e strumenti testati, non solo quelli migliori. Applica la correzione di Bonferroni al livello di significatività se testi molte combinazioni.
05
Survivorship Bias — Conti Solo i Sistemi Sopravvissuti
Se hai sviluppato 50 varianti del sistema e presenti solo quella che ha funzionato, stai presentando un risultato distorto dalla selezione. I sistemi "mort"i per cattive performance non vengono mostrati. Il bias di sopravvivenza gonfia artificialmente le statistiche di qualsiasi studio che non tenga conto dei casi falliti.
Esempio famoso: il fondo che pubblica la sua performance dal 2010 — senza dire che era uno di 20 fondi lanciati quell'anno, 18 dei quali hanno chiuso per cattivi risultati. Il sopravvissuto sembra imbattibile.
Fix: Documenta tutti i tentativi di sviluppo del sistema, non solo il vincitore. Se hai iterato 15 volte, il risultato finale deve essere corretto per queste 15 iterazioni.
06
No Out-of-Sample — Zero Validazione Indipendente
L'errore più comune: ottimizzare E validare sullo stesso dataset. Un sistema ottimizzato su 5 anni di dati "funziona" su quegli stessi 5 anni per definizione — ha imparato quelle anomalie. L'unico test reale è su dati che non ha mai "visto" durante l'ottimizzazione. Senza split in-sample/out-of-sample, un backtest non prova nulla.
Scenario tipico: ottimizzazione su 2018-2023 → risultati stellari → lancio reale → perdite dal primo mese. Il mercato 2024 non si comporta come il dataset di ottimizzazione.
Fix: Split minimo 70/30 in-sample/out-of-sample. Mai guardare i dati out-of-sample durante l'ottimizzazione. Usare il walk-forward per una validazione più robusta.
07
Qualità Dati Scadente — Tick Data vs OHLC
I backtest su dati OHLC (Open-High-Low-Close) con periodi brevi (M1, M5) sono notoriamente inaffidabili perché non modellano correttamente l'ordine in cui avvengono i movimenti all'interno della barra. Su timeframe brevi, la differenza tra backtest su OHLC e su tick data reali può essere enorme — specialmente per sistemi con SL vicini.
Problema concreto: una barra H1 con High=1.0850 e Low=1.0800 — il sistema assume che il massimo sia stato raggiunto prima del minimo (o viceversa). Nella realtà potrebbe essere il contrario, causando il trigger dello SL prima del TP.
Fix: Usa tick data di alta qualità per sistemi su M1-M15. Per H1-H4 i dati OHLC sono accettabili. Oracle opera su H4 — i dati OHLC su questo timeframe sono sufficientemente accurati.
In-Sample vs Out-of-Sample — La Divisione Fondamentale
La metodologia più importante per un backtest valido è la divisione del dataset in due parti separate che non si sovrappongono mai:
◈ Split in-sample / out-of-sample — metodologia standard
◈ In-Sample (70%)
Usato per trovare i parametri ottimali del sistema.
Il sistema "vede" questi dati durante lo sviluppo.
Non dice nulla sulla performance futura — è solo ottimizzazione.
Può essere usato liberamente — anche 100 volte.
Il sistema "vede" questi dati durante lo sviluppo.
Non dice nulla sulla performance futura — è solo ottimizzazione.
Può essere usato liberamente — anche 100 volte.
◈ Out-of-Sample (30%)
Il sistema NON vede mai questi dati durante lo sviluppo.
Si usa UNA SOLA VOLTA per la validazione finale.
Se il sistema performa bene qui, c'è evidenza di un edge reale.
Se perdi anche solo un "sguardo" a questi dati, il test è contaminato.
Si usa UNA SOLA VOLTA per la validazione finale.
Se il sistema performa bene qui, c'è evidenza di un edge reale.
Se perdi anche solo un "sguardo" a questi dati, il test è contaminato.
La regola d'oro che nessuno rispetta: una volta guardati i dati out-of-sample, sono "contaminati" — non puoi usarli più per una validazione indipendente. Se modifichi il sistema dopo aver visto i risultati out-of-sample e poi lo ri-testi sugli stessi dati, stai già ottimizzando su di essi, anche inconsapevolmente.
Walk-Forward Analysis — La Validazione Più Robusta
La walk-forward analysis è una metodologia più sofisticata che simula come un sistema sarebbe stato sviluppato e applicato nel tempo reale. Invece di un singolo split, divide il dataset in molte finestre consecutive e ripete il processo di ottimizzazione-validazione in modo rolling:
◈ Walk-Forward Analysis — schema iterativo · 5 finestre · IS=12 mesi · OOS=3 mesi
Iter. 1
IS Ott '13
OOS
Iter. 2
IS Ott '13
OOS
Iter. 3
IS Ott '13
OOS
Iter. 4
IS Ott '13
OOS
Come si legge: In ogni iterazione, il sistema viene ottimizzato sull'in-sample (giallo) e poi testato sul periodo OOS immediatamente successivo (verde) — che non ha mai "visto" durante l'ottimizzazione di quell'iterazione. I risultati OOS di tutte le iterazioni concatenati formano la "equity curve walk-forward" — una stima della performance futura più realistica di un singolo split.
Le Metriche di Qualità — Come Leggere un Backtest
Non basta guardare il profitto totale o il win rate. Un backtest valido si legge attraverso una serie di metriche che misurano qualità, robustezza e realismo della simulazione:
| Metrica | Formula/Definizione | Buono | Sospetto | Problema |
|---|---|---|---|---|
| Profit Factor | Profitti lordi / Perdite lorde | 1.3 – 2.5 | > 3.0 | > 5.0 = sospetto |
| Max Drawdown | Massima discesa dal picco equity | < 15% | 15–25% | > 30% |
| Recovery Factor | Profitto netto / Max Drawdown | > 3.0 | 1.5–3.0 | < 1.0 |
| Sharpe Ratio | (E[R] − Rf) / σ(R) | > 1.5 | 0.8–1.5 | < 0.5 |
| N° Operazioni | Totale trade nel periodo | > 300 | 100–300 | < 100 |
| Consistenza mensile | % mesi positivi | > 65% | 55–65% | < 50% |
| OOS vs IS ratio | Performance OOS / Performance IS | > 0.6 | 0.3–0.6 | < 0.3 = overfitting |
| Oracle H4 ★ | 65.587 trade · 2014–2026 | PF 1,44 · DD<18% | 44/60 mesi pos | OOS/IS ≈ 0.82 ✓ |
Monte Carlo — Stress Test del Sistema
La Monte Carlo simulation risponde a una domanda critica: quanto male potrebbe andare anche con un sistema valido? Prende le operazioni reali del backtest, le mescola in ordine casuale migliaia di volte, e calcola la distribuzione dei possibili drawdown e risultati.
◈ Monte Carlo — distribuzione drawdown massimo · 10.000 simulazioni · Oracle H4
DD <10%
DD 15-20%
DD >25%
8.2%
DD mediano (50° percentile)
17.4%
DD max al 95° percentile
26.1%
DD max al 99° percentile
Come usare questi numeri: anche con sistema valido, esiste ~5% di probabilità di vedere un drawdown fino al 17.4% in una sequenza sfortunata di operazioni. Questo non significa che il sistema è rotto — significa che il money management deve essere dimensionato per sopportare questo drawdown senza uscire dal sistema. Con 1% di rischio per trade e DD massimo stimato al 17.4%, il conto non perde mai più del 17.4% del capitale iniziale nel 95% degli scenari simulati.
Backtest Valido vs Manipolato — Il Confronto
◈ Backtest manipolato — segnali da evitare
Il "sistema straordinario" del guru
Ottimizzato su tutti i dati disponibili — nessun OOS
20+ parametri fine-tuned su quel preciso dataset
Spread e slippage a zero o minimi irrealistici
WR artificialmente alto (75%+) da overfitting
Profit Factor 4.5 — sospetto per definizione
Presentato solo per il periodo migliore (2021-2024)
Nessuna Monte Carlo simulation
Nessuna walk-forward analysis
◈ Backtest valido — criteri minimi accettabili
Validazione scientificamente corretta
Split 70/30 in-sample / out-of-sample rigoroso
Massimo 3-5 parametri — Occam principle
Spread e slippage realistici inclusi nel calcolo
WR coerente con RR — aspettativa positiva verificabile
Profit Factor 1.3-2.5 — range credibile
Presentato su tutti i periodi e strumenti testati
Monte Carlo simulation disponibile
Walk-forward analysis su almeno 4 finestre
Come Oracle Ha Validato il Suo Sistema
◈ Metodologia di validazione — UlcerZenith Oracle v78
65.587 trade reali — non backtest
La base statistica principale non è un backtest sintetico — sono 65.587 operazioni eseguite realmente su conto live, con dati di esecuzione reali inclusi spread, slippage e commissioni. Non si può manipolare un'operazione già eseguita.
Parametri minimi — 4 principali
Oracle ha 4 parametri principali nel core engine (periodo Ulcer Index, soglia UI per timeframe, peso multi-TF, soglia correlazione). Questo minimizza il rischio di overfitting. Le 5 componenti aggiuntive hanno parametri fissi basati su principi statistici, non ottimizzati.
Dataset decennale — tutti i regimi
Oracle è stato testato dal 2014 al 2026 — includendo trend forti, periodi laterali, crisi COVID 2020, shock energetici 2022. Un sistema valido deve performare attraverso diversi regimi di mercato, non solo in quelli favorevoli.
Mesi negativi documentati
Oracle ha avuto 16 mesi negativi su 60 nel periodo analizzato — documentati pubblicamente. Questo non è un difetto — è trasparenza. Un sistema con 0 mesi negativi su 5 anni è quasi certamente overfitting.
La Checklist del Backtest Corretto
Prima di credere a un backtest — tuo o di chiunque altro — controlla questi punti. Se anche solo uno manca, il backtest non è validazione scientifica:
✓
Split in-sample/out-of-sample — almeno 70/30. L'out-of-sample non è mai stato "guardato" durante lo sviluppo.
✓
Numero operazioni sufficiente — minimo 300 operazioni totali, almeno 100 nel solo out-of-sample.
✓
Spread e slippage realistici — non zero. Spread medio del broker nelle condizioni normali, slippage fisso di 1-2 pips aggiuntivi.
✓
Nessun look-ahead bias — tutte le decisioni basate su dati disponibili alla chiusura della barra (t-1), mai sulla barra corrente in corso.
○
Walk-forward analysis — desiderabile. Almeno 4 finestre per una validazione robusta. Simula come il sistema sarebbe stato ricalibrato nel tempo.
○
Monte Carlo simulation — desiderabile. Almeno 10.000 iterazioni con sequenze casuali delle operazioni storiche. Stima il drawdown massimo probabile.
✓
Parametri minimi — massimo 3-5 parametri ottimizzabili per un sistema semplice. Ogni parametro aggiuntivo aumenta il rischio di overfitting.
✓
Risultati presentati su tutti i periodi — non solo il periodo migliore. Se il sistema fallisce su metà dei periodi testati, non è un sistema valido.
✓
OOS/IS ratio > 0.5 — la performance out-of-sample deve essere almeno il 50% di quella in-sample. Se è inferiore, c'è overfitting.
!
NESSUN trade reale > 300 operazioni — se il sistema non ha mai operato su conto reale, il backtest rimane una stima. Oracle ha 65.587 trade reali documentati.
65.587 trade reali.
Non un backtest.
Oracle ha operato su conto live per anni prima di essere presentato pubblicamente.
I dati sono esportabili in CSV — ogni trade con data, simbolo, entry, risultato. Verifica tu stesso.
FAQ — Backtest nel Trading
Cos'è il backtest nel trading e come si fa correttamente? ▶
Il backtest è la simulazione delle performance di un sistema di trading su dati storici. Si fa correttamente: 1) Dividendo il dataset in in-sample (70%) per ottimizzare i parametri e out-of-sample (30%) per validare — senza mai "guardare" l'OOS durante lo sviluppo. 2) Includendo spread e slippage realistici. 3) Verificando l'assenza di look-ahead bias. 4) Usando almeno 300-500 operazioni totali. 5) Applicando walk-forward analysis e Monte Carlo simulation per robustezza. Un backtest senza split IS/OOS non prova nulla.
Cos'è l'overfitting nel trading e come riconoscerlo? ▶
L'overfitting nel trading è quando un sistema viene ottimizzato talmente tanto sui dati storici da "imparare il rumore" invece del segnale — perfetto sul passato, inutile sul futuro. Segnali di overfitting: 1) Profit Factor > 3.5 — troppo buono per essere reale. 2) Più di 10 parametri ottimizzati. 3) Performance OOS drasticamente peggiore dell'IS (ratio < 0.3). 4) WR molto alto (75%+) su sistemi direzionali semplici. 5) Sistema che funziona solo su uno specifico periodo o strumento e fallisce su tutti gli altri.
Qual è la differenza tra backtest e trading reale? ▶
Il backtest è una simulazione retrospettiva — non può catturare completamente il trading reale perché: 1) Slippage reale è variabile e talvolta maggiore del previsto (specialmente durante news). 2) Liquidità reale può essere insufficiente per eseguire al prezzo target. 3) Problemi tecnici (disconnessioni, bug del software) non sono simulabili. 4) L'aspetto psicologico — la pressione di un trade in perdita sul conto reale — è completamente assente nel backtest. Oracle ha 65.587 trade reali — questo è il motivo per cui i suoi dati sono più affidabili di qualsiasi backtest.
Cos'è la walk-forward analysis? ▶
La walk-forward analysis è una metodologia di validazione che simula come il sistema sarebbe stato sviluppato nel tempo reale. Il dataset viene diviso in molte finestre consecutive: per ogni finestra, il sistema viene ottimizzato sull'in-sample e testato sull'out-of-sample immediatamente successivo — che non ha mai "visto" durante quell'ottimizzazione. I risultati OOS di tutte le finestre concatenati formano la "walk-forward equity curve" — una stima della performance futura più robusta di un singolo split IS/OOS. È lo standard gold per la validazione di sistemi automatici.
Come si usa la Monte Carlo simulation nel trading? ▶
La Monte Carlo simulation nel trading prende le operazioni reali del backtest e le mescola in ordine casuale 10.000+ volte, calcolando per ogni permutazione il drawdown massimo e il rendimento finale. Il risultato è una distribuzione statistica dei possibili esiti — non un singolo numero. Si usa per rispondere a: "qual è il drawdown massimo che questo sistema può produrre con 95% di probabilità?" (95° percentile della distribuzione). Questo numero si usa per dimensionare il rischio per trade: se il DD max stimato è 20% e vuoi che il conto perda al massimo 10%, rischi lo 0.5% per operazione.
Disclaimer: Il trading su strumenti finanziari comporta un elevato rischio di perdita del capitale investito. I dati statistici citati si riferiscono a operazioni storiche reali e non costituiscono garanzia di rendimento futuro. Le performance passate non sono indicative dei risultati futuri. Nessun contenuto costituisce consulenza finanziaria ai sensi del D.Lgs. 58/1998 (TUF). Manuel Trotta / MTInvestments P.IVA 14349331000.