Calendario degli utili ed esposizione gamma sullo SPX, fusi in un unico cruscotto.

Due superfici. Una decisione di trading.

Una società di trading quantitativo lavorava con una frustrazione reale ma banale: i dati di cui avevano bisogno per prendere una singola decisione stavano in due strumenti separati che non avevano idea che l'altro esistesse.

Da un lato, un calendario degli utili. Quattro fonti pubbliche principali, ciascuna leggermente diversa — simboli diversi, convenzioni diverse sull'orario della call, duplicati occasionali, contraddizioni occasionali. Il team le riconciliava a mano prima di negoziare qualsiasi cosa.

Dall'altro lato, l'esposizione gamma dei dealer sullo SPX. L'indicatore di struttura del mercato delle opzioni che ti dice dove si concentra la pressione di hedging sistematico — quali strike diventano magnetici man mano che il mercato si muove verso di essi, dove i dealer compreranno la debolezza e venderanno la forza, quanto cuscinetto ha l'indice prima che scatti la vendita meccanica. Non esiste un campo Bloomberg per questo. Lo si deriva. Fresco, dalla catena delle opzioni della borsa, con la gamma di Black-Scholes calcolata per strike e aggregata per delta-adjustment. E lo fai ogni quindici minuti durante la sessione cash, oppure il numero che hai è già sbagliato.

Il brief era specifico: una schermata, entrambi i segnali, sincronizzati. Passa il mouse su un evento di utili. Vedi il quadro gamma per quella data. I prodotti pronti all'uso fanno l'uno o l'altro. Nessuno faceva entrambi in un'unica vista.

Una vista fusa: calendario degli eventi in alto, esposizione gamma sotto.

Il cruscotto ha dato ai trader della società un calendario degli utili che fa emergere i simboli da quattro fonti dati indipendenti — deduplicati, riconciliati, con indicatori dell'orario della call — sovrapposto a un grafico dell'esposizione gamma in tempo reale per lo SPX. Le due superfici erano sincronizzate: passa il mouse su una data di utili e il grafico gamma scatta al quadro di esposizione per quella sessione.

Il grafico gamma mostrava l'esposizione aggregata dei dealer per strike, delta-adjusted, con una linea di gamma netta che rendeva visibile a colpo d'occhio il passaggio positivo/negativo. Lo zero gamma — il punto in cui l'hedging dei dealer passa da stabilizzante ad amplificante — era segnato come costante. L'apertura giornaliera e la chiusura precedente erano linee di riferimento. I cluster di strike dove l'esposizione si concentrava apparivano come picchi.

Il calendario degli utili mostrava eventi confermati e provvisori con indicatori dell'orario della call (BMO, AMC, non confermato). Filtri a livello di simbolo, un selettore di intervallo di date e una vista watchlist permettevano a un trader di delimitare il calendario al proprio portafoglio senza toccare il livello gamma. Le due viste condividevano lo stesso asse delle date. Era tutto il punto.

Il frontend girava su Next.js 16 e React 19, con D3.js a gestire il rendering della gamma e Zustand a gestire lo stato condiviso calendario/grafico. Vercel Analytics è stato integrato fin dalla prima settimana di produzione.

F · 01Calendario degli utili multi-fonte

Quattro fonti indipendenti deduplicate per simbolo, data e orario della call. La gestione retry-and-backoff per singola fonte degrada il calendario con grazia quando una fonte si rompe — la vista del trader non si oscura mai.

F · 02Grafico dell'esposizione gamma SPX in tempo reale

Gamma di Black-Scholes calcolata fresca sull'intera catena di opzioni SPX ogni quindici minuti durante l'orario di mercato. Aggregata per strike, delta-adjusted. Zero gamma e linee di riferimento chiave segnate.

F · 03Asse delle date sincronizzato

Passa il mouse su un evento di utili e il grafico gamma scatta al quadro di esposizione per quella sessione. La fusione è nell'interazione, non solo nel layout.

F · 04Hot store solo Redis

Nessun database freddo. Entrambe le pipeline scrivono in Redis JSON, indicizzato per data e simbolo. Letture frontend sotto il millisecondo. Lo schema di accesso non ha mai avuto bisogno di altro.

F · 05Telemetria per singola fonte

Ogni parser degli utili espone il proprio stato di retry come metrica. Un parser rotto emerge nel cruscotto di monitoraggio entro un ciclo di aggiornamento — prima che chi negozia sui dati se ne accorga.

F · 06Backend a due linguaggi

Node/Express per lo scraping e la deduplicazione. Python/FastAPI per il livello quant — scipy.stats, numpy, pandas. Ogni linguaggio possiede il problema a cui si adatta. Una sola cache contiene il risultato.

Una cache, due pipeline, due linguaggi.

Il problema di fusione dei dati sotto il cruscotto era una scelta di architettura con una risposta chiara: due pipeline indipendenti, nessuna delle quali blocca l'altra, che scrivono in un unico hot store.

La pipeline degli utili girava in Node ed Express. Un servizio di scraping prelevava da quattro calendari pubblici indipendenti ogni tre ore. Ogni fonte aveva il proprio parser — isolato, con gestione retry-and-backoff in modo che un guasto transitorio su una fonte non corrompesse le altre. La deduplicazione girava per simbolo più data più orario della call; un simbolo che appariva in tre fonti con piccole differenze di formattazione delle date si risolveva in un unico record canonico. La telemetria per singola fonte faceva sì che un parser rotto fosse visibile nel cruscotto di monitoraggio prima che un trader notasse qualcosa di sbagliato.

La pipeline gamma girava in Python. FastAPI serviva il livello quant: una catena di opzioni SPX fresca prelevata dal feed CSV della borsa ogni quindici minuti durante l'orario di mercato, passata attraverso il calcolo della gamma di Black-Scholes usando scipy.stats e numpy, aggregata per strike e delta-adjusted. Python era lo strumento giusto qui — scipy.stats, l'ecosistema scientifico di Python e il modo in cui il team quant già ragionava sul calcolo. Riscriverlo in TypeScript avrebbe aggiunto attrito senza alcun vantaggio.

“

Una volta che non c'era un database freddo su cui ripiegare, ogni pipeline doveva essere corretta al momento della scrittura. Quella pressione ha prodotto parser più puliti e una gestione della reperibilità più netta.

”

Entrambe le pipeline scrivevano in Redis. Nessun database freddo — per scelta, non per omissione. La telemetria delle prime settimane di produzione ha confermato ciò che l'architettura presumeva: lo schema di accesso era sempre «che aspetto ha il quadro in questo momento», mai «che aspetto aveva sei settimane fa». Redis JSON, indicizzato per data e simbolo, dava al frontend letture sotto il millisecondo sullo stato corrente. La cache era l'intero store.

Quattro anni in produzione. Ancora in aggiornamento ogni quindici minuti.

Il cruscotto ha avuto il suo primo deployment in produzione nel 2022 e da allora gira ininterrottamente. L'architettura a due pipeline è sopravvissuta a tre anni di churn dei selettori sulle fonti degli utili, a cambiamenti di formato del feed della borsa sul lato gamma e a una ricostruzione completa del frontend quando è atterrata la migrazione a React 19.

La copertura degli utili si attesta su oltre 5.000 simboli su quattro fonti indipendenti. Il motore gamma elabora oltre 3.000 strike SPX per ciclo di scadenza. Le cadenze di aggiornamento non sono cambiate: utili ogni tre ore, gamma ogni quindici minuti durante la sessione cash.

La telemetria del circuit-breaker per singola fonte è stata la funzionalità più utile dal punto di vista operativo. I parser delle fonti si rompono in silenzio — una riprogettazione del calendario o una modifica dell'API senza preavviso. La telemetria segnala una fonte degradata entro un ciclo di aggiornamento. La vista del calendario del trader degrada con grazia; non si oscura.

Il codice del frontend ha raggiunto 325 commit entro la fine del 2024. Il backend ha superato i 541. Il motore gamma, quello che è cambiato meno, si attesta a 59. Il rapporto è una mappa fedele di dove fosse davvero il lavoro: non nella matematica quant — quella si è assestata presto — ma nella manutenzione continua del livello dati sottostante.