Il bot TRPS (Tail Risk Protection Selling)#

Il bot della TRPS è concettualmente semplice: la strategia della pagina TRPS è già una lista di regole con orari, e il codice non fa che eseguirla. La difficoltà non sta nella logica di trading — un centinaio di righe — ma in tutto ciò che le sta attorno: riconciliazione, gestione degli errori del broker, comportamento nei casi degeneri. La descrivo come la vive il bot: una macchina a stati che attraversa la giornata di New York, dove ogni transizione ha precondizioni esplicite e ogni fallimento ha una destinazione sicura (il Principio 2 della pagina Esecuzione). Gli orari sono nel fuso America/New_York, ovviamente, e il calendario delle festività di borsa è la prima cosa che il bot consulta al risveglio: nei giorni di chiusura non si transita affatto, nelle semifestività (chiusure anticipate) gli orari serali scalano di conseguenza.

Gli stati della giornata#

09:25 — Riconciliazione. Prima di qualunque azione, il bot interroga IBKR: posizioni aperte, ordini vivi, saldo e excess liquidity. Confronta tutto col journal (Principio 4). Il caso normale: in posizione ci sono le put 1DTE vendute ieri sera, che scadono oggi, senza ordini attivi. Ogni altra configurazione — una posizione che il journal non conosce, un ordine orfano, un fill notturno inatteso — porta nello stato HALT: nessuna operatività, notifica immediata, si aspetta l’umano. La riconciliazione controlla anche la salute dell’ambiente: dati di mercato freschi (un prezzo SPX più vecchio di qualche secondo è un sintomo, non un dato), connessione al Gateway, ora di sistema allineata a NTP. È il pre-flight check: due minuti di paranoia che comprano una giornata di serenità.

10:00 — Cambio della guardia. Mezz’ora dopo l’apertura, il bot esegue il passaggio di consegne tra la protezione notturna e quella diurna, con una regola d’ordine precisa: prima cancella, poi trasmette. Cancella la guardia notturna ancora viva sui server (la sezione dedicata, più sotto) e solo dopo trasmette gli ordini stop-limit sulle put in posizione: trigger a multiplo del premio incassato (5-20x, dal file di configurazione), limite 2-4 tick sopra il trigger, validità giornaliera (pagina TRPS: gli stop diurni vivono solo in seduta). Mai due protezioni sovrapposte sulla stessa posizione: uno stop diurno piazzato con una guardia ancora attiva è il modo migliore per chiudere due volte. C’è un’eccezione, ed è deliberata: se la guardia futures è scattata durante la notte, il bot non trasmette nessuno stop automatico — la posizione è già coperta dai futures, e uno stop sopra sarebbe un doppio hedge — ma manda una notifica critica e aspetta la decisione umana. Da questo istante, comunque, vale il Principio 1: le protezioni risiedono sui server di IBKR e il bot potrebbe anche morire — la giornata è già in sicurezza. La mezz’ora di attesa dall’apertura non è pigrizia: i primi trenta minuti di seduta sono i più rumorosi, e uno stop piazzato alle 9:31 rischia di essere colpito dal rimbalzo tecnico invece che dal movimento vero.

Giornata — Monitoraggio passivo. Tra le 10:00 e le 15:30 il bot non decide nulla: osserva. Un ciclo lento (ogni minuto basta e avanza) verifica connessione, posizioni e margine, registra un heartbeat sul journal e manda il ping al dead-man switch esterno. Se uno stop scatta, è IBKR a eseguirlo: il bot se ne accorge dall’evento di fill, aggiorna il journal, mi notifica con i dettagli (prezzo di esecuzione contro trigger: il dato che alimenta la statistica sugli slippage della pagina Tail risk) e — importante — non fa nient’altro. Nessun reingresso, nessun “recupero”: la regola della strategia non prevede riaperture, quindi il bot nemmeno le conosce.

15:30 — Selezione. Qui vive l’unica vera logica di trading. Il bot legge il VIX corrente, calcola la IV target (il multiplo configurato, ~1,5-2,5× VIX), e scandisce la catena delle put SPXW in scadenza domani cercando il primo strike prominente (multipli di 25) il cui premio bid cade nella fascia target (IV ~1,5-2,5× VIX, pagina TRPS). Per il sizing interroga il what-if (pagina Setup): il numero di contratti è il minimo tra quello della leva configurata (nozionale ≤ 3-4× il conto) e quello che il margine stressato consente con il cuscino richiesto. Ogni numero di questa fase — VIX, strike candidato, premio, margine simulato — finisce sul journal prima dell’esecuzione: se qualcosa andrà storto dopo, saprò esattamente che cosa il bot credeva di fare.

15:30-16:15 — La finestra. Dopo la selezione, parte la finestra in cui si vendono le 1DTE di domani (pagina TRPS). L’esecuzione è con ordini limit che partono dal ask e cedono un tick ogni manciata di minuti (pagina TRPS: su 15 centesimi, lo spread è un terzo del lordo). Se allo scadere della finestra restano contratti invenduti, pazienza: si vende quel che si è venduto, il journal registra il miss, e la statistica mi dirà se è un caso o un sintomo.

~16:00 — Il montaggio della guardia. È il quinto appuntamento, il più recente della lista. Appena il fill della vendita è confermato, il bot arma la guardia notturna: uno o più ordini GTC che restano a vegliare sui server di broker ed exchange mentre lui dorme. Il congegno ha un solo grilletto e due possibili reazioni. Il grilletto è un livello di prezzo sul future ES, fissato — in modo regolabile — a metà strada tra il prezzo dell’indice al momento della vendita e lo strike della put: finché ES resta sopra, la notte è tranquilla e non accade nulla; se lo buca, la guardia scatta. La reazione è una scelta di configurazione tra due modalità alternative (o l’una o l’altra, mai insieme): riacquistare la put — chiudere del tutto il rischio — oppure vendere futures per coprirne il delta — ammortizzarlo senza chiudere. Le spiego entrambe nella sezione che segue, perché la guardia è il cambiamento più importante dell’architettura dall’inizio del progetto; qui basta il principio: la protezione notturna nasce prima che il bot vada a dormire e non dipende dal fatto che resti acceso.

16:20 — Chiusura del giorno. Verifica finale posizioni-contro-attese (guardia inclusa: la posizione senza il suo ordine di guardia è un’anomalia da notifica), preparazione degli ordini stop di domani (pronti sul journal, verranno trasmessi mezz’ora dopo l’apertura), scrittura del riepilogo, ping conclusivo, e il bot entra nello stato notturno: dormiente per progetto. La differenza rispetto alla prima versione dell’architettura è tutta qui: il bot dorme come prima, ma le posizioni non passano più la notte con la sola protezione strutturale della leva (pagine Tail risk e TRPS) — c’è una guardia armata sui server, e il bot acceso o spento continua a non cambiare nulla, che è esattamente come deve essere.

La macchina a stati vista come timeline: due appuntamenti critici (il cambio della guardia delle 10:00, la finestra delle 16:00 col montaggio della guardia notturna), un lungo monitoraggio passivo in mezzo, e una notte in cui il bot dorme ma gli ordini di guardia vegliano sui server di broker ed exchange.

La guardia notturna#

Per capire perché esiste, conviene guardare l’orologio. La vendita si riempie verso le 16:00 di New York; lo stop-limit diurno arriva sui server solo mezz’ora dopo l’apertura di domani. In mezzo ci sono circa diciotto ore — dal venerdì al lunedì, un weekend intero — in cui la put è in posizione e nessuno stop la difende, perché gli stop sulle opzioni SPX di notte semplicemente non operano. È la finestra scoperta della pagina TRPS, quella dove vive il gap notturno. Per anni la risposta è stata una sola: la leva, decisa a monte, dimensionata sul disastro. La guardia notturna aggiunge una seconda linea: ordini che vivono sui server di broker ed exchange e scattano mentre il bot — e io — dormiamo. I futures ES, a differenza delle opzioni, quotano quasi 24 ore su Globex (con un unico buco dichiarato: la manutenzione tra le 17:00 e le 18:00 ET), e sono loro a fare da sentinella.

Il trigger. Tutto ruota attorno a un unico livello di prezzo sul future ES, calcolato una volta sola al momento della vendita e valido per l’intera notte. Lo fisso a una frazione della distanza tra il prezzo dell’indice e lo strike venduto, e un esempio rende l’idea: se vendo la put con l’indice a 6.800 e strike a 6.400 — 400 punti di margine — e imposto la frazione a 0,4, il trigger cade a 6.800 − 0,4 × 400 = 6.640. Finché ES resta sopra 6.640 la guardia dorme; appena lo tocca, scatta. La frazione è il parametro che ne decide il carattere: più è alta (verso 0,5) più il trigger resta vicino al prezzo di partenza, quindi la guardia interviene presto e lontano dallo strike — tante false partenze, ma poco danno quando l’allarme è vero; più è bassa (verso 0,2) più il trigger scivola verso lo strike, quindi la guardia ignora gli spaventi passeggeri e agisce solo quando il movimento è serio — meno false partenze, ma intervento più tardivo e più vicino al punto in cui la put comincia davvero a fare male. Lo stesso identico trigger vale per entrambe le modalità: cambia che cosa fa il bot quando scatta, non quando scatta.

Prima modalità: il riacquisto. Al fill della vendita, il bot piazza un ordine di riacquisto GTC sulla stessa put, attivo anche fuori orario regolare, condizionato al livello di trigger sul future ES. Se ES tocca il trigger nella notte, il broker ricompra la put e la storia finisce lì: posizione chiusa, gamma azzerato, niente da gestire al mattino. Il prezzo limite dell’ordine è volutamente brutale — modella quanto l’opzione può valere al trigger con la volatilità stressata a circa il doppio, non quanto varrebbe in una notte educata — perché lo scopo è uscire, non ottimizzare il prezzo. Il costo si paga in due modi: nelle notti davvero cattive si ricompra a un premio gonfiato dall’esplosione della IV (è il costo dell’assicurazione), e in un falso allarme si paga il giro completo di andata e ritorno su un’opzione illiquida di notte. La filosofia: uno stop-loss notturno definitivo. Un’onestà tecnica va detta: la condizione di prezzo è simulata dai server del broker, non è nativa dell’exchange — un gradino di affidabilità sotto uno stop vero.

Seconda modalità: l’hedge futures. L’idea nasce da un’osservazione semplice: di notte il book delle opzioni SPX è un deserto, ma quello dei futures ES è tra i più profondi del pianeta; invece di ricomprare l’opzione dove non c’è liquidità, si vende il future dove ce n’è in abbondanza. Al fill della vendita il bot piazza ordini stop sui futures allo stesso livello di trigger — e questi sono stop nativi del CME, non condizioni simulate. Se il trigger scatta, il bot ha venduto futures per un controvalore pari al delta che la put avrà al trigger (calcolato con volatilità stressata, perché in una notte da trigger la IV non è quella della sera prima), moltiplicato per un fattore di copertura regolabile. La taglia si compone mescolando i due formati: la gamba grossa sul contratto E-mini pieno (più liquido di notte e con costi per nozionale circa un terzo), il resto di precisione sui Micro che valgono un decimo. La put però resta aperta: al trigger la posizione combinata è vicina alla neutralità, ma l’hedge è statico — se la discesa continua, il delta della put corre verso uno e i futures restano quelli. La guardia futures mitiga la coda, non la elimina. E ha i suoi spigoli, che elenco senza sconti: un gap che salta oltre la banda di prezzo dell’ordine (qualche punto ES, il tetto allo slippage accettato) può lasciare lo stop ineseguito; le gambe E-mini e Micro sono ordini indipendenti che possono riempirsi in modo diseguale; i futures eseguiti assorbono margine overnight; e sotto la taglia di un Micro la guardia semplicemente non si monta. La filosofia: un ammortizzatore, non un’uscita.

La scelta tra le due. È un parametro di configurazione, non un dogma, perché nessuna delle due domina l’altra su tutti gli scenari — ed è il motivo per cui il bot le implementa entrambe e mi lascia decidere. La regola che uso è semplice, e ruota attorno a una domanda: quanto è liquido il mercato in cui voglio farmi trovare quando scatta l’allarme? Scelgo il riacquisto quando voglio chiudere il rischio e dormire davvero: paga il prezzo del panico, ma al mattino non lascia nulla da gestire. Funziona finché le posizioni sono piccole e il book delle opzioni, anche in una notte brutta, resta abbastanza spesso da assorbire l’ordine di riacquisto. Passo all’hedge futures quando la size cresce e quel presupposto salta: in un crash notturno vero il book delle opzioni evapora — ricomprare diventa costoso o impossibile — mentre quello dei futures ES regge. L’hedge non chiude la posizione, la trasforma in qualcosa di quasi neutro da smontare alla luce del giorno, ma è l’unica delle due che ha una controparte affidabile proprio quando serve di più. In una riga: riacquisto per le notti cattive ma ordinate; futures per quelle estreme e disordinate, dove pretendere liquidità dalle opzioni è ingenuo e l’unico posto serio dove farsi trovare è il book dei futures.

Il mattino dopo. Se la notte è passata liscia — la stragrande maggioranza — il cambio della guardia delle 10:00 cancella gli ordini notturni e monta lo stop diurno, come descritto sopra. Se il riacquisto è scattato, non c’è più niente da proteggere: si registra, si impara, si riparte la sera. Se l’hedge futures è scattato, il bot si ferma un passo prima dell’automazione totale: notifica critica e decisione umana, perché le due uscite pulite — chiudere put e futures insieme in apertura, o tenere l’hedge fino alla scadenza delle 16:00 accettando gamma e margine — dipendono da come si presenta il mattino, ed è una valutazione che non ho voluto delegare.

La calibrazione, con trasparenza. La frazione di trigger giusta non si indovina a tavolino: si misura. Per questo la guardia ha anche una modalità di solo ascolto, in cui non piazza ordini ma campiona il future ES per tutta la notte e registra il minimo toccato e a quale frazione della distanza strike-fill corrisponde. Ed è la modalità in cui il sistema gira adesso: qualche settimana di notti misurate prima di armare gli ordini, con il percorso previsto che va dal riacquisto verso l’hedge futures. Mi sembra il minimo sindacale di serietà: un sistema che può vendere futures alle tre di notte si guadagna la fiducia una notte misurata alla volta.

Fallire con grazia#

Il valore di un’architettura si misura sui casi brutti, quindi eccoli, dal più frequente al più raro. Il Gateway cade durante la finestra delle 15:30: il bot perde la connessione a metà degli invii; al riavvio (systemd + IBC fanno il loro lavoro in un paio di minuti) la prima azione è sempre la riconciliazione, che scopre quanti contratti sono effettivamente partiti e riprende — o non riprende, se la finestra è chiusa: meglio una sera a metà size che un doppio invio. È il motivo per cui ogni ordine porta un identificativo univoco scritto sul journal prima della trasmissione: l’idempotenza non è un vezzo da ingegneri, è ciò che distingue “riprovo” da “raddoppio”. Fill parziale sullo stop: lo stop-limit esegue una parte e il resto resta appeso oltre il limite; il bot notifica e lascia decidere a me (runbook: di norma, chiusura manuale a mercato della coda — la perdita extra è il premio della pagina TRPS sugli stop-limit). Internet di casa giù alle 15:25: il failover LTE (pagina Setup) dovrebbe coprire; se non copre, la serata salta e le posizioni di ieri sono comunque scadute alle 16:00 — fail-static nella sua forma più pura: il sistema fermo è un sistema senza nuove posizioni, non un sistema in pericolo. Lo scenario più temuto: il gap notturno della pagina Tail risk. Per anni la risposta onesta era “non c’è codice in grado di gestirlo”: oggi c’è la guardia notturna, ma va detto con la stessa onestà che cosa può e non può fare. Può ricomprare la put o vendere futures mentre il mercato scende in modo continuo; non può nulla contro un salto istantaneo che riapre oltre il trigger e oltre la banda — l’ordine condizionato del riacquisto è una simulazione dei server del broker, lo stop futures non esegue oltre il suo limite di prezzo, e l’hedge, quando esegue, è statico. La difesa di ultima istanza resta quella di sempre: la leva, decisa nel file di configurazione molto prima (pagina Ergodicità), ed eventualmente l’umano con i futures ES dal telefono (pagine Futures e Esecuzione) — che oggi è il fallback del fallback, non il piano. L’architettura non protegge dalla coda: protegge la strategia che protegge dalla coda, e la guardia notturna accorcia la lista delle notti in cui questa frase deve fare tutto il lavoro da sola.

Configurazione, test, vita reale#

Una parola sulle notifiche, che viaggiano tutte sul canale di messaggistica della pagina Setup, perché il loro disegno è metà dell’affidabilità percepita del sistema. Tre livelli: il livello info (vendita eseguita, riepilogo serale, ping regolari) arriva come notifica senza suono e resta sul journal; il livello warning (ritentativo per BigMarginChange, fill a prezzo peggiore dell’atteso) genera un messaggio push che posso ignorare per ore; il livello critical (riconciliazione fallita, stato HALT, stop eseguito, dead-man scattato) genera una notifica insistente che richiede un riscontro. E il canale lavora anche all’incontrario: da qualunque punto della giornata posso chiedere lo stato per vedere posizioni e ordini vivi, o impartire l’arresto per fermare la macchina a stati — il bot cancella gli ordini pendenti non protettivi, congela ogni nuova vendita e lascia intatti gli stop sui server del broker. Il caso d’uso reale del kill switch non è il film catastrofico ma la banalità: una notifica che non mi torna, un dubbio sulla configurazione appena cambiata, e preferisco una sera senza premi a una sera col dubbio. La taratura conta più della tecnologia: un sistema che grida per tutto addestra l’operatore a ignorarlo — è l’alert fatigue, e un allarme ignorato è peggio di un allarme assente. La regola che uso: se negli ultimi tre mesi un tipo di notifica non ha mai cambiato il mio comportamento, scende di livello.

Tutti i parametri della pagina TRPS — multiplo di IV, fascia di premio, leva, multiplo di stop — vivono in un file di configurazione versionato: ogni modifica è un commit con data e motivazione, mai un numero ritoccato al volo. È la versione informatica della regola contro l’ottimizzazione strisciante (pagina TRPS): cambiare i parametri resta possibile, ma costa abbastanza attrito da dover essere una decisione. Il collaudo segue la trafila della pagina Esecuzione: mesi di conto paper attraversando almeno un episodio di volatilità vera, con un’attenzione particolare ai giorni strani — semifestività, giornate di roll dei futures, sedute con dati macro alle 8:30 — perché è lì che i bug si nascondono. E una nota finale di umiltà operativa: dopo oltre un anno di esercizio, la quasi totalità degli interventi manuali che ho fatto riguarda l’infrastruttura (Gateway, rete, aggiornamenti), non il trading. Il dipendente junior esegue benissimo; è l’ufficio che ogni tanto perde i pezzi.