Dati point-in-time

I dati point-in-time conservano la storia così come poteva essere osservata in ciascun istante. Per ogni valore non basta la data a cui il dato si riferisce: occorre registrare quando fu pubblicato, quando divenne disponibile al sistema, quale versione era allora valida e fino a quando rimase tale. Un database aggiornato e corretto oggi può descrivere perfettamente il passato e, nello stesso tempo, essere inadatto a simulare una decisione passata.

Le quattro date da non confondere

Il timestamp di disponibilità è quello operativo. Un comunicato pubblicato alle 16:05 di New York non può generare un ordine alla chiusura delle 16:00. Se il sistema acquisisce il file alle 16:08, la prima decisione ammissibile deve rispettare anche quella latenza. Per dati giornalieri senza orario affidabile è prudente definire una convenzione esplicita, per esempio “utilizzabile dalla seduta successiva”, e documentarla.

I dati macro illustrano bene il problema del revision vintage. Produzione, occupazione e crescita possono essere corretti molte volte. La serie più recente risponde a “qual è oggi la migliore stima del passato”; un test point-in-time risponde a “quale stima era pubblica in quella data”. Sono domande diverse.

Universo, identificatori e appartenenza

Un elenco odierno di titoli, fondi o contratti non può essere proiettato all'indietro. L'universo deve essere una tabella temporale con intervalli di validità:

Il ticker è un'etichetta, non un'identità stabile: può cambiare o essere riutilizzato. Per collegare prezzi, bilanci e corporate action servono identificatori persistenti e una mappa con validità temporale. Anche la classificazione settoriale o il paese di appartenenza possono cambiare; usare la classificazione attuale nel 2010 introduce informazione retrospettiva.

Corporate action e delisting

Split, dividendi, spin-off, fusioni, offerte, conversioni e cambi di simbolo richiedono più date: annuncio, ex-date, record date, pagamento ed efficacia. Una serie “adjusted close” ricalcolata oggi è comoda per i rendimenti, ma non sostituisce un registro causale degli eventi. Il fattore di aggiustamento deve essere applicato in modo coerente allo scopo: confrontare rendimenti totali non è la stessa cosa che simulare limiti, quantità e ordini osservabili prima dell'evento.

Il delisting non autorizza a eliminare l'ultima osservazione. Occorre conservare motivo, data, eventuale rendimento di delisting, distribuzione o valore di recupero e regola adottata quando il dato manca. Una perdita cancellata dal database rende il campione più sano di quanto fosse e si collega direttamente al survivorship bias.

Protocollo point-in-time

1. Fissa il tempo decisionale. Definisci timezone, calendario, cutoff e frequenza di ogni strategia.
2. Separa evento e disponibilità. Conserva event_time, published_at, available_at e ingested_at quando disponibili.
3. Archivia i vintage. Non sovrascrivere una revisione: aggiungi una nuova versione con inizio e fine validità.
4. Usa identità persistenti. Mappa ticker e descrizioni a identificatori stabili con intervalli temporali.
5. Ricostruisci l'universo. Salva membership, eleggibilità, annunci ed effettività; non partire dai superstiti odierni.
6. Tratta le corporate action come eventi. Conserva termini, date e fonti, poi genera gli aggiustamenti necessari.
7. Mantieni fallimenti e assenze. Delisting, sospensioni, fondi chiusi e valori mancanti fanno parte della storia.
8. Modella la latenza. Aggiungi ritardo di vendor, elaborazione e successiva finestra di negoziazione.
9. Rendi ripetibile la query. Il comando “mostrami ciò che era noto alle 10:00 del giorno X” deve restituire sempre lo stesso snapshot.
10. Congela il dataset del test. Registra versione, checksum, trasformazioni e codice insieme ai risultati out-of-sample.

Controlli rapidi

Limiti

Una base point-in-time riduce il look-ahead bias, ma non certifica la strategia. Dati tardivi possono essere errati; una fonte può avere copertura selettiva; la pipeline può applicare trasformazioni future; l'universo può restare incompleto. Inoltre il point-in-time non modella automaticamente ordini, liquidità, capacità o costi di transazione nel backtest. Ogni risultato resta condizionato a fonti, convenzioni e disponibilità documentate.

Fonti

• Federal Reserve Bank of St. Louis, ALFRED® e Real-Time Periods — archiviazione dei valori originariamente pubblicati, revisioni e periodi di validità informativa.
• U.S. Securities and Exchange Commission, EDGAR Application Programming Interfaces — storia dei filing, metadati e aggiornamento delle informazioni disseminate.
• Center for Research in Security Prices, CRSP Survivor-Bias-Free US Mutual Fund Database Guide — struttura storica comprendente fondi attivi e cessati.
• Tyler Shumway, The Delisting Bias in CRSP Data, The Journal of Finance, 1997 — conseguenze dell'omissione dei rendimenti di delisting.
• S&P Dow Jones Indices, Equity Indices Policies & Practices — annunci, date effettive, ribilanciamenti e trattamento delle correzioni di composizione.

Collegamenti

• Trading sistematico
• Backtest
• Out-of-sample
• Data leakage e look-ahead bias
• Survivorship bias
• Costi di transazione nei backtest