Setup (broker, margine, prodotti)#

Questa pagina è la distinta base del sistema: che cosa serve, perché proprio quello, e dove stanno i punti di rottura. La divido in tre strati: il conto presso il broker, l’hardware in casa, e il software che ci gira sopra. Avverto subito: è la pagina che invecchierà più in fretta del sito — modelli e prezzi citati valgono oggi — ma i criteri di scelta restano.

Il conto: broker, margine, prodotti#

Il broker di riferimento per queste strategie è Interactive Brokers, per tre ragioni non negoziabili: è tra i pochi a concedere al retail il portfolio margin e la vendita di opzioni naked su indice; ha un’API documentata e matura su cui costruire; e applica margini e tassi tra i più competitivi del mercato. Il conto va configurato così: tipo IBKR Pro (il piano Lite non ha l’API), regime portfolio margin — che richiede un patrimonio minimo di 110.000 dollari e un questionario di esperienza (pagina Capital efficiency) — e permessi di trading per opzioni al livello che consente le vendite scoperte, più futures e opzioni su futures se vuoi gli ES/MES per coperture (pagine Futures e Il bot DHCS). I prodotti da abilitare: opzioni su indici USA (per le SPX/SPXW) e futures CME. Serve poi l’abbonamento ai dati di mercato in tempo reale: il pacchetto OPRA per le opzioni e i dati CME per i futures — pochi dollari al mese, spesso azzerati dalle commissioni generate, e indispensabili: un bot che decide su dati ritardati di 15 minuti è un bot che vende strike sbagliati. Infine, due accortezze di sicurezza: la lista degli IP fidati per le sessioni API, e soprattutto il conto paper gemello, che IBKR fornisce gratuitamente e che è l’ambiente dove il bot vivrà i suoi primi mesi (pagina Esecuzione).

Una nota sul margine che riprende la pagina Capital efficiency ma in chiave operativa: l’API espone la funzione what-if, che restituisce l’impatto di margine di un ordine prima di inviarlo. Il bot la usa come cancello: nessun ordine parte se il margine post-operazione supera la soglia configurata (io uso una frazione prudente dell’excess liquidity, perché — pagina Capital efficiency — il requisito raddoppia da solo nei giorni cattivi). È il vincolo di leva della pagina Ergodicità trasformato in una riga di codice che non si può dimenticare.

L’hardware: piccolo, dedicato, raggiungibile#

Prima domanda: perché un computer in casa e non un VPS in datacenter? Per strategie low frequency la latenza è irrilevante (Principio 1: gli ordini critici riposano comunque sui server del broker), quindi il VPS non compra velocità; compra affidabilità di alimentazione e rete, e la paga con un canone mensile perpetuo, con la gestione di chiavi e credenziali del conto su una macchina altrui, e con un ambiente che non puoi toccare fisicamente quando qualcosa si incastra davvero. La mia scelta è la macchina domestica dedicata — niente doppi usi, niente browser, solo il bot — con le debolezze di casa (corrente, internet) mitigate una per una. È anche la scelta più economica: l’intero rack che descrivo costa come un anno di VPS decente. Non escludo di passare a un VPS in futuro ma per il momento mi attengo al principio: “non aggiustarlo se non è rotto”.

Il mini PC. Il candidato che ho scelto è il GMKtec NucBox G11, attorno ai 250 euro: processore AMD Ryzen Embedded R2514 (quattro core, otto thread), piattaforma embedded pensata per uso industriale continuo, doppia porta Ethernet da 2,5 Gb e consumi da lampadina. Come processore è roba datata — e va benissimo così: IB Gateway più un processo Python che lavora dieci minuti al giorno occupano una frazione di una macchina del genere, e il requisito vero non è la potenza ma la capacità di stare acceso 24/7 per anni senza drammi. Unico appunto: ha una ventola, quindi una parte mobile che prima o poi potrebbe morire — è il pezzo di ricambio da tenere nel cassetto.

L’alimentazione. Un UPS a monte di mini PC e router, collegato via USB al mini PC con il demone NUT (Network UPS Tools): così il bot sa di essere a batteria, può avvisarmi e, se la carica scende sotto soglia con posizioni aperte, eseguire la procedura di spegnimento pulito dopo aver scritto lo stato sul journal. Nota la coerenza col Principio 2: il blackout con la TRPS in posizione non è un’emergenza — le protezioni, stop diurni o guardia notturna che siano, sono già sui server di broker ed exchange, o le inserisco io da mobile — ma il bot che muore sporco, a metà di una scrittura su database, è il tipo di guasto che costa una mattinata di riconciliazione.

La rete. È il vero single point of failure di tutta la baracca, e merita la spesa maggiore: connessione primaria in fibra più un failover LTE/5G (router con SIM dati che subentra da solo), perché la finestra delle 16:00 non aspetta il tecnico. E una regola di sicurezza non negoziabile: nessuna porta aperta verso internet sul router di casa per non esporre la macchina.

La distinta del rack: doppia uscita verso internet, UPS monitorato via NUT, il canale di messaggistica bidirezionale verso il telefono, e nessuna porta aperta sul router.

Il software: pochi pezzi, ben sorvegliati#

Lo strato software, dal basso: Ubuntu Server stabile, headless, aggiornamenti di sicurezza automatici e nient’altro che si aggiorni da solo. IB Gateway, la versione senza interfaccia della piattaforma IBKR che espone l’API: è il componente più capriccioso dell’intero sistema — sessioni che scadono, riavvii settimanali obbligati, finestre di autenticazione — e per questo va addomesticato con IBC, l’utility che ne gestisce login automatico e riavvii programmati. La regola pratica: il riavvio notturno del Gateway si pianifica in un orario in cui per costruzione non succede nulla (per la TRPS, il primo pomeriggio di New York, lontano sia dall’apertura sia dalla finestra serale). Sopra il Gateway, il bot vero e proprio: Python con la libreria ib_async (l’evoluzione comunitaria della storica ib_insync), che incapsula l’API in un modello a eventi pulito. Lo stato vive in un database SQLite — il journal del Principio 4: ogni intenzione scritta prima dell’ordine, ogni esito dopo, così che a ogni riavvio il bot sappia esattamente dove si era fermato. Il tutto orchestrato da systemd: servizi con riavvio automatico, dipendenze esplicite (il bot parte solo se il Gateway risponde), log centralizzati.

La sorveglianza è a strati, dal più sciocco al più paranoico: il watchdog di systemd che riavvia il processo morto; il controllo interno del bot che verifica la connessione al Gateway e la freschezza dei dati prima di ogni azione; e il dead-man switch esterno — un servizio come healthchecks.io che si aspetta un ping dal bot a ogni passo della giornata e mi manda una notifica se il ping non arriva. Il punto concettuale: la sorveglianza interna non può segnalare la morte di chi la ospita; serve sempre un osservatore fuori dalla macchina.

Il pezzo che lega tutto al telefono è il canale di messaggistica, bidirezionale per progetto. In uscita: ogni operazione eseguita dai bot di trading — ordine inviato, fill ricevuto, stop scattato, roll completato, ribilanciamento MES, transizione di stato, errore — diventa un messaggio sul telefono nell’istante in cui accade, con i numeri che servono per giudicare (strike, premio, prezzo di esecuzione, margine residuo). In entrata: dallo stesso canale impartisco comandi — il comando di stato restituisce posizioni, ordini vivi e ultimo heartbeat; il comando di arresto è il kill switch: ferma la macchina a stati, cancella gli ordini pendenti non protettivi e congela ogni nuova operatività, lasciando intoccati gli stop sui server del broker (spegnere il bot non deve mai significare spegnere le protezioni — è il Principio 1 applicato anche al guinzaglio); e si riparte solo dopo una riconciliazione pulita. L’implementazione è banale (l’API di un servizio di messaggistica più una libreria Python; il processo di messaggistica gira separato dal bot di trading, così sopravvive ai suoi crash e può riferirli), ma due accorgimenti di sicurezza sono obbligatori: il bot risponde solo alla mia utenza — chiunque altro scriva viene ignorato e loggato — e l’insieme dei comandi rispetta l’asimmetria della pagina Esecuzione: dal telefono si può fermare, interrogare, mai aprire posizioni o alzare la size. Il telefono è un freno, non un acceleratore.

Ultima pignoleria che vale oro: l’orologio. NTP attivo, e tutta la pianificazione espressa nel fuso America/New_York, mai in ora locale — il mio paese non osserva l’ora legale, gli Stati Uniti sì, e un bot che vende le 1DTE un’ora dopo la chiusura per due volte l’anno è un bot licenziato.