El bot TRPS (Tail Risk Protection Selling)#
El bot de la TRPS es conceptualmente sencillo: la estrategia de la página TRPS es ya una lista de reglas con horarios, y el código no hace más que ejecutarla. La dificultad no está en la lógica de trading — un centenar de líneas — sino en todo lo que la rodea: reconciliación, gestión de los errores del bróker, comportamiento en los casos degenerados. La describo como la vive el bot: una máquina de estados que atraviesa la jornada de Nueva York, donde cada transición tiene precondiciones explícitas y cada fallo tiene un destino seguro (el Principio 2 de la página Ejecución). Los horarios están en el huso America/New_York, por supuesto, y el calendario de festivos de bolsa es lo primero que el bot consulta al despertar: en los días de cierre no se transita en absoluto, y en los semifestivos (cierres anticipados) los horarios vespertinos se desplazan en consecuencia.
Los estados de la jornada#
09:25 — Reconciliación. Antes de cualquier acción, el bot interroga a IBKR: posiciones abiertas, órdenes vivas, saldo y excess liquidity. Lo compara todo con el journal (Principio 4). El caso normal: en posición están las put 1DTE vendidas ayer por la tarde, que vencen hoy, sin órdenes activas. Cualquier otra configuración — una posición que el journal no conoce, una orden huérfana, un fill nocturno inesperado — lleva al estado HALT: ninguna operativa, notificación inmediata, se espera al humano. La reconciliación comprueba también la salud del entorno: datos de mercado frescos (un precio del SPX con más de unos segundos de antigüedad es un síntoma, no un dato), conexión al Gateway, hora del sistema alineada con NTP. Es el pre-flight check: dos minutos de paranoia que compran una jornada de serenidad.
10:00 — Cambio de guardia. Media hora después de la apertura, el bot ejecuta el relevo entre la protección nocturna y la diurna, con una regla de orden precisa: primero cancela, luego transmite. Cancela la guardia nocturna todavía viva en los servidores (la sección dedicada, más abajo) y solo después transmite las órdenes stop-limit sobre las put en posición: trigger a un múltiplo de la prima ingresada (5-20x, del fichero de configuración), límite 2-4 ticks por encima del trigger, validez diaria (página TRPS: los stops diurnos viven solo en sesión). Nunca dos protecciones superpuestas sobre la misma posición: un stop diurno colocado con una guardia todavía activa es la mejor manera de cerrar dos veces. Hay una excepción, y es deliberada: si la guardia de futuros ha saltado durante la noche, el bot no transmite ningún stop automático — la posición ya está cubierta por los futuros, y un stop encima sería un doble hedge — sino que manda una notificación crítica y espera la decisión humana. Desde este instante, en todo caso, rige el Principio 1: las protecciones residen en los servidores de IBKR y el bot podría incluso morirse — la jornada ya está asegurada. La media hora de espera desde la apertura no es pereza: los primeros treinta minutos de sesión son los más ruidosos, y un stop colocado a las 9:31 corre el riesgo de que lo golpee el rebote técnico en vez del movimiento de verdad.
Jornada — Monitorización pasiva. Entre las 10:00 y las 15:30 el bot no decide nada: observa. Un ciclo lento (una vez por minuto basta y sobra) verifica conexión, posiciones y margen, registra un heartbeat en el journal y manda el ping al dead-man switch externo. Si un stop salta, es IBKR quien lo ejecuta: el bot se entera por el evento de fill, actualiza el journal, me notifica con los detalles (precio de ejecución contra trigger: el dato que alimenta la estadística de slippage de la página Tail risk) y — importante — no hace nada más. Ningún reingreso, ningún «recuperar»: la regla de la estrategia no contempla reaperturas, así que el bot ni siquiera las conoce.
15:30 — Selección. Aquí vive la única lógica de trading de verdad. El bot lee el VIX actual, calcula la IV objetivo (el múltiplo configurado, ~1,5-2,5× VIX), y recorre la cadena de las put SPXW que vencen mañana buscando el primer strike prominente (múltiplos de 25) cuya prima bid cae en la franja objetivo (IV ~1,5-2,5× VIX, página TRPS). Para el sizing consulta el what-if (página Setup): el número de contratos es el mínimo entre el del apalancamiento configurado (nocional ≤ 3-4× la cuenta) y el que el margen estresado permite con el colchón exigido. Cada número de esta fase — VIX, strike candidato, prima, margen simulado — acaba en el journal antes de la ejecución: si algo sale mal después, sabré exactamente qué creía estar haciendo el bot.
15:30-16:15 — La ventana. Tras la selección, arranca la ventana en la que se venden las 1DTE de mañana (página TRPS). La ejecución es con órdenes limit que parten del ask y ceden un tick cada puñado de minutos (página TRPS: sobre 15 céntimos, el spread es un tercio del bruto). Si al cerrarse la ventana quedan contratos sin vender, paciencia: se vende lo que se ha vendido, el journal registra el miss, y la estadística me dirá si es casualidad o síntoma.
~16:00 — El montaje de la guardia. Es la quinta cita, la más reciente de la lista. En cuanto el fill de la venta queda confirmado, el bot arma la guardia nocturna: una o más órdenes GTC que se quedan velando en los servidores del bróker y del exchange mientras él duerme. El mecanismo tiene un solo gatillo y dos reacciones posibles. El gatillo es un nivel de precio en el futuro ES, fijado — de forma regulable — a medio camino entre el precio del índice en el momento de la venta y el strike de la put: mientras ES se mantenga por encima, la noche es tranquila y no pasa nada; si lo perfora, la guardia salta. La reacción es una elección de configuración entre dos modalidades alternativas (o una o la otra, nunca juntas): recomprar la put — cerrar del todo el riesgo — o vender futuros para cubrir su delta — amortiguarlo sin cerrar. Explico ambas en la sección siguiente, porque la guardia es el cambio más importante de la arquitectura desde el inicio del proyecto; aquí basta el principio: la protección nocturna nace antes de que el bot se vaya a dormir y no depende de que siga encendido.
16:20 — Cierre del día. Verificación final de posiciones contra expectativas (guardia incluida: la posición sin su orden de guardia es una anomalía que merece notificación), preparación de las órdenes stop de mañana (listas en el journal, se transmitirán media hora después de la apertura), escritura del resumen, ping final, y el bot entra en el estado nocturno: dormido por diseño. La diferencia respecto a la primera versión de la arquitectura está toda aquí: el bot duerme como antes, pero las posiciones ya no pasan la noche con la sola protección estructural del apalancamiento (páginas Tail risk y TRPS) — hay una guardia armada en los servidores, y que el bot esté encendido o apagado sigue sin cambiar nada, que es exactamente como debe ser.
La máquina de estados vista como línea de tiempo: dos citas críticas (el cambio de guardia de las 10:00, la ventana de las 16:00 con el montaje de la guardia nocturna), una larga monitorización pasiva en medio, y una noche en la que el bot duerme pero las órdenes de guardia velan en los servidores del bróker y del exchange.
La guardia nocturna#
Para entender por qué existe, conviene mirar el reloj. La venta se llena hacia las 16:00 de Nueva York; el stop-limit diurno llega a los servidores solo media hora después de la apertura de mañana. En medio hay unas dieciocho horas — de viernes a lunes, un fin de semana entero — en las que la put está en posición y ningún stop la defiende, porque los stops sobre las opciones SPX por la noche sencillamente no operan. Es la ventana descubierta de la página TRPS, aquella donde vive el gap nocturno. Durante años la respuesta fue una sola: el apalancamiento, decidido de antemano, dimensionado sobre el desastre. La guardia nocturna añade una segunda línea: órdenes que viven en los servidores del bróker y del exchange y saltan mientras el bot — y yo — dormimos. Los futuros ES, a diferencia de las opciones, cotizan casi 24 horas en Globex (con un único hueco declarado: el mantenimiento entre las 17:00 y las 18:00 ET), y son ellos los que hacen de centinela.
El trigger. Todo gira en torno a un único nivel de precio en el futuro ES, calculado una sola vez en el momento de la venta y válido para toda la noche. Lo fijo en una fracción de la distancia entre el precio del índice y el strike vendido, y un ejemplo lo aclara: si vendo la put con el índice en 6.800 y strike en 6.400 — 400 puntos de margen — y fijo la fracción en 0,4, el trigger cae en 6.800 − 0,4 × 400 = 6.640. Mientras ES se mantenga por encima de 6.640 la guardia duerme; en cuanto lo toca, salta. La fracción es el parámetro que decide su carácter: cuanto más alta (hacia 0,5), más cerca queda el trigger del precio de partida, así que la guardia interviene pronto y lejos del strike — muchas falsas alarmas, pero poco daño cuando la alarma es de verdad; cuanto más baja (hacia 0,2), más se desliza el trigger hacia el strike, así que la guardia ignora los sustos pasajeros y actúa solo cuando el movimiento es serio — menos falsas alarmas, pero intervención más tardía y más cerca del punto donde la put empieza de verdad a hacer daño. El mismo trigger, idéntico, vale para ambas modalidades: cambia qué hace el bot cuando salta, no cuándo salta.
Primera modalidad: la recompra. Al fill de la venta, el bot coloca una orden de recompra GTC sobre la misma put, activa también fuera del horario regular, condicionada al nivel de trigger en el futuro ES. Si ES toca el trigger durante la noche, el bróker recompra la put y ahí acaba la historia: posición cerrada, gamma a cero, nada que gestionar por la mañana. El precio límite de la orden es deliberadamente brutal — modela cuánto puede valer la opción en el trigger con la volatilidad estresada a cerca del doble, no cuánto valdría en una noche educada — porque el objetivo es salir, no optimizar el precio. El coste se paga de dos maneras: en las noches de verdad malas se recompra a una prima inflada por la explosión de la IV (es el coste del seguro), y en una falsa alarma se paga el viaje completo de ida y vuelta sobre una opción ilíquida de noche. La filosofía: un stop-loss nocturno definitivo. Hay una honestidad técnica que decir: la condición de precio la simulan los servidores del bróker, no es nativa del exchange — un escalón de fiabilidad por debajo de un stop de verdad.
Segunda modalidad: el hedge de futuros. La idea nace de una observación sencilla: de noche el book de las opciones SPX es un desierto, pero el de los futuros ES es de los más profundos del planeta; en vez de recomprar la opción donde no hay liquidez, se vende el futuro donde la hay en abundancia. Al fill de la venta el bot coloca órdenes stop sobre los futuros al mismo nivel de trigger — y estos son stops nativos del CME, no condiciones simuladas. Si el trigger salta, el bot ha vendido futuros por un contravalor igual al delta que la put tendrá en el trigger (calculado con volatilidad estresada, porque en una noche de trigger la IV no es la de la tarde anterior), multiplicado por un factor de cobertura regulable. La talla se compone mezclando los dos formatos: la pata gruesa en el contrato E-mini completo (más líquido de noche y con costes por nocional de cerca de un tercio), el resto de precisión en los Micro, que valen una décima parte. La put, sin embargo, sigue abierta: en el trigger la posición combinada está cerca de la neutralidad, pero el hedge es estático — si la caída continúa, el delta de la put corre hacia uno y los futuros se quedan como están. La guardia de futuros mitiga la cola, no la elimina. Y tiene sus aristas, que enumero sin descuentos: un gap que salte más allá de la banda de precio de la orden (unos puntos de ES, el techo de slippage aceptado) puede dejar el stop sin ejecutar; las patas E-mini y Micro son órdenes independientes que pueden llenarse de forma desigual; los futuros ejecutados absorben margen overnight; y por debajo de la talla de un Micro la guardia sencillamente no se monta. La filosofía: un amortiguador, no una salida.
La elección entre las dos. Es un parámetro de configuración, no un dogma, porque ninguna de las dos domina a la otra en todos los escenarios — y es la razón por la que el bot implementa ambas y me deja decidir. La regla que uso es sencilla, y gira en torno a una pregunta: ¿cómo de líquido es el mercado en el que quiero que me encuentren cuando suene la alarma? Elijo la recompra cuando quiero cerrar el riesgo y dormir de verdad: paga el precio del pánico, pero por la mañana no deja nada que gestionar. Funciona mientras las posiciones sean pequeñas y el book de las opciones, incluso en una noche fea, siga siendo lo bastante espeso como para absorber la orden de recompra. Paso al hedge de futuros cuando la size crece y ese supuesto salta por los aires: en un crash nocturno de verdad el book de las opciones se evapora — recomprar se vuelve caro o imposible — mientras que el de los futuros ES aguanta. El hedge no cierra la posición, la transforma en algo casi neutro que se desmonta a la luz del día, pero es la única de las dos que tiene una contraparte fiable justo cuando más falta hace. En una línea: recompra para las noches malas pero ordenadas; futuros para las extremas y desordenadas, donde pretender liquidez de las opciones es ingenuo y el único sitio serio donde dejarse encontrar es el book de los futuros.
La mañana siguiente. Si la noche ha pasado sin sobresaltos — la inmensa mayoría — el cambio de guardia de las 10:00 cancela las órdenes nocturnas y monta el stop diurno, como se describe arriba. Si la recompra ha saltado, ya no queda nada que proteger: se registra, se aprende, se vuelve a empezar por la tarde. Si el hedge de futuros ha saltado, el bot se detiene un paso antes de la automatización total: notificación crítica y decisión humana, porque las dos salidas limpias — cerrar put y futuros juntos en la apertura, o mantener el hedge hasta el vencimiento de las 16:00 aceptando gamma y margen — dependen de cómo se presente la mañana, y es una valoración que no he querido delegar.
La calibración, con transparencia. La fracción de trigger correcta no se adivina sobre el papel: se mide. Por eso la guardia tiene también una modalidad de solo escucha, en la que no coloca órdenes sino que muestrea el futuro ES durante toda la noche y registra el mínimo tocado y a qué fracción de la distancia strike-fill corresponde. Y es la modalidad en la que el sistema gira ahora: unas semanas de noches medidas antes de armar las órdenes, con el recorrido previsto que va de la recompra hacia el hedge de futuros. Me parece el mínimo exigible de seriedad: un sistema que puede vender futuros a las tres de la madrugada se gana la confianza una noche medida cada vez.
Fallar con gracia#
El valor de una arquitectura se mide en los casos feos, así que aquí están, del más frecuente al más raro. El Gateway se cae durante la ventana de las 15:30: el bot pierde la conexión a mitad de los envíos; al reiniciarse (systemd + IBC hacen su trabajo en un par de minutos) la primera acción es siempre la reconciliación, que descubre cuántos contratos han salido realmente y retoma — o no retoma, si la ventana ya está cerrada: mejor una tarde a media size que un doble envío. Es la razón por la que cada orden lleva un identificador único escrito en el journal antes de la transmisión: la idempotencia no es un capricho de ingenieros, es lo que distingue «reintento» de «duplico». Fill parcial en el stop: el stop-limit ejecuta una parte y el resto se queda colgado más allá del límite; el bot notifica y me deja decidir a mí (runbook: por norma, cierre manual a mercado de la cola — la pérdida extra es la prima de la página TRPS sobre los stop-limit). El internet de casa caído a las 15:25: el failover LTE (página Setup) debería cubrirlo; si no cubre, la tarde se pierde y las posiciones de ayer han vencido de todos modos a las 16:00 — fail-static en su forma más pura: el sistema parado es un sistema sin posiciones nuevas, no un sistema en peligro. El escenario más temido: el gap nocturno de la página Tail risk. Durante años la respuesta honesta fue «no hay código capaz de gestionarlo»: hoy existe la guardia nocturna, pero hay que decir con la misma honestidad qué puede y qué no puede hacer. Puede recomprar la put o vender futuros mientras el mercado baja de forma continua; no puede nada contra un salto instantáneo que reabre más allá del trigger y más allá de la banda — la orden condicionada de la recompra es una simulación de los servidores del bróker, el stop de futuros no ejecuta más allá de su límite de precio, y el hedge, cuando ejecuta, es estático. La defensa de última instancia sigue siendo la de siempre: el apalancamiento, decidido en el fichero de configuración mucho antes (página Ergodicidad), y en su caso el humano con los futuros ES desde el teléfono (páginas Futures y Ejecución) — que hoy es el fallback del fallback, no el plan. La arquitectura no protege de la cola: protege la estrategia que protege de la cola, y la guardia nocturna acorta la lista de noches en las que esta frase tiene que hacer todo el trabajo sola.
Configuración, test, vida real#
Una palabra sobre las notificaciones, que viajan todas por el canal de mensajería de la página Setup, porque su diseño es la mitad de la fiabilidad percibida del sistema. Tres niveles: el nivel info (venta ejecutada, resumen vespertino, pings regulares) llega como notificación sin sonido y queda en el journal; el nivel warning (reintento por BigMarginChange, fill a un precio peor del esperado) genera un mensaje push que puedo ignorar durante horas; el nivel critical (reconciliación fallida, estado HALT, stop ejecutado, dead-man saltado) genera una notificación insistente que exige respuesta. Y el canal trabaja también en sentido contrario: desde cualquier punto de la jornada puedo pedir el estado para ver posiciones y órdenes vivas, o dar la orden de parada para detener la máquina de estados — el bot cancela las órdenes pendientes no protectoras, congela toda nueva venta y deja intactos los stops en los servidores del bróker. El caso de uso real del kill switch no es la película catastrófica sino la banalidad: una notificación que no me cuadra, una duda sobre la configuración recién cambiada, y prefiero una tarde sin primas a una tarde con la duda. El ajuste importa más que la tecnología: un sistema que grita por todo entrena al operador para ignorarlo — es la alert fatigue, y una alarma ignorada es peor que una alarma ausente. La regla que uso: si en los últimos tres meses un tipo de notificación no ha cambiado nunca mi comportamiento, baja de nivel.
Todos los parámetros de la página TRPS — múltiplo de IV, franja de prima, apalancamiento, múltiplo de stop — viven en un fichero de configuración versionado: cada modificación es un commit con fecha y motivación, nunca un número retocado al vuelo. Es la versión informática de la regla contra la optimización sigilosa (página TRPS): cambiar los parámetros sigue siendo posible, pero cuesta la fricción suficiente como para tener que ser una decisión. La puesta a punto sigue el proceso de la página Ejecución: meses de cuenta paper atravesando al menos un episodio de volatilidad de verdad, con especial atención a los días raros — semifestivos, jornadas de roll de los futuros, sesiones con datos macro a las 8:30 — porque es ahí donde se esconden los bugs. Y una nota final de humildad operativa: tras más de un año de funcionamiento, la casi totalidad de las intervenciones manuales que he hecho conciernen a la infraestructura (Gateway, red, actualizaciones), no al trading. El empleado júnior ejecuta de maravilla; es la oficina la que de vez en cuando pierde piezas.