A chi serve — A chi deve trasformare un'idea in regole che un'altra persona o un altro programma possano implementare, testare e sorvegliare senza indovinare le intenzioni dell'autore.
La specifica di una strategia sistematica è il documento versionato che descrive la strategia prima della valutazione: scopo, ipotesi, informazioni ammesse, trasformazioni, segnali, posizioni, rischio, ordini, costi, benchmark, controlli e criteri di revisione. È contemporaneamente un contratto di ricerca, un'interfaccia tra ricerca e produzione e una traccia per l'audit.
Una frase come “compra il breakout con volume” non è una specifica. Restano indefiniti universo, calendario, rettifiche, lunghezza della finestra, inclusione della barra corrente, orario di calcolo, primo prezzo eseguibile, size, uscita, gestione dei gap e comportamento quando i dati mancano. Ogni ambiguità permette al backtest di incorporare decisioni retroattive che non sarebbero disponibili in tempo reale.
I blocchi minimi
| Blocco | Contenuto verificabile | Domanda di revisione |
|---|---|---|
| Scopo e uso previsto | decisione supportata, utenti, frequenza e limiti | che cosa non deve fare il sistema? |
| Ipotesi | meccanismo, previsione falsificabile, condizioni di fallimento | quale alternativa spiega lo stesso risultato? |
| Universo | inclusione, esclusione, membership storica e data effettiva | compaiono solo i survivor attuali? |
| Dati | sorgente, campo, timestamp, timezone, lag, revisione e versione | il valore era conoscibile alla decisione? |
| Segnale | formula, finestra, stato, missing e ordine degli eventi | esistono rami non determinati? |
| Portafoglio | mapping segnale-posizione, vincoli, netting e ribilanciamento | quale esposizione domina davvero? |
| Rischio | limiti, scenari, sizing, escalation e fail-safe | cosa succede se un input o un limite fallisce? |
| Esecuzione | tipo ordine, venue, timing, fill, borrow, funding e costi | il prezzo simulato era raggiungibile? |
| Valutazione | benchmark, metriche, split, tentativi e criterio decisionale | il test finale può influenzare la scelta? |
| Monitoraggio | owner, soglie motivate, alert, sospensione e rollback | chi decide e con quali evidenze? |
I campi possono vivere in testo, configurazione e codice, purché siano riconciliabili. Le unità devono essere esplicite: percentuale di capitale, nozionale, volatilità, delta, valuta e frequenza non sono intercambiabili.
L'orologio causale
La specifica deve ordinare almeno quattro istanti:
informazione disponibile → segnale calcolato → ordine inviato → fill possibile“Prezzo di chiusura del giorno” non basta. La chiusura ufficiale può essere nota solo dopo l'asta; un fondamentale può riferirsi a un trimestre ma diventare pubblico settimane dopo; una serie macro può essere revisionata. Se il segnale usa il close e il backtest compra allo stesso close, occorre una meccanica esplicita che renda possibile la partecipazione all'asta con l'informazione necessaria. In assenza di tale meccanica, il primo prezzo successivo è una scelta più coerente, ma anch'essa deve modellare gap e costi.
Per ogni input sono utili almeno tre date: periodo economico di riferimento, pubblicazione iniziale e versione/vintage usata. Per ogni ordine servono stato, timestamp, quantità richiesta, quantità eseguita, prezzo e motivo di rifiuto o cancellazione.
Stati ed eccezioni
Una strategia reale non vive solo nel ramo “segnale presente → ordine eseguito”. La specifica stabilisce che cosa accade quando:
- manca o arriva in ritardo un dato;
- uno strumento è sospeso, delistato o cambia identificativo;
- il contratto future entra nella finestra di roll;
- non è disponibile il prestito titoli oppure il costo supera il limite;
- l'ordine è parzialmente eseguito, rifiutato o resta aperto a fine sessione;
- prezzo, posizione, margine o P&L non si riconciliano;
- il controllo di rischio o la connessione al broker non rispondono.
“Non fare nulla” è una regola valida solo se si specifica lo stato risultante: conservare la posizione precedente, ridurla, liquidarla o bloccare nuovi ordini produce rischi differenti.
Protocollo di ricerca collegato
Prima di osservare il risultato destinato alla decisione, il protocollo registra:
- domanda e ipotesi falsificabile;
- versione della specifica e repository del codice;
- dataset, perimetro temporale e universo;
- baseline e benchmark coerenti;
- metriche primarie e secondarie, lorde e nette;
- disegno in-sample, validation e test finale;
- insieme dei parametri o modelli candidati;
- assunzioni di costo, liquidità e capacità;
- criterio per continuare, modificare o scartare;
- registro di ogni tentativo, compresi risultati negativi.
Un criterio non deve essere necessariamente una singola soglia. Può richiedere coerenza economica, segno stabile su più segmenti, incertezza accettabile, materialità netta e assenza di dipendenza da un punto o da una variante. La scelta va commisurata all'uso: uno strumento esplorativo interno e una strategia che muove capitale hanno conseguenze diverse.
Versioni, riproducibilità e replicazione
Ogni risultato dovrebbe identificare commit o release del codice, file di configurazione, ambiente e dipendenze, seed casuali, versione del dataset e output. Uno snapshot o un hash aiuta a provare che l'input non è cambiato. Rieseguire lo stesso codice sugli stessi dati riguarda la riproducibilità; ottenere evidenza coerente con una realizzazione indipendente riguarda la replicazione. Sono proprietà correlate ma non equivalenti.
Quando un test out-of-sample induce una modifica, nasce una nuova versione. Il segmento consultato non torna incontaminato: va registrato come informazione di sviluppo. Questa genealogia evita che iterazioni successive accumulino data snooping invisibile.
La separazione dei ruoli può aumentare l'efficacia della revisione, ma “indipendente” non significa necessariamente esterno. Significa che chi sfida assunzioni, implementazione e uso dispone di competenza, autorità e incentivi per contestare il risultato.
Esempio illustrativo: un segnale a fine giornata
Una specifica ipotetica dichiara che il segnale usa soltanto dati consolidati
fino alla chiusura di t; viene calcolato dopo la ricezione dei file
finali; gli ordini possono essere inviati non prima dell'apertura di
t+1. L'universo è ricostruito per membership storica; strumenti non
negoziabili generano uno stato di eccezione; la size rispetta limiti di
partecipazione e concentrazione; il costo dipende da spread e quantità.
L'esempio non prescrive che l'open successivo sia sempre corretto. Mostra come rendere controllabile la causalità. Una strategia che partecipa all'asta di chiusura richiederebbe invece segnali calcolabili prima del cutoff e un modello di esecuzione coerente con quell'asta.
Criteri di qualità
- Un implementatore indipendente non deve inventare una regola mancante.
- Ogni variabile ha definizione, unità, timestamp e comportamento sui missing.
- I risultati sono riconducibili a una versione immutabile.
- Le assunzioni di backtest e produzione sono confrontabili riga per riga.
- Le eccezioni conducono a stati sicuri e osservabili.
- I limiti sono collegati a rischio, capacità o uso previsto, non a numeri decorativi.
- Ogni modifica materiale riapre le verifiche interessate.
La specifica non elimina il rischio di modello. Rende però visibili le scelte e permette di distinguere un errore di ricerca da un errore di implementazione o di utilizzo.
Fonti
- Joseph Simonian, CFA Institute Research Foundation, Investment Model Validation: A Guide for Practitioners — scopo, tecniche di validazione, benchmarking, stress e documentazione.
- Federal Reserve, SR 26-2 — Revised Guidance on Model Risk Management — principi correnti di sviluppo, uso, validazione, governance e monitoraggio nel perimetro bancario supervisionato.
- U.S. Securities and Exchange Commission, Staff Report on Algorithmic Trading in U.S. Capital Markets — contesto istituzionale su algoritmi di decisione ed esecuzione e relativi rischi.
- National Futures Association, Interpretive Notice 9025 — Hypothetical Results — limiti dei risultati ipotetici e rilevanza di ipotesi, liquidità, slippage e comportamento; applicazione circoscritta al proprio perimetro.