Abbiamo smontato un backtest di prediction market che acquistava il contratto sbagliato

Un backtest di prediction market può usare un ticker che sembra quello giusto, la cronologia dei prezzi corretta e il contratto sbagliato. È facile non accorgersene: i nomi dei mercati sono brevi, le pagine degli eventi vengono aggiornate e una quota YES sembra sempre un prezzo compreso tra zero e uno.

Prendiamo un mercato ipotetico intitolato “La legge Clean Transit sarà approvata?”. Una strategia acquista YES a 0.42 dopo un segnale di notizie. In seguito, il backtest valuta la posizione 1.00. Prima di fidarmi di questa vincita, voglio sapere esattamente cosa prometteva il contratto: quale legge, cosa significava “approvata”, qual era la scadenza e quale fonte ne avrebbe determinato l’esito.

Il titolo: “La legge Clean Transit sarà approvata?”

Un titolo è una dicitura mostrata a schermo, non un identificativo stabile dello strumento. Due mercati possono avere formulazioni quasi identiche e riferirsi a sessioni legislative, versioni emendate della legge o scadenze diverse. Inoltre, una piattaforma può modificare il titolo per chiarire il mercato senza cambiarne i termini sottostanti.

Perciò, il backtest dovrebbe associare la posizione all’ID immutabile del mercato o del contratto assegnato dalla piattaforma e conservarne il testo completo delle regole con la relativa versione. Se i dati storici contengono solo un titolo e un ticker, non puoi dimostrare che la serie dei prezzi corrisponda al contratto che la strategia intendeva negoziare.

Le regole: cosa significa “approvata”?

Supponiamo che le regole stabiliscano che la legge debba essere approvata da Camera e Senato entro il 30 giugno e poi firmata dal presidente. Un backtest che considera sufficiente l’approvazione da parte di una sola delle camere ha cambiato la scommessa. Lo stesso vale se conteggia una legge con lo stesso nome approvata nella sessione successiva.

Leggi i criteri effettivi di risoluzione come condizioni eseguibili. Registra la scadenza e il fuso orario, l’evento che soddisfa i requisiti, eventuali eccezioni e la fonte di risoluzione indicata. Anche l’ambiguità conta: se le regole della piattaforma non chiariscono uno scenario plausibile, non scegliere tacitamente l’interpretazione che coincide con l’esito storico.

C’è una parte meravigliosamente poco appariscente di questo lavoro: salvare la pagina delle regole prima che accada qualcosa di interessante. Una pagina acquisita solo dopo la risoluzione può mostrare la formulazione finale, mentre la strategia è entrata a mercato quando era in vigore una versione precedente.

La cronologia: quando poteva saperlo la strategia?

Supponiamo ora che le regole siano chiare e che il segnale di notizie sia scattato alle 14:05 UTC. Il feed storico indica un’operazione alle 14:05 al prezzo di 0.42. Quel timestamp, da solo, non dice se l’informazione fosse disponibile prima dell’operazione, se il prezzo registrato fosse ancora eseguibile dopo, né se la barra rappresenti una quotazione, un’operazione o il riepilogo di un intervallo.

Tieni separati l’orario in cui il segnale diventa disponibile e quello dell’evento di mercato. Poi invia l’ordine dopo che la strategia ha avuto il tempo di calcolarlo e trasmetterlo. In un mercato poco liquido, la successiva operazione registrata può arrivare minuti dopo: non dimostra che il tuo ordine sarebbe stato eseguito a quel prezzo.

Il prezzo: una quotazione non è un’esecuzione

Un prezzo YES di 0.42 significa 42 centesimi per quota, ma una serie basata sull’ultima operazione non mostra lo spread né la quantità disponibile. Se la migliore offerta in vendita è 0.45 per 20 quote, un acquisto simulato di 100 quote non può essere eseguito interamente a 0.42. Potrebbe consumare più livelli del book, restare in attesa o non essere eseguito.

I prezzi dei prediction market invitano anche a una scorciatoia contabile: trattare 0.42 come una probabilità del 42% e dimenticare che è anche l’esborso iniziale. Una posizione di 100 quote YES costa $42 prima delle commissioni. Se il contratto si regola a $1, l’incasso lordo è $100; se si regola a $0, è zero. Commissioni, esecuzioni parziali e modalità di regolamento specifiche della piattaforma devono comparire nel registro.

Il regolamento: cosa chiude l’operazione?

Spesso un backtest chiude la posizione al prezzo di mercato finale. Ma un contratto mantenuto fino alla risoluzione paga secondo le regole, e l’ultima quotazione può essere obsoleta, avere uno spread ampio o discostarsi molto dal pagamento finale. Modella la risoluzione come un evento a sé: esito, orario del regolamento e movimento di cassa devono provenire dal registro del contratto.

Considera anche i mercati che si risolvono con un esito non valido o contestato, se le regole della piattaforma lo prevedono. Potrebbero restituire la puntata, pagare un importo diverso o richiedere un’attesa. Un’ipotesi di pagamento binario non può rappresentare tutti i possibili percorsi di risoluzione.

Il verdetto sul backtest

In questo esempio, accetterei la vincita riportata solo dopo aver verificato l’ID immutabile del mercato, la versione delle regole in vigore all’ingresso, il token YES, l’orario in cui il segnale era disponibile, le migliori offerte in vendita e le quantità effettivamente eseguibili, le commissioni e il regolamento registrato. Se l’archivio dei prezzi non consente queste verifiche, il risultato corretto da riportare è un intervallo di scenari oppure un esito non verificato.

Può sembrare un controllo rigoroso per una singola piccola operazione. Ma, ripetuto su migliaia di mercati, lo stesso errore di associazione può trasformare il backtest in una misurazione accurata di contratti che la strategia non ha mai negoziato.