Come faccio a sapere se i dati di mercato di un backtest erano davvero negoziabili?

Una riga di dati di mercato può essere perfettamente accurata e comunque non costituire una prova utilizzabile in un backtest. La transazione è avvenuta, il prezzo è corretto e il timestamp è valido; ma il feed potrebbe averla consegnata in ritardo, il fornitore potrebbe averla corretta in seguito oppure il mercato quotato potrebbe non essere accessibile alla strategia.

Per capire se i dati storici erano negoziabili, verifica più del solo timestamp dell’evento. Devi sapere che cosa descrive la riga, quando è diventata disponibile al sistema, quale venue o strumento rappresenta e se la quotazione o la transazione potevano plausibilmente supportare il tuo ordine.

Per un backtest basta un prezzo storico corretto?

No. L’accuratezza risponde alla domanda: «Quale prezzo ha registrato infine la fonte?». Un backtest deve anche rispondere a: «Che cosa avrebbe potuto sapere la mia strategia al momento della decisione?» e «Che cosa avrebbe potuto eseguire?». Sono domande distinte.

Immagina che una transazione crypto venga registrata alle 12:00:00.120, ma che il flusso del fornitore di dati la consegni al tuo processo alle 12:00:00.480. Una strategia che decide alle .200 non può usare quella transazione, anche se il timestamp dell’evento è precedente alla decisione. Se il file storico conserva solo l’ora dell’evento, il backtest può attribuire silenziosamente alla strategia informazioni che il processo live non aveva ancora ricevuto.

Se il tuo archivio non contiene gli orari di ricezione, sii trasparente su questa lacuna. Puoi testare un’ipotesi sulla latenza oppure limitare le conclusioni alla ricerca basata sull’ora degli eventi. Non puoi ricostruire l’esatto insieme di informazioni disponibili usando timestamp che non sono mai stati salvati.

Come faccio a capire se una quotazione era eseguibile?

Parti dal mercato a cui sarebbe arrivato il tuo ordine. Il miglior bid e ask consolidato può riassumere più venue; non dimostra che il tuo conto avesse accesso alla quantità esposta, che la quotazione fosse ancora presente all’arrivo dell’ordine o che la venue accettasse il tipo di ordine scelto.

Per un ordine a mercato, un’esecuzione al midpoint è di solito una finzione. Una stima più utile esaurisce i livelli visibili del book in base alla dimensione dell’ordine, poi aggiunge commissioni e un’ipotesi di latenza o impatto. Se hai solo dati top-of-book, limita le conclusioni: puoi stimare il primo livello, ma non dedurre una profondità mai registrata.

Per un ordine limite, il semplice tocco del prezzo non significa che l’ordine sia stato eseguito. Gli ordini davanti al tuo possono assorbire prima la quantità disponibile. Di solito gli snapshot ordinari non permettono di conoscere la posizione in coda, quindi una regola di esecuzione basata sul tocco del prezzo va considerata uno scenario ottimistico, non una prova di ciò che è successo.

Che cosa dovrei controllare prima di fidarmi di un archivio di dati di mercato?

Comincio dai controlli più semplici. Individuano più problemi di ricerca di un sofisticato modello di esecuzione applicato a un feed difettoso.

• Copertura: Ci sono intervalli mancanti, eventi duplicati, lacune nella sequenza o picchi inspiegabili di volume pari a zero?
• Identità del mercato: Il simbolo corrisponde nel tempo allo stesso exchange, contratto, valuta di quotazione e specifiche dello strumento?
• Disponibilità: Sono conservati sia gli orari degli eventi sia quelli di ricezione? Se no, quale ipotesi di ritardo limita il risultato?
• Correzioni: Puoi distinguere il messaggio originale dai successivi dati retroattivi o dalle revisioni del fornitore?
• Unità di misura: Prezzi, quantità, moltiplicatori dei contratti e timestamp sono interpretati in modo coerente?

Quest’ultimo controllo sembra quasi troppo elementare. Una volta ho passato una mattinata a indagare su un’apparente variazione del regime di volatilità, che si è rivelata dovuta a un campo quantità passato a un’altra unità dopo la migrazione del feed. Il grafico era bellissimo; l’unità era sbagliata.

Come posso verificare se la disponibilità dei dati cambia il risultato?

Esegui un piccolo test di sensibilità attorno alla soglia decisionale della strategia. Ritarda i dati utilizzabili di intervalli realistici, scarta gli aggiornamenti con sequenze discontinue e confronta le esecuzioni usando il book della venue effettiva, quando disponibile. Riporta sia il risultato originale sia quello degradato. Se un ritardo minimo annulla l’effetto, la strategia potrebbe dipendere da un vantaggio informativo che la tua configurazione di raccolta non è in grado di fornire con affidabilità.

Considera un esempio concreto: supponiamo che un segnale scatti quando il miglior bid sale di 1 tick. Riproducilo una volta usando l’ora dell’evento dell’exchange e una volta usando l’ora di ricezione del collector. Se la versione basata sull’ora dell’evento genera 40 operazioni e quella basata sull’ora di ricezione ne genera 27, questa differenza fa parte delle evidenze sulla strategia. Lo stesso vale per la performance di ciascuna riproduzione. Non nascondere quella più debole solo perché i suoi dati sembrano meno eleganti.

Il paper trading è un utile passaggio successivo, perché mette in luce ritardi del feed, quotazioni obsolete, errori nella mappatura dei simboli e filtri della venue lungo lo stesso percorso operativo usato dal sistema di ricerca. Non riprodurrà comunque ogni coda live o impatto sul mercato. Tieni presente questo limite.

Che cosa significa in pratica «dati negoziabili»?

Significa che il backtest può spiegare quando è avvenuta un’osservazione, quando la strategia avrebbe potuto utilizzarla, da quale mercato proveniva e quali evidenze di esecuzione supportano l’ipotesi di fill. Una serie di prezzi pulita è solo un punto di partenza. La ricerca diventa credibile quando le ipotesi su tempi, accesso ed esecuzione superano un esame approfondito e il risultato resta sensato anche dopo averle rese meno favorevoli.