Alle 08:00 UTC di un martedì, una venue crypto ha cambiato il tick size di un contratto perpetual di prezzo medio. La nostra strategia di basis non se n’è accorta. Il segnale vedeva ancora lo stesso spread tra spot e futures, i limiti di rischio erano invariati e il backtest continuava a produrre gli stessi risultati.
Il paper trading se n’è accorto. L’adattatore degli ordini ha arrotondato al ribasso un ordine buy limit fino al prezzo consentito più vicino. L’ordine è così finito un tick sotto il livello modellato dal backtest. Il mercato ha toccato il vecchio prezzo, l’ordine simulato è stato eseguito e l’ordine in paper trading è rimasto lì senza essere eseguito. A pranzo, l’inventario della strategia era sbilanciato.
L’incidente sembrava un piccolo errore di arrotondamento. In realtà, era un problema di confine del modello: la strategia conosceva i prezzi, ma il backtest non conosceva la griglia dei prezzi della venue.
Stavamo negoziando un semplice segnale di basis: acquistare spot e vendere un perpetual quando il premio dei futures superava una soglia. Gli ordini erano passivi perché il vantaggio atteso della basis era ridotto. Bastavano pochi tick per determinare se l’ingresso avrebbe generato un guadagno sufficiente a coprire le commissioni e l’uscita successiva.
Che cosa è cambiato con il tick size?
Prima dell’aggiornamento, il perpetual accettava prezzi a incrementi di 0.01. In seguito, nella fascia di prezzo pertinente, accettava incrementi di 0.05. Il segnale calcolava un prezzo obiettivo di vendita pari a 42,318.03, valido secondo la vecchia regola. Con la nuova, quel prezzo non era valido.
L’exchange rifiutava i prezzi non validi, ma il nostro adattatore prevedeva un ripiego: arrotondava al ribasso l’ordine sell a 42,318.00. Anche quel prezzo non era valido. Un secondo ripiego arrotondava ancora, questa volta a 42,318.05, un prezzo valido ma meno aggressivo per chi vende. Non era più possibile vendere al prezzo modellato. Quel percorso di codice era stato scritto per un altro mercato e trasformava silenziosamente un rifiuto in un ordine riprezzato.
Quel singolo ordine sollevava due questioni distinte. Primo: quale prezzo può accettare la venue? Secondo: come deve reagire una strategia quando il prezzo desiderato non rientra nella griglia? Alla prima risponde l’exchange. Alla seconda deve rispondere la strategia o la politica di esecuzione.
| Intento dell’ordine | Regola della griglia | Direzione tipica dell’arrotondamento | Possibile effetto |
|---|---|---|---|
| Buy limit | Il prezzo deve essere un multiplo del tick | Al ribasso, per restare al prezzo limite o sotto | Minore probabilità di esecuzione |
| Sell limit | Il prezzo deve essere un multiplo del tick | Al rialzo, per restare al prezzo limite o sopra | Minore probabilità di esecuzione |
| Limit marketable | Deve rispettare anche i limiti di prezzo | Dipende dal prezzo massimo accettabile | Se incrocia lo spread |
Non esiste una regola di arrotondamento corretta in assoluto. Arrotondare al ribasso un buy preserva il vincolo di prezzo dell’acquirente, ma può ridurre la probabilità di esecuzione. Arrotondare al rialzo può rendere l’ordine marketable, modificando commissioni e impatto. Per il nostro ingresso passivo sulla basis, spostare l’ordine senza segnalarlo era la scelta sbagliata. La strategia aveva scelto un obiettivo; l’adattatore ne aveva cambiato l’economia.
Perché il backtest sembrava ancora solido?
Il nostro simulatore storico degli ordini trattava i prezzi limit come numeri continui. Se il minimo della barra raggiungeva il prezzo buy, o il massimo raggiungeva il prezzo sell, registrava un’esecuzione. È già un’approssimazione generosa per un ordine passivo, perché sapere che il prezzo è stato negoziato al livello limite non dice nulla sulla posizione in coda. Ma l’aggiornamento del tick ha messo in luce un problema ancora più fondamentale: a quel prezzo l’ordine non sarebbe potuto esistere.
Abbiamo riprodotto le stesse decisioni applicando la nuova griglia a partire dalla sua data di efficacia. Diverse esecuzioni sono scomparse. Alcuni ordini sono stati arrotondati a prezzi che incrociavano lo spread e hanno comportato commissioni taker invece di maker. Di conseguenza, il percorso della posizione è diver so, quindi sono cambiati anche gli hedge e le uscite successive. Una regola che sembrava semplice metadato aveva modificato l’intera sequenza di operazioni.
E l’aggiornamento non era una sorpresa nascosta in un grafico. La venue aveva pubblicato una modifica delle regole dello strumento con un timestamp di efficacia. Archiviavamo con cura i dati di mercato, ma i metadati degli strumenti risiedevano in una cache aggiornata all’avvio. Il backtest usava le regole odierne per ogni data storica; il paper trading manteneva regole obsolete fino al riavvio del processo. Nessuno dei due ambienti rappresentava ciò che la venue consentiva in ciascun momento.
Come dovrebbe modellare un backtest i cambiamenti del tick size?
Assegnate alle regole degli strumenti intervalli di validità, come per gli altri input disponibili in un preciso momento storico. Come minimo, conservate l’ora di efficacia e i valori necessari per convalidare un ordine: tick size, incremento della quantità, quantità minima ed eventuali fasce di prezzo. Il simulatore dovrebbe caricare l’insieme di regole disponibile al momento della decisione simulata.
Poi rendete esplicita la gestione degli ordini. Se un prezzo obiettivo non è valido, rifiutatelo, arrotondatelo secondo una politica documentata oppure ricalcolate l’obiettivo sulla griglia. Registrate quale opzione è stata applicata. Un backtest che corregge automaticamente ogni ordine può essere utile per stimare una specifica politica di esecuzione, ma non dovrebbe mascherare quella politica da esecuzione sull’exchange.
Per gli ordini passivi, un prezzo valido secondo il tick è solo la prima condizione per ottenere un’esecuzione. Serve anche un modello che stimi se il mercato ha negoziato oltre il prezzo, la coda davanti all’ordine, le cancellazioni e il livello di commissioni applicabile.
Abbiamo aggiunto due controlli. Il primo applica a ogni ordine generato le regole dello strumento valide in quel momento e segnala chiaramente prezzi o quantità non validi. Il secondo confronta l’ordine finale normalizzato dell’adattatore del backtest con quello del paper trading: lato, prezzo, quantità, validità nel tempo e intento relativo alle commissioni. Se non coincidono, l’esecuzione non è considerata confrontabile.
Poi abbiamo riprodotto il cambio del martedì. Dopo l’aggiornamento della griglia, il backtest non ha più dichiarato esecuzioni a 42,318.03. Paper trading e simulazione hanno preso la stessa decisione per ogni obiettivo non valido, anche quando la decisione era saltare l’ordine.
Il segnale non si era guastato. Erano diventate obsolete le sue ipotesi sull’oggetto negoziabile. Una strategia può sopravvivere a un nuovo tick size, ma solo se il sistema di ricerca considera le regole della venue parte del mercato che sta simulando.
← Tutti gli articoli


