ESECUZIONE#

Nella pagina introduttiva avevo chiuso con una battuta: cosa potrebbe mai andare storto nel far operare un conto trading live da un bot che vende put a margine, scritto con l’AI, su un mini PC domestico cinese headless? Questa sezione è la risposta lunga alla battuta. Quattro pagine in cui scendo dal piano delle strategie a quello dei cavi, dei log e degli ordini che partono alle 16:01 ora di New York mentre io, nel mio fuso sudamericano, sto facendo tutt’altro. È la sezione più personale del sito — descrivo il mio setup, non il setup — e anche la più deperibile: hardware, librerie e API invecchiano più in fretta dei premi al rischio. I principi però no, e sono i principi che voglio fissare prima dei dettagli.

Perché automatizzare (e perché no)#

Parto dall’equivoco da smontare: il bot non serve a guadagnare di più. Le due strategie sono low frequency per costruzione — dieci minuti al giorno la TRPS, un rito serale la DHCS — e nessun millisecondo di latenza in meno aggiunge un centesimo di alpha: l’edge (pagina Edge) è un premio per il rischio detenuto, non per la velocità. Il bot serve a tre cose diverse.

Primo: codificare la disciplina. L’ho scritto alla pagina TRPS: il killer di lungo periodo della TRPS non è il crash, è la tentazione di “ottimizzare” — lo strike un po’ più vicino dopo un mese buono, il contratto in più dopo un trimestre tranquillo. Un bot esegue la regola scritta, identica, la sera del giorno 1 e la sera del giorno 1.000, compresa la sera dopo uno stop mangiato, quando la versione umana di me vorrebbe “recuperare”. L’automazione è l’ergodicità (pagina Ergodicità) applicata alla psicologia: rimuove l’operatore dalla catena delle decisioni ripetitive, che è esattamente il punto in cui l’operatore rompe le strategie.

Secondo: presidiare orari scomodi. La finestra critica della TRPS — i 15 minuti dopo la chiusura del NYSE, il montaggio della guardia notturna subito dopo il fill, il cambio della guardia mezz’ora dopo l’apertura — cade quando cade, festivi americani e impegni miei inclusi. Un processo che deve avvenire 252 volte l’anno a orario fisso è la definizione operativa di “lavoro da macchina”.

Terzo: produrre un archivio. Ogni ordine, ogni fill, ogni rifiuto del broker finisce in un journal su database: è la materia prima del PCR (pagina Misure di rischio), del cruscotto di rischio settimanale e, non ultimo, della dichiarazione fiscale. La versione manuale di questo archivio si chiama “lo faccio nel weekend” e dura tre settimane.

E il perché no, altrettanto onesto: l’automazione converte rischio psicologico in rischio operativo. Il bot non si fa prendere dal panico, ma può crashare alle 16:02 con metà degli ordini inviati; non insegue le perdite, ma esegue alla lettera un bug. La pagina Risk management lo diceva già: il bot è un dipendente junior con accesso al conto — sorveglianza, limiti rigidi, kill switch. Nel mio sistema il guinzaglio ha la forma di un canale di messaggistica bidirezionale (pagina Setup): ogni operazione eseguita dai bot di trading arriva sul telefono in tempo reale, e dal telefono un comando può fermarli all’istante — il dipendente junior lavora con il capo in linea, sempre. Questa sezione è, in larga parte, il manuale di come si sorveglia quel dipendente.

C’è poi un rischio che l’automazione crea dal nulla e che va nominato subito: la sicurezza. Una macchina sempre accesa con una sessione autenticata sul mio conto è un bersaglio, e la superficie d’attacco va ridotta con la stessa serietà con cui si dimensiona la leva. Le regole che seguo: nessuna porta aperta verso internet sul router di casa; l’API del broker vincolata ad accettare connessioni solo dalla macchina locale; le credenziali mai nel codice ma in un archivio cifrato, e comunque un utente API che non può prelevare fondi — la separazione tra “può fare trading” e “può toccare il denaro” è la versione informatica della distinzione tra perdita e rovina della pagina Ergodicità; aggiornamenti di sicurezza automatici e nient’altro di automatico; e la disciplina più banale e più trascurata, l’autenticazione a due fattori su tutto ciò che conta. Un attaccante che entra nel mini PC può al peggio farmi vendere put male per una sera; non deve poter fare di più.

I quattro principi di progettazione#

Tutto il disegno che segue discende da quattro principi. Li enuncio qui perché nelle pagine Il bot TRPS e Il bot DHCS li ritroverai applicati ovunque, e perché valgono qualunque sia il tuo stack.

Principio 1: i server del broker sono parte del sistema. L’intuizione più importante di tutta la sezione: gli ordini stop-limit (pagina TRPS) non vivono sul mini PC — una volta trasmessi, risiedono sui server di IBKR e vengono eseguiti anche se la mia casa è al buio, il router fuso e il bot morto. Il design corretto sfrutta questo fatto fino in fondo: il bot piazza le protezioni per primo, e da quel momento la sua sopravvivenza diventa desiderabile ma non necessaria. La parte critica del sistema gira in un datacenter con ridondanza che non potrei mai permettermi; il mini PC è solo il segretario che consegna le buste.

Principio 2: fail-static, non fail-operational. Non pretendo che il sistema continui a operare durante un guasto (quello costa come un’infrastruttura da hedge fund): pretendo che un guasto lo lasci in uno stato sicuro senza ulteriori azioni. Ed è qui che la scelta delle strategie paga due volte: una TRPS con il bot morto è un insieme di put 1DTE con la loro guardia notturna già sui server di broker ed exchange, che al massimo scadono senza valore il giorno dopo; una DHCS che salta un ribilanciamento accumula un po’ di tracking error, non una catastrofe (pagina Il bot DHCS). Nessuna delle due richiede che il bot sia vivo per essere al sicuro. Confronta con una strategia intraday che deve chiudere le posizioni entro sera: lì un crash del processo è un’emergenza; qui è un fastidio.

Principio 3: l’umano è il backup, e va equipaggiato. Quando il fail-static non basta — il gap notturno con posizioni aperte, l’ordine parzialmente eseguito, il margine che urla — l’ultima linea sono io con l’app mobile di IBKR, che parla direttamente con i server del broker scavalcando l’intera mia infrastruttura domestica. Ma per intervenire bisogna sapere, e qui entra il canale di notifica: ogni fill, ogni rifiuto, ogni cambio di stato mi raggiunge sul telefono nel momento in cui accade, e lo stesso canale accetta comandi nell’altra direzione — interrogare lo stato, o spegnere il bot. Il runbook della pagina Risk management qui diventa letterale: una pagina plastificata con i casi (bot muto da N minuti, posizione orfana, stop eseguito a prezzo assurdo) e le azioni, scritta col mare calmo.

Principio 4: la verità sta dal broker, non nel database. A ogni avvio e a orari fissi, il bot riconcilia: interroga IBKR su posizioni e ordini reali e li confronta col proprio journal. Ogni discrepanza congela l’operatività e mi avvisa — mai, in nessun caso, il bot “corregge” da solo una differenza che non capisce. Il journal è la memoria; il broker è la realtà; quando divergono, decide l’umano.

La gerarchia delle responsabilità: le protezioni vivono dal broker, la routine sul mini PC, e l’umano — equipaggiato — può scavalcare tutto parlando direttamente con i server di IBKR. Questo singolo principio elimina la classe di incidenti più insidiosa dell’automazione retail: il bot convinto di avere posizioni che non ha (o viceversa) che “sistema” le cose raddoppiando il danno.

Che cosa resta manuale#

Non tutto si automatizza, e la linea di confine è concettuale, non tecnica. Si automatizza ciò che è regola: la routine quotidiana della TRPS (selezione strike a premio fisso, invio, stop), il ribilanciamento e il roll della DHCS, la sorveglianza, il journaling. Resta manuale ciò che è giudizio: la gamba tattica delle put lunghe a VIX alto (pagina TRPS), per sua natura discrezionale; la decisione del mattino dopo una notte in cui la guardia futures è scattata — chiudere put e futures insieme o tenere l’hedge fino a scadenza — che il bot segnala con una notifica critica e non prende mai da solo (pagina Il bot TRPS); ogni modifica di leva o di parametri, che passa da un file di configurazione versionato e mai da un’idea delle 23:40; e ogni intervento sulle eccezioni segnalate dalla riconciliazione. La regola che mi sono dato: il bot può solo fare meno di quanto previsto (saltare una vendita se una condizione di sicurezza non è soddisfatta), mai di più. L’asimmetria è voluta: un’occasione persa costa 15 centesimi a contratto; un’iniziativa di troppo può costare il conto.

La mappa della sezione#

La pagina Setup descrive il setup: il conto e i permessi dal lato broker, l’hardware (il mini PC embedded, l’UPS, la rete con failover), il software di base (sistema operativo, IB Gateway e il suo addomesticatore IBC, la libreria API, i servizi di sorveglianza) e una nota su dati di mercato e fiscalità del journal. La pagina Il bot TRPS è l’architettura del bot TRPS: una macchina a stati che vive sul fuso di New York, con la riconciliazione delle 9:25, il cambio della guardia delle 10:00, la finestra di vendita delle 16:00, la guardia notturna nelle sue due varianti — riacquisto condizionato e hedge futures — e i suoi modi di fallire con grazia. La pagina Il bot DHCS è il bot DHCS: più semplice nel ritmo (un solo appuntamento serale), più delicato nella matematica (da dove prendi il delta, quando ribilanci, come arrotondi i Micro), e strutturalmente più tollerante ai guasti — il confronto tra i due è anche un confronto tra filosofie di automazione, e chiude il discorso aperto alla pagina TRPS vs DHCS.

Un’ultima avvertenza, la stessa della pagina Strategie ma al quadrato: tutto ciò che segue si collauda in paper trading per mesi, sul conto simulato che IBKR fornisce apposta, prima che un solo contratto vero parta da uno script. Il paper non testa l’edge — quello è stabilito nelle sezioni Derivati e Strategie — testa te e il tuo codice: i timeout, i fusi, i festivi, gli errori del Gateway alle 16:01. È il periodo di prova del dipendente junior. Comincio dall’ufficio che gli ho costruito attorno.