Il backtest è stato superato. La strategia paper ha mancato il 37% degli ordini.

Il nostro backtest ha conteggiato 91 esecuzioni su 100 ordini inviati. Nel paper trading, la stessa strategia ne ha ottenute 63. Il tempo mediano tra il segnale e la conferma di ricezione dell’ordine è stato di 84 millisecondi; 12 delle esecuzioni mancate nel paper trading erano ordini limit che il backtest considerava eseguiti non appena il prezzo li raggiungeva.

Quella differenza di 28 punti sembrava un problema della strategia, finché non abbiamo separato le decisioni sugli ordini da quelle sulle esecuzioni. In entrambe le simulazioni, la strategia ha scelto quasi sempre lo stesso lato, la stessa quantità e lo stesso prezzo. A cambiare è stato il percorso di esecuzione: alcuni ordini sono arrivati in ritardo, altri sono rimasti aperti e altri ancora hanno incontrato un mercato già in movimento.

Che cosa significa parità degli ordini tra backtest e paper trading?

Parità significa che il backtest e il sistema paper prendono decisioni confrontabili a partire dalle stesse informazioni disponibili, tenendo poi conto esplicitamente dei diversi modelli di esecuzione. Non significa che ogni esecuzione simulata debba corrispondere a un’esecuzione paper. Le barre storiche non permettono di ricostruire la posizione in coda e il venue paper può usare un modello di matching diverso da quello di un exchange live.

La domanda utile è più circoscritta: per ogni ordine che la strategia intendeva piazzare, sai spiegare che cosa è successo dopo? Il numero di trade e il rendimento finale nascondono troppi dettagli. Conserva un record collegato per ogni decisione, usando un ID stabile della decisione della strategia che accompagni gli eventi di segnale, ordine, conferma, annullamento ed esecuzione.

Perché gli ordini limit raggiunti dal prezzo hanno causato così tante mancate esecuzioni?

Il nostro backtest usava barre da 1 minuto. Se il prezzo di un ordine limit rientrava nell’intervallo tra il massimo e il minimo della barra, l’ordine veniva segnato come eseguito. Questa regola stabilisce se, in un momento qualsiasi di quel minuto, il mercato ha scambiato a quel prezzo. Non dice se il nostro ordine fosse già attivo, se fosse il primo in coda o se, dopo il suo arrivo, fosse stata scambiata una quantità sufficiente.

I log paper hanno messo in luce il problema dei tempi. La strategia ha calcolato un segnale alle 12:03:00.000, ma l’evento di mercato è arrivato al processo degli ordini 31 millisecondi dopo. I controlli di rischio hanno richiesto altri 22 millisecondi e il simulatore del venue ha confermato la ricezione dell’ordine 31 millisecondi più tardi. Durante un movimento rapido, una barra storica può far sembrare raggiungibile un prezzo, anche se il limit è arrivato quando il mercato lo aveva già superato.

C’era anche un’altra complicazione: dodici ordini paper erano ancora aperti quando il backtest era già passato oltre. Il simulatore accettava una richiesta di annullamento come se l’ordine fosse scomparso all’istante. Nel sistema paper, la conferma dell’annullamento arrivava più tardi; tre ordini sono stati eseguiti nel frattempo. Questo ha modificato la posizione vista dal segnale successivo.

Come posso misurare la discrepanza senza ingannarmi?

Inizia con un semplice report di riconciliazione, raggruppato per intento dell’ordine. Rendi visibile il denominatore. Il «tasso di esecuzione» può indicare le esecuzioni per ordine inviato, la quantità eseguita divisa per quella richiesta oppure gli ordini eseguiti divisi per quelli arrivati al venue. Sono misure che rispondono a domande diverse.

1. Collega gli eventi usando l’ID della decisione o l’ID client dell’ordine, non un timestamp ricostruito a posteriori.
2. Confronta prima le decisioni: ora del segnale, lato, quantità richiesta, tipo di ordine e prezzo limit.
3. Per le decisioni corrispondenti, confronta il ritardo della conferma, i rifiuti, il tempo di apertura, il tempo di annullamento, la quantità eseguita e il prezzo di esecuzione ponderato per il volume.
4. Riporta i tassi per tipo di ordine e condizioni di mercato. Un tasso di esecuzione complessivo del 63% può nascondere il 90% per gli ordini market e il 35% per i limit passivi.

Mantieni ben distinte le categorie. Un ordine rifiutato non è un ordine non eseguito; un ordine eseguito parzialmente non è un’esecuzione completa; e un ordine annullato dopo un’esecuzione parziale ha comunque modificato la posizione. Conta sia gli ordini sia le quantità richieste, così un gruppo di ordini di entità minima non farà sembrare il risultato migliore di quanto sia.

Che cosa dovremmo cambiare nel backtest?

Usa una regola di esecuzione coerente con la risoluzione dei dati e il comportamento previsto dell’ordine. Con i dati a barre, un limit raggiunto dal prezzo è un indizio di una possibile esecuzione, non una prova. Puoi modellare esecuzioni parziali in modo prudente, richiedere che il prezzo superi il limit oppure escludere gli ordini passivi la cui posizione in coda non è stimabile. Ogni scelta risponde a una domanda diversa: documentala e confronta i risultati usando più di una regola plausibile.

Modella anche lo stato degli ordini. Un ordine rimane attivo finché il sistema non riceve un evento terminale; una richiesta di annullamento non elimina l’esposizione. Se la strategia può inviare un secondo ordine mentre il primo è in attesa, il backtest deve rappresentare questa condizione di gara oppure impedirla per progettazione.

Un modello di esecuzione afferma che cosa avrebbe potuto fare il tuo ordine. Dagli una regola che sai spiegare, poi confrontala con i log paper.

Nella nostra discrepanza di 28 punti, la sorpresa non è stata che un backtest basato su barre da 1 minuto sovrastimasse le esecuzioni passive. È stata la divergenza della posizione della strategia prima della decisione successiva, perché i tempi di annullamento erano stati omessi. Una volta corretto il modello dello stato degli ordini e smesso di trattare ogni limit raggiunto dal prezzo come un’esecuzione, il confronto paper è diventato meno lusinghiero e più utile.

Questo è il criterio pratico della parità: ogni differenza significativa tra il comportamento simulato e quello paper ha una causa registrata e il backtest non dichiara certezze che i suoi dati non possono offrire.