Perché il mio backtest continua a sostituire i dati sulle opzioni?

Un backtest sulle opzioni può cambiare senza che venga modificata una sola riga del codice della strategia. Un fornitore corregge una quotazione errata, aggiunge un’operazione arrivata in ritardo, rivede i metadati di un contratto o modifica il filtro per i mercati incrociati. Ripeti il backtest sulle stesse date e ottieni un’esecuzione diversa, una posizione diversa, magari uno Sharpe diverso. Non è necessariamente un bug della strategia. È cambiata la base di dati su cui è stata testata.

Per rendere riproducibile un backtest sulle opzioni, tratta i dati di mercato come un input versionato. Registra quale snapshot hai usato, conserva le osservazioni grezze che hanno determinato ogni decisione e confronta i risultati cambiati a livello di contratto e timestamp prima di fidarti del nuovo dato aggregato.

Perché il mio backtest sulle opzioni è cambiato anche se il codice è rimasto uguale?

I dati sulle opzioni sono particolarmente sensibili alle correzioni, perché la negoziabilità apparente di un contratto dipende da più campi che cambiano insieme: bid, ask, quantità, prezzo del sottostante, scadenza, strike e moltiplicatore o deliverable del contratto. Una quotazione corretta può trasformare un’apparente opportunità in un mercato incrociato. Una correzione dei metadati può cambiare il significato del moltiplicatore di una posizione.

Immagina una strategia che compra una call quando l’ask è inferiore a $2.00. Al primo caricamento dei dati, la quotazione delle 10:14 ha un ask di $1.95, un bid di $1.90 e una quantità di 5. Una revisione successiva del fornitore porta l’ask a $2.05 dopo aver riconciliato un messaggio tardivo della borsa. Basta un’osservazione per far scattare o annullare il segnale. Se quel contratto era l’unica operazione della strategia quel giorno, una correzione modesta dei dati può determinare gran parte del rendimento giornaliero.

Anche il filtraggio delle quotazioni conta. I fornitori possono eliminare quotazioni obsolete, rimuovere i mercati incrociati o normalizzare i timestamp in modo diverso. Queste scelte possono essere ragionevoli, ma fanno parte dell’identità del dataset. “Opzioni SPY, da gennaio a marzo” non definisce una storia riproducibile.

Cos’è una versione dei dati sulle opzioni?

Una versione dei dati è l’insieme esatto delle osservazioni storiche disponibili per una specifica esecuzione di ricerca. Conserva il nome del fornitore e del dataset, l’ora di recupero, l’intervallo di date, la versione dello schema e le eventuali regole di pulizia o filtraggio. Se il fornitore rende disponibili ID degli snapshot o timestamp delle revisioni, salva anche quelli.

Per ogni decisione simulata, conserva informazioni sufficienti per rispondere a queste domande: quale contratto è stato preso in considerazione, quale quotazione è stata selezionata, quando è stata pubblicata o ricevuta e quale regola l’ha resa idonea? Contano sia il record grezzo sia quello derivato. Un NBBO ripulito senza i timestamp originali può nascondere se una quotazione era obsoleta o è arrivata dopo la decisione simulata.

Come verifico se una revisione del fornitore ha cambiato i miei risultati?

Esegui la stessa strategia e la stessa configurazione su entrambi gli snapshot. Per prima cosa confronta il numero di osservazioni e contratti idonei per data. Poi confronta decisioni ed esecuzioni: quali segnali sono comparsi o scomparsi, quale quotazione è cambiata e se il nuovo record ha modificato il prezzo di esecuzione simulato.

Non fermarti al rendimento totale. Tieni traccia delle variazioni nel numero di operazioni, nei prezzi di ingresso e uscita, nei segnali rifiutati e nella quota di P&L generata da operazioni presenti in una sola versione dei dati. Uno Sharpe simile può nascondere la sostituzione di singole operazioni; la statistica principale non ti dirà che la storia sottostante è cambiata.

Per un audit utile, mantieni fissi la strategia, le commissioni e le ipotesi di esecuzione. Se cambiano più elementi contemporaneamente, non saprai se la divergenza è dovuta alla correzione del fornitore o al tuo esperimento.

Dovrei usare sempre la storia più recente delle opzioni?

Usa la storia più recente quando vuoi basarti sulla ricostruzione attuale più accurata del fornitore. Conserva lo snapshot precedente quando devi riprodurre un risultato passato o capire quali informazioni erano disponibili al tuo sistema di ricerca in quel momento. Sono domande diverse.

Per la ricerca point-in-time, un record corretto può essere più accurato oggi e comunque non essere stato disponibile alla strategia all’epoca. Quando possibile, conserva gli orari di pubblicazione e ricezione; altrimenti, indica chiaramente questa limitazione. Una ricostruzione moderna non equivale automaticamente all’insieme di informazioni disponibile storicamente.

Quando cambia un backtest sulle opzioni, la prima domanda dovrebbe essere: “Quali osservazioni sono cambiate?”. La domanda “Quale esecuzione è corretta?” viene dopo, quando sai rispondere alla prima.

Cosa dovrei salvare con ogni backtest?

Salva accanto ai risultati un manifest conciso: fornitore dei dati e snapshot, ora di recupero, versioni dello schema e dei criteri di pulizia, fonte dei metadati dei contratti, commit della strategia, ipotesi di esecuzione e configurazione dell’esecuzione. Collega ogni operazione ai record delle quotazioni che l’hanno giustificata.

Questo piccolo registro trasforma una riesecuzione inspiegabile in un diff che puoi esaminare. La storia delle opzioni continuerà a essere corretta. Il tuo processo di ricerca dovrebbe rendere visibile ogni correzione, così un archivio migliore migliora la base di dati senza riscrivere silenziosamente l’esperimento.