Come creare un trading system, dall’idea all’operatività reale

Per creare un trading system bisogna trasformare un’idea in regole scritte senza margini di interpretazione, codificarle su una piattaforma, verificarle su dati storici che non sono serviti a costruirle e infine portarle sul conto con una dimensione piccola, confrontando i risultati reali con quelli attesi. Il backtest, da solo, è a metà strada. Quasi tutti i sistemi che deludono dal vivo avevano un backtest bello: nessuno aveva controllato se fosse bello per merito o per caso.

Cosa deve dire una regola per diventare un trading system

Un sistema decide tutto quello che di solito si decide a occhio. La prova è semplice: due persone diverse, con le stesse regole e gli stessi dati, devono ottenere esattamente le stesse operazioni. Se una delle due deve «interpretare» una candela, la regola non è pronta.

Le componenti minime sono cinque:

• Mercato e timeframe: su cosa si opera e con quale intervallo di barre (giornaliero, orario, 15 minuti).
• Ingresso: la condizione che apre la posizione, long o short.
• Uscita: stop loss, obiettivo, uscita a tempo o su segnale opposto. Spesso pesa più dell’ingresso.
• Dimensione: quanti contratti per operazione, fissi o legati alla volatilità.
• Filtri: le condizioni che sospendono il sistema, come una volatilità troppo bassa.

Per testarle, le regole vanno scritte in un linguaggio che la piattaforma capisca. Per i futures un linguaggio molto usato è EasyLanguage, nato su TradeStation e letto in forma compatibile da MultiCharts; altri lavorano in Python. La codifica fa già da filtro. «Entro sulla rottura» diventa «entro con un ordine stop un tick sopra il massimo delle ultime 45 sedute», e ogni parola aggiunta è una decisione che prima nessuno aveva preso.

Un backtest ipotetico letto riga per riga

L’esempio è inventato, con numeri arrotondati, e serve solo a leggere un report. Il sistema compra un future su indice quando il prezzo rompe il massimo delle ultime 45 sedute e va short quando rompe il minimo; chiude il long alla rottura del minimo delle ultime 25 sedute, e viceversa. Un contratto per operazione, otto anni di storico, 50 dollari di costi per operazione fra commissioni e slippage, cioè la differenza fra il prezzo previsto e quello di esecuzione.

Il profit factor è la somma delle operazioni in utile divisa per la somma di quelle in perdita: 139.200 / 115.200 = 1,21. Sopra 1 il sistema ha guadagnato. Per ogni dollaro perso ne sono tornati 1,21, e un valore modesto non è un difetto: un profit factor altissimo su centinaia di operazioni merita più sospetto che entusiasmo.

La media per operazione, detta anche expectancy, torna con la percentuale di successo: 0,40 × 1.450 − 0,60 × 800 = 580 − 480 = 100 dollari. Il massimo drawdown è la perdita più ampia da un massimo della curva dei profitti al minimo successivo. Qui supera tre anni di utile medio. Nello storico è capitato una volta. Dal vivo può arrivare al primo mese.

Quanto dimostrano 240 operazioni?

Meno di quanto sembri. Un controllo classico è il test t sulla media: si divide la media per il suo errore standard, cioè la deviazione standard delle operazioni divisa per la radice del loro numero. Con una deviazione standard ipotetica di 1.100 dollari, 1.100 / √240 ≈ 1.100 / 15,5 ≈ 71, e 100 / 71 ≈ 1,4. Per dire che un risultato difficilmente è frutto del caso si cerca di solito un valore intorno a 2. Con la stessa media e la stessa dispersione servirebbero circa 480 operazioni: (2 × 1.100 / 100)² = 484.

Il sistema potrebbe funzionare lo stesso. Il report, da solo, non basta a dirlo.

Commissioni e slippage: quanto margine resta davvero

Molti backtest girano con costi a zero o ottimistici. Nell’esempio la media per operazione prima dei costi è di 150 dollari, e ogni dollaro di costo si toglie da lì. Semplificando, lo si sottrae a ciascuna operazione:

Da 50 a 90 dollari si perde il 40% dell’utile. Basta poco: stop eseguiti durante un movimento veloce, un mercato meno liquido, qualche apertura in gap. I sistemi con molti ingressi e operazioni brevi soffrono di più, perché la loro media per operazione è piccola rispetto ai costi. Una prova sensata è raddoppiare lo slippage stimato e guardare se il sistema regge ancora.

Il picco e l’altopiano: come si riconosce l’overfitting

L’overfitting, o sovra-ottimizzazione, è l’adattamento delle regole al rumore di un certo periodo. Nasce quasi sempre dall’ottimizzazione: si provano molte combinazioni di parametri e si tiene la migliore. Con abbastanza tentativi, qualcosa di bello salta fuori anche da dati casuali.

Nel nostro sistema i parametri sono due, la lunghezza del canale d’ingresso e quella del canale d’uscita. Ingresso da 10 a 100 sedute a passi di 5, uscita da 5 a 50: 19 × 10 = 190 combinazioni, che diventano 380 con o senza un filtro di volatilità. Gli ultimi due anni di dati restano fuori, chiusi, come verifica out-of-sample.

La 65/15 è un picco isolato: spostando un parametro di cinque sedute il risultato crolla, segno che la combinazione ha trovato una coincidenza del passato. La 45/25 rende meno sulla carta ma sta su un altopiano, dove le combinazioni vicine si comportano in modo simile. Fuori campione cede poco. Chi deve scegliere prima di conoscere il futuro ha una sola scelta sensata.

Altre forme di overfitting sono più subdole. Aggiungere un filtro dopo aver visto quali operazioni perdevano. Escludere «l’anno anomalo». Cambiare mercato finché il sistema non funziona. Ogni decisione presa guardando i risultati toglie al test un po’ della sua capacità di dire la verità.

Errori del test che non dipendono dai parametri

• Look-ahead bias: il test usa un’informazione che al momento dell’ordine non esisteva, come calcolare il segnale sulla chiusura ed entrare allo stesso prezzo di chiusura.
• Serie continue dei futures: per avere uno storico lungo si incollano le scadenze successive. Con l’aggiustamento per differenza le variazioni in punti restano corrette, quelle in percentuale no.
• Survivorship bias: sulle azioni, testare solo i titoli oggi presenti in un indice esclude quelli usciti o falliti e gonfia i risultati.

Out-of-sample, walk forward e Monte Carlo

L’out-of-sample è la parte di storico che resta chiusa mentre si costruisce il sistema, e si guarda una volta sola. Se dopo averla vista si ritoccano le regole, anche quei dati diventano in sample e la verifica è bruciata.

Il walk forward ripete l’idea in modo sistematico. Si ottimizza su quattro anni, si applicano i parametri scelti all’anno seguente, si sposta tutto avanti di un anno e si ricomincia. Con dieci anni di dati si ottengono sei anni di risultati «ciechi» in fila, molto più simili a quello che accade dal vivo, dove i parametri si ricalibrano senza conoscere il futuro.

La simulazione Monte Carlo parte da un’osservazione banale: le 240 operazioni sono arrivate in un certo ordine, ma potevano arrivare in un altro. Si rimescola la sequenza migliaia di volte e si registra il drawdown di ogni versione. Nell’esempio ipotetico, su 10.000 rimescolamenti il drawdown supera i 15.000 dollari nel 5% dei casi.

Quel numero cambia il modo di leggere il report. Se il drawdown sopportabile è il 25% del capitale, servono 15.000 / 0,25 = 60.000 dollari per contratto, e i 3.000 dollari medi l’anno diventano il 5% annuo, prima delle tasse. Il sistema che «ha fatto 24.000 dollari» ora ha un’altra faccia. A volte è proprio questo conto, e non il backtest, a far scartare un’idea.

Dal report al conto: incubazione e regole di spegnimento

Superati i test, il sistema non parte a piena dimensione. Prima c’è l’incubazione: qualche mese in simulazione o con la taglia più piccola disponibile, per esempio un contratto micro al posto di quello pieno, quando esiste. Serve a controllare quello che nessun backtest vede.

1. Esecuzione: gli ordini partono quando devono e lo slippage reale è vicino a quello stimato?
2. Coerenza: le operazioni dal vivo coincidono con quelle che il codice genera sugli stessi giorni? Una differenza di solito è un errore nel codice o nei dati.
3. Infrastruttura: cosa succede se la connessione cade, se il computer si riavvia, se arriva il rollover con una posizione aperta.
4. Tenuta: si riesce a lasciar lavorare il sistema durante sette perdite di fila senza metterci mano?

L’automazione completa, con la piattaforma che invia gli ordini da sola, elimina le distrazioni e la tentazione di saltare un segnale. Porta problemi suoi: un server remoto da gestire, controlli quotidiani, ordini doppi se qualcosa si inceppa.

L’ultima regola va scritta prima del primo ordine reale: quando spegnere il sistema. Un criterio diffuso è un drawdown dal vivo che supera il peggiore stimato con il Monte Carlo; nell’esempio, oltre 15.000 dollari il sistema si ferma e torna in laboratorio. Senza una soglia fissata a freddo, ogni drawdown diventa una trattativa con se stessi.

Operare con un trading system invece che a discrezione: pro e contro

Dove approfondire: sei corsi sul trading sistematico

Chi parte da zero con la programmazione può guardare a Quant Trader Academy – Marco Casario, un percorso guidato passo dopo passo: basi di programmazione, configurazione dell’ambiente, creazione, test e validazione di sistemi con strumenti semplici, secondo gli autori anche per chi non è programmatore. Si arriva a un portafoglio di 3 strategie automatiche con codice aperto, seguendo le lezioni ai propri ritmi.

Smart Quant: Da Zero a Live – Quant Trader Academy è un percorso di 12 settimane che va dalle fondamenta di programmazione e trading automatico alla configurazione dell’ambiente su cui far girare le strategie. Comprende analisi dei report, ricerca di strategie, tre indicatori bonus per TradingView e tre strategie: sull’oro e gli altri metalli, sull’S&P 500 e sul forex. L’equity line della strategia sull’oro dal 2006, mostrata dagli autori, è un risultato passato da leggere con i controlli descritti sopra.

Trading Automatico – QTLab è il più vicino ai temi di questa guida: backtesting, robustezza, confronto In Sample e Out Of Sample, T-Test, Monte Carlo Analysis e Walk Forward Analysis. Prevede sessioni live con registrazioni e lo studio di 6 strategie su diversi mercati, a codice aperto in Easy Language, compatibile con TradeStation e MultiCharts. Fa per chi ha già un’idea e vuole capire se regge.

Workshop sul Trading Sistematico – QTLab è il formato più corto: 5 appuntamenti e una decina di giorni di pratica sui futures con una piattaforma messa a disposizione per il periodo. La sua tesi è che trovare qualcosa che ha funzionato in passato sia facile e che serva un metodo per validarlo. Tocca anche l’automazione.

Trading System Academy – Luca Giusti (QTLab) è il percorso più ampio: 11 giornate di formazione in 8 corsi, 6 coaching class all’anno, oltre 200 ore di registrazioni e tutorial sulle piattaforme, dispense e slide. Copre codifica e test, robustezza, portafogli diversificati e azionari, filtri di volatilità e automazione su futures, commodities, azioni e forex; il workshop finale presenta le 18 strategie della «Hall of Fame». Adatto a chi cerca un percorso completo più che un singolo tema.

Easy Language di Luca Giusti riguarda la codifica avanzata: Easy Language orientato agli oggetti, array, cicli nidificati, variabili globali e oggetti come le global dictionary collection, con strategie implementate usando queste istruzioni. Sono 5 appuntamenti registrati di circa 4 ore e presuppongono le basi del linguaggio, trattate nel corso «Do You Speak Easy Language».

Un’avvertenza prima di passare dal report al conto. Il trading su futures, con la leva, può far perdere capitale anche più in fretta di quanto un backtest lasci immaginare. Nessun sistema, per quanto validato, garantisce rendimenti: i test servono a scartare le idee deboli e a misurare il rischio, non a eliminarlo.