A chi serve — A chi ha definito una versione di strategia e vuole osservarla sui dati che arriveranno dopo il congelamento, senza riscrivere regole, campione o criteri alla luce dei risultati.
Il forward test è la valutazione prospettica di una versione congelata: la specifica viene identificata in un momento preciso e, da quel momento, produce decisioni seguendo il flusso temporale reale. I dati futuri non possono essere riavvolti, scelti o sostituiti dopo averne visto l'esito. Il test misura il comportamento della versione nel periodo osservato; non prova che l'edge continuerà e non garantisce la stessa esecuzione a scala maggiore.
Out of sample e forward test rispondono a domande diverse. OOS descrive se un dato ha partecipato allo sviluppo: anche un segmento storico già esistente può essere OOS se è rimasto realmente sigillato. Il forward test descrive invece l'ordine cronologico: i dati arrivano dopo il congelamento. Paper, shadow e micro-live sono ambienti di implementazione nei quali il forward può essere condotto; non sono sinonimi di forward né di OOS.
Relazione fra dato, tempo e ambiente
| Termine | Classifica | Domanda corretta | Esempio |
|---|---|---|---|
| Out of sample | Relazione dato-sviluppo | Il dato ha influenzato una scelta? | Holdout storico mai consultato |
| Forward test | Relazione temporale | La decisione precede l'arrivo del dato? | Versione congelata da oggi |
| Paper trading | Ambiente simulato | L'ordine espone capitale reale? | Conto demo con fill modellati |
| Shadow mode | Implementazione parallela | La pipeline genera ma non instrada ordini? | Ordini ombra e log real-time |
| Micro-live | Ambiente reale ridotto | Quali effetti emergono con piccoli ordini veri? | Routing e fill con limiti stretti |
Le categorie possono sovrapporsi. Un'osservazione generata domani da una versione congelata e mai usata per modificarla è sia forward sia OOS rispetto a quella versione. Se il suo risultato orienta un nuovo filtro, diventa informazione di sviluppo per la versione successiva.
Che cosa deve essere congelato
Congelare “le regole” non basta. La versione comprende almeno:
- codice, dipendenze, configurazioni e seed pertinenti;
- universo, fonte dati, calendario, timestamp e regole sui missing;
- feature, parametri, segnali e gestione dei casi senza operazione;
- costruzione del portafoglio, sizing, leva e vincoli;
- tipi d'ordine, modello di fill, costi, funding e benchmark;
- metriche principali, controlli, soglie di alert e criterio di conclusione;
- modalità paper, shadow o live e relative differenze note.
Una modifica materiale crea un nuovo identificatore. Correggere un refuso nella documentazione può non alterare la versione; cambiare feature, universo, ritardo, costi, sizing o comportamento degli ordini normalmente sì. Il registro deve rendere verificabile la decisione.
Protocollo prospettico
- Scrivere il mandato. Distinguere obiettivo statistico, verifica della pipeline, qualità dell'esecuzione e addestramento operativo.
- Apporre il freeze. Conservare versione, hash degli artefatti, data e ora, responsabilità e criteri predefiniti di modifica o arresto.
- Scegliere l'ambiente. Dichiarare quali eventi sono simulati e quali reali; documentare modello di fill, broker, venue, feed e latenza.
- Registrare l'intero flusso. Conservare dati ricevuti, segnali nulli, intenzioni, ordini, rifiuti, fill, posizioni, costi, alert e interventi umani.
- Non ripulire retroattivamente. Errori e outage restano nel registro; eventuali esclusioni seguono regole definite prima e vengono mostrate.
- Confrontare con attese dichiarate. Valutare distribuzione, rischio, esposizione, turnover, esecuzione e benchmark con la relativa incertezza.
- Classificare le deviazioni. Separare incidente dati/operativo, errore di implementazione, execution drift, variabilità normale e possibile deterioramento del modello.
- Chiudere con una decisione tracciata. Continuare, limitare, sospendere, revalidare o creare una nuova versione sono esiti diversi da “profitto” e “perdita”.
Durata e quantità d'informazione
Non esiste una durata universale. Il calendario necessario dipende dalla frequenza della strategia, dalla dipendenza fra segnali, dall'orizzonte delle posizioni, dalla rarità degli eventi e dalla precisione richiesta. Molti trade correlati non equivalgono allo stesso numero di osservazioni indipendenti; poche settimane profittevoli possono non includere condizioni materiali.
Il protocollo dovrebbe definire criteri basati sulla copertura e sulla decisione: tipi di ordine osservati, sessioni ed eventi pertinenti, volume di informazione, precisione delle metriche e assenza di incidenti irrisolti. Una data finale può essere necessaria per la governance, ma non diventa per questo prova statistica di sufficienza.
Neppure una soglia unica di profit factor, Sharpe o drawdown decide il test. Le metriche vanno lette insieme, al netto dei costi, rispetto a un benchmark scelto prima e con intervalli compatibili con dipendenza e distribuzione. Un esito può essere favorevole, incompatibile con l'ipotesi o semplicemente non conclusivo.
Modifiche, incidenti e purezza
Durante il forward possono emergere difetti operativi che richiedono intervento immediato. La sicurezza prevale sulla purezza statistica: un kill switch non va ritardato per “salvare il test”. Il registro conserva l'incidente, la decisione e i dati coinvolti. Se la correzione cambia il comportamento, nasce una nuova versione con un nuovo periodo prospettico.
Consultare ripetutamente i risultati e aggiustare la strategia trasforma il forward in sviluppo iterativo. L'iterazione è lecita, ma deve essere chiamata con il suo nome; concatenare i segmenti delle diverse versioni e presentarli come un unico track record incontaminato è scorretto.
Esempio illustrativo
Esempio dichiarato illustrativo — La versione 1.0 viene congelata con segnali, sizing, costi e soglie operative. In shadow mode registra per ogni evento l'ordine che avrebbe inviato. Dopo l'avvio emerge che i dati di una sessione ridotta arrivano con un calendario errato: l'incidente viene conservato, la pipeline viene corretta e nasce la versione 1.1. I risultati della 1.0 non vengono attribuiti alla 1.1. Numeri di giorni o trade non sono specificati perché dipendono dall'obiettivo e dalla struttura informativa.
Il passaggio successivo potrebbe essere un micro-live limitato per osservare routing e riconciliazione. Non è obbligatorio né sufficiente in ogni contesto e richiede autorizzazioni, limiti di rischio e capacità operative adeguate.
Limiti
- Il forward osserva soltanto i regimi verificatisi dopo il freeze.
- Paper e shadow non riproducono pienamente coda, impatto, borrow e pressione economica; il micro-live non dimostra la capacità alla size obiettivo.
- Una versione congelata può condividere bias di dati e progettazione con il backtest.
- Monitorare molte metriche o molte strategie aumenta il rischio di selezione ex post.
- La prospettività migliora la tracciabilità, non trasforma una correlazione in causalità.
Fonti
- Leonard J. Tashman, Out-of-sample tests of forecasting accuracy: an analysis and review, 2000 — ordine temporale, rolling origin e valutazioni successive fuori campione.
- Joseph Simonian, CFA Institute Research Foundation, Investment Model Validation: A Guide for Practitioners, 2024 — validazione proattiva e affidabilità dei modelli d'investimento.
- National Futures Association, Interpretive Notice 9025 — Use of Promotional Material Containing Hypothetical Performance Results — limiti della performance ipotetica nel relativo ambito NFA.
- U.S. Securities and Exchange Commission, Staff Report on Algorithmic Trading in U.S. Capital Markets, 2020 — automazione, venue e interazione degli ordini nei mercati reali.
- Commissione europea, Regolamento delegato (UE) 2017/589, RTS 6 — test, controlli, documentazione e deployment nel proprio perimetro normativo UE.