Calendario de resultados y exposición gamma del SPX, fusionados en un solo panel.

Dos superficies. Una decisión de trading.

Una firma de trading cuantitativo lidiaba con una frustración real pero mundana: los datos que necesitaban para tomar una sola decisión estaban en dos herramientas separadas que no tenían ni idea de que la otra existía.

Por un lado, un calendario de resultados. Cuatro grandes fuentes públicas, cada una ligeramente distinta: símbolos distintos, convenciones distintas para la hora de la llamada, duplicados ocasionales, contradicciones ocasionales. El equipo las reconciliaba a mano antes de operar nada.

Por otro lado, la exposición gamma de los dealers del SPX. El indicador de microestructura del mercado de opciones que te dice dónde se concentra la presión de cobertura sistemática: qué strikes se vuelven magnéticos a medida que el mercado se mueve hacia ellos, dónde los dealers comprarán la debilidad y venderán la fortaleza, cuánto colchón tiene el índice antes de que se active la venta mecánica. No hay un campo de Bloomberg para esto. Lo derivas. Fresco, a partir de la cadena de opciones del mercado, con la gamma de Black-Scholes calculada por strike y agregada por ajuste de delta. Y lo haces cada quince minutos durante la sesión de contado, o el número que tienes ya está equivocado.

El encargo fue específico: una pantalla, ambas señales, sincronizadas. Pasa el cursor sobre un evento de resultados. Mira la imagen gamma para esa fecha. Los productos estándar hacen lo uno o lo otro. Nadie hacía ambas cosas en una sola vista.

Una vista fusionada: calendario de eventos arriba, exposición gamma debajo.

El panel dio a los traders de la firma un calendario de resultados que mostraba símbolos de cuatro fuentes de datos independientes —deduplicados, reconciliados, con indicadores de hora de llamada— superpuesto a un gráfico de exposición gamma en vivo para el SPX. Las dos superficies estaban sincronizadas: pasas el cursor sobre una fecha de resultados y el gráfico gamma salta a la imagen de exposición para esa sesión.

El gráfico gamma mostraba la exposición agregada de los dealers por strike, ajustada por delta, con una línea de gamma neta que hacía visible de un vistazo el cambio entre positivo y negativo. La gamma cero —el punto donde la cobertura de los dealers pasa de estabilizar a amplificar— estaba marcada como una constante. La apertura del día y el cierre anterior eran líneas de referencia. Los clústeres de strikes donde se concentraba la exposición aparecían como picos.

El calendario de resultados mostraba eventos confirmados y tentativos con indicadores de hora de llamada (BMO, AMC, sin confirmar). El filtrado a nivel de símbolo, un selector de rango de fechas y una vista de lista de seguimiento permitían a un trader acotar el calendario a su cartera sin tocar la capa gamma. Las dos vistas compartían el mismo eje de fechas. Ese era todo el propósito.

El frontend funcionaba sobre Next.js 16 y React 19, con D3.js encargándose del renderizado de la gamma y Zustand gestionando el estado compartido entre calendario y gráfico. Vercel Analytics se conectó desde la primera semana de producción.

F · 01Calendario de resultados multifuente

Cuatro fuentes independientes deduplicadas por símbolo, fecha y hora de llamada. El manejo de reintento y retroceso por fuente degrada el calendario con elegancia cuando una fuente se rompe: la vista del trader nunca se apaga.

F · 02Gráfico de exposición gamma del SPX en vivo

Gamma de Black-Scholes calculada fresca sobre la cadena completa de opciones del SPX cada quince minutos durante el horario de mercado. Agregada por strike, ajustada por delta. Gamma cero y líneas de referencia clave marcadas.

F · 03Eje de fechas sincronizado

Pasa el cursor sobre un evento de resultados y el gráfico gamma salta a la imagen de exposición para esa sesión. La fusión está en la interacción, no solo en el diseño.

F · 04Almacén caliente solo en Redis

Sin base de datos fría. Ambos pipelines escriben en Redis JSON, indexado por fecha y símbolo. Lecturas del frontend en submilisegundos. El patrón de acceso nunca necesitó nada más.

F · 05Telemetría por fuente

Cada parser de resultados expone su estado de reintento como métrica. Un parser roto aflora en el panel de monitorización en un ciclo de refresco, antes de que nadie que opere con los datos lo note.

F · 06Backend en dos lenguajes

Node/Express para scraping y deduplicación. Python/FastAPI para la capa cuantitativa: scipy.stats, numpy, pandas. Cada lenguaje es dueño del problema que le encaja. Una caché guarda el resultado.

Una caché, dos pipelines, dos lenguajes.

El problema de fusión de datos que había debajo del panel era una decisión de arquitectura con una respuesta clara: dos pipelines independientes, sin que ninguno bloqueara al otro, escribiendo en un único almacén caliente.

El pipeline de resultados corría en Node y Express. Un servicio de scraping extraía de cuatro calendarios públicos independientes cada tres horas. Cada fuente tenía su propio parser —aislado, con manejo de reintento y retroceso para que un fallo transitorio en una fuente no corrompiera las demás—. La deduplicación se ejecutaba por símbolo más fecha más hora de llamada; un símbolo que aparecía en tres fuentes con diferencias menores de formato de fecha se resolvía en un único registro canónico. La telemetría por fuente significaba que un parser roto era visible en el panel de monitorización antes de que un trader notara que algo iba mal.

El pipeline de gamma corría en Python. FastAPI servía la capa cuantitativa: una cadena de opciones del SPX fresca extraída del feed CSV del mercado cada quince minutos durante el horario de mercado, pasada por el cálculo de gamma de Black-Scholes usando scipy.stats y numpy, agregada por strike y ajustada por delta. Python era la herramienta adecuada aquí: scipy.stats, el ecosistema científico de Python y la forma en que el equipo cuantitativo ya razonaba sobre el cálculo. Reescribirlo en TypeScript habría añadido fricción sin ninguna ventaja.

“

Una vez que no había una base de datos fría a la que recurrir, cada pipeline tenía que ser correcto en el momento de escritura. Esa presión produjo parsers más limpios y una historia de guardia más nítida.

”

Ambos pipelines escribían en Redis. Sin base de datos fría: por diseño, no por omisión. La telemetría de las primeras semanas de producción confirmó lo que la arquitectura asumía: el patrón de acceso era siempre «¿qué aspecto tiene la imagen ahora mismo?», nunca «¿qué aspecto tenía hace seis semanas?». Redis JSON, indexado por fecha y símbolo, daba al frontend lecturas en submilisegundos del estado actual. La caché era todo el almacén.

Cuatro años en producción. Sigue refrescándose cada quince minutos.

El panel hizo su primer despliegue en producción en 2022 y ha funcionado de forma continua desde entonces. La arquitectura de dos pipelines ha sobrevivido a tres años de cambios de selectores en las fuentes de resultados, a cambios de formato del feed del mercado en el lado de la gamma y a una reconstrucción completa del frontend cuando aterrizó la migración a React 19.

La cobertura de resultados se sitúa en más de 5.000 símbolos a través de cuatro fuentes independientes. El motor de gamma procesa más de 3.000 strikes del SPX por ciclo de vencimiento. Las cadencias de refresco no han cambiado: resultados cada tres horas, gamma cada quince minutos durante la sesión de contado.

La telemetría de cortacircuitos por fuente ha sido la función más útil operativamente. Los parsers de fuentes se rompen en silencio: un rediseño del calendario o un cambio de API sin previo aviso. La telemetría marca una fuente degradada en un ciclo de refresco. La vista del calendario del trader se degrada con elegancia; no se apaga.

El código base del frontend alcanzó 325 commits a finales de 2024. El backend superó los 541. El motor de gamma, que es el que menos ha cambiado, se sitúa en 59. La proporción es un mapa fiel de dónde estaba realmente el trabajo: no en las matemáticas cuantitativas —eso se estabilizó pronto— sino en el mantenimiento continuo de la capa de datos que hay debajo.