EJECUCIÓN#

En la página introductoria cerré con una broma: ¿qué podría salir mal si dejo que una cuenta de trading real la opere un bot que vende put con margen, escrito con IA, en un mini PC doméstico chino headless? Esta sección es la respuesta larga a esa broma. Cuatro páginas en las que bajo del plano de las estrategias al de los cables, los logs y las órdenes que salen a las 16:01 hora de Nueva York mientras yo, en mi huso sudamericano, estoy haciendo cualquier otra cosa. Es la sección más personal del sitio — describo mi setup, no el setup — y también la más perecedera: el hardware, las librerías y las API envejecen más deprisa que las primas de riesgo. Los principios, en cambio, no, y son los principios lo que quiero fijar antes de los detalles.

Por qué automatizar (y por qué no)#

Empiezo por el equívoco que hay que desmontar: el bot no sirve para ganar más. Las dos estrategias son low frequency por construcción — diez minutos al día la TRPS, un rito vespertino la DHCS — y ningún milisegundo menos de latencia añade un céntimo de alfa: el edge (página Edge) es una prima por el riesgo mantenido, no por la velocidad. El bot sirve para tres cosas distintas.

Primero: codificar la disciplina. Lo escribí en la página TRPS: el asesino a largo plazo de la TRPS no es el crash, es la tentación de «optimizar» — el strike un poco más cercano tras un mes bueno, el contrato de más tras un trimestre tranquilo. Un bot ejecuta la regla escrita, idéntica, la tarde del día 1 y la tarde del día 1.000, incluida la tarde siguiente a un stop que ha saltado, cuando la versión humana de mí querría «recuperar». La automatización es la ergodicidad (página Ergodicidad) aplicada a la psicología: saca al operador de la cadena de decisiones repetitivas, que es exactamente el punto en el que el operador rompe las estrategias.

Segundo: cubrir horarios incómodos. La ventana crítica de la TRPS — los 15 minutos tras el cierre del NYSE, el montaje de la guardia nocturna justo después del fill, el cambio de guardia media hora después de la apertura — cae cuando cae, festivos americanos y compromisos míos incluidos. Un proceso que debe ocurrir 252 veces al año a hora fija es la definición operativa de «trabajo de máquina».

Tercero: producir un archivo. Cada orden, cada fill, cada rechazo del bróker acaba en un journal sobre base de datos: es la materia prima del PCR (página Medidas de riesgo), del cuadro de mando de riesgo semanal y, no menos importante, de la declaración fiscal. La versión manual de este archivo se llama «lo hago el fin de semana» y dura tres semanas.

Y el porqué no, igual de honesto: la automatización convierte riesgo psicológico en riesgo operativo. El bot no se deja llevar por el pánico, pero puede colgarse a las 16:02 con la mitad de las órdenes enviadas; no persigue las pérdidas, pero ejecuta al pie de la letra un bug. La página Risk management ya lo decía: el bot es un empleado júnior con acceso a la cuenta — vigilancia, límites rígidos, kill switch. En mi sistema la correa tiene la forma de un canal de mensajería bidireccional (página Setup): cada operación ejecutada por los bots de trading llega al teléfono en tiempo real, y desde el teléfono un comando puede detenerlos al instante — el empleado júnior trabaja con el jefe en línea, siempre. Esta sección es, en gran parte, el manual de cómo se vigila a ese empleado.

Hay además un riesgo que la automatización crea de la nada y que conviene nombrar cuanto antes: la seguridad. Una máquina siempre encendida con una sesión autenticada en mi cuenta es un blanco, y la superficie de ataque hay que reducirla con la misma seriedad con la que se dimensiona el apalancamiento. Las reglas que sigo: ningún puerto abierto hacia internet en el router de casa; la API del bróker restringida a aceptar conexiones solo desde la máquina local; las credenciales nunca en el código sino en un almacén cifrado, y en todo caso un usuario API que no puede retirar fondos — la separación entre «puede operar» y «puede tocar el dinero» es la versión informática de la distinción entre pérdida y ruina de la página Ergodicidad; actualizaciones de seguridad automáticas y nada más automático; y la disciplina más banal y más descuidada, la autenticación de dos factores en todo lo que importa. Un atacante que entre en el mini PC puede, como mucho, hacerme vender put mal una tarde; no debe poder hacer nada más.

Los cuatro principios de diseño#

Todo el diseño que sigue se deriva de cuatro principios. Los enuncio aquí porque en las páginas El bot TRPS y El bot DHCS los encontrarás aplicados por todas partes, y porque valen sea cual sea tu stack.

Principio 1: los servidores del bróker son parte del sistema. La intuición más importante de toda la sección: las órdenes stop-limit (página TRPS) no viven en el mini PC — una vez transmitidas, residen en los servidores de IBKR y se ejecutan aunque mi casa esté a oscuras, el router fundido y el bot muerto. El diseño correcto explota este hecho hasta el final: el bot coloca las protecciones primero, y desde ese momento su supervivencia pasa a ser deseable pero no necesaria. La parte crítica del sistema corre en un centro de datos con una redundancia que yo jamás podría permitirme; el mini PC es solo el secretario que entrega los sobres.

Principio 2: fail-static, no fail-operational. No pretendo que el sistema siga operando durante una avería (eso cuesta lo que una infraestructura de hedge fund): pretendo que una avería lo deje en un estado seguro sin más acciones. Y aquí es donde la elección de las estrategias paga dos veces: una TRPS con el bot muerto es un conjunto de put 1DTE con su guardia nocturna ya en los servidores del bróker y del exchange, que como mucho expiran sin valor al día siguiente; una DHCS que se salta un reequilibrio acumula un poco de tracking error, no una catástrofe (página El bot DHCS). Ninguna de las dos necesita que el bot esté vivo para estar a salvo. Compáralo con una estrategia intradía que debe cerrar las posiciones antes del final de la sesión: allí un crash del proceso es una emergencia; aquí es una molestia.

Principio 3: el humano es el backup, y hay que equiparlo. Cuando el fail-static no basta — el gap nocturno con posiciones abiertas, la orden parcialmente ejecutada, el margen que grita — la última línea soy yo con la app móvil de IBKR, que habla directamente con los servidores del bróker saltándose toda mi infraestructura doméstica. Pero para intervenir hay que saber, y aquí entra el canal de notificación: cada fill, cada rechazo, cada cambio de estado me alcanza en el teléfono en el momento en que ocurre, y el mismo canal acepta comandos en la otra dirección — consultar el estado, o apagar el bot. El runbook de la página Risk management aquí se vuelve literal: una página plastificada con los casos (bot mudo desde hace N minutos, posición huérfana, stop ejecutado a un precio absurdo) y las acciones, escrita con la mar en calma.

Principio 4: la verdad está en el bróker, no en la base de datos. En cada arranque y a horas fijas, el bot reconcilia: interroga a IBKR sobre posiciones y órdenes reales y las compara con su propio journal. Cualquier discrepancia congela la operativa y me avisa — nunca, en ningún caso, el bot «corrige» por su cuenta una diferencia que no entiende. El journal es la memoria; el bróker es la realidad; cuando divergen, decide el humano.

La jerarquía de responsabilidades: las protecciones viven en el bróker, la rutina en el mini PC, y el humano — equipado — puede saltárselo todo hablando directamente con los servidores de IBKR. Este único principio elimina la clase de incidentes más insidiosa de la automatización retail: el bot convencido de tener posiciones que no tiene (o al revés) que «arregla» las cosas duplicando el daño.

Qué queda manual#

No todo se automatiza, y la línea divisoria es conceptual, no técnica. Se automatiza lo que es regla: la rutina diaria de la TRPS (selección del strike a prima fija, envío, stop), el reequilibrio y el roll de la DHCS, la vigilancia, el journal. Queda manual lo que es juicio: la pata táctica de las put largas con VIX alto (página TRPS), discrecional por naturaleza; la decisión de la mañana siguiente a una noche en la que la guardia de futuros ha saltado — cerrar put y futuros juntos o mantener el hedge hasta el vencimiento — que el bot señala con una notificación crítica y no toma nunca por su cuenta (página El bot TRPS); toda modificación de apalancamiento o de parámetros, que pasa por un fichero de configuración versionado y nunca por una idea de las 23:40; y toda intervención sobre las excepciones señaladas por la reconciliación. La regla que me he dado: el bot solo puede hacer menos de lo previsto (saltarse una venta si una condición de seguridad no se cumple), nunca más. La asimetría es deliberada: una ocasión perdida cuesta 15 céntimos por contrato; una iniciativa de más puede costar la cuenta.

El mapa de la sección#

La página Setup describe el setup: la cuenta y los permisos del lado del bróker, el hardware (el mini PC embedded, el UPS, la red con failover), el software de base (sistema operativo, IB Gateway y su domador IBC, la librería API, los servicios de vigilancia) y una nota sobre datos de mercado y fiscalidad del journal. La página El bot TRPS es la arquitectura del bot TRPS: una máquina de estados que vive en el huso de Nueva York, con la reconciliación de las 9:25, el cambio de guardia de las 10:00, la ventana de venta de las 16:00, la guardia nocturna en sus dos variantes — recompra condicionada y hedge de futuros — y sus maneras de fallar con gracia. La página El bot DHCS es el bot DHCS: más sencillo en el ritmo (una sola cita vespertina), más delicado en la matemática (de dónde sacas el delta, cuándo reequilibras, cómo redondeas los Micro), y estructuralmente más tolerante a las averías — la comparación entre los dos es también una comparación entre filosofías de automatización, y cierra la conversación abierta en la página TRPS vs DHCS.

Una última advertencia, la misma de la página Estrategias pero al cuadrado: todo lo que sigue se prueba en paper trading durante meses, en la cuenta simulada que IBKR proporciona precisamente para eso, antes de que un solo contrato real salga de un script. El paper no testa el edge — ese quedó establecido en las secciones Derivados y Estrategias — te testa a ti y a tu código: los timeouts, los husos, los festivos, los errores del Gateway a las 16:01. Es el periodo de prueba del empleado júnior. Empiezo por la oficina que le he construido alrededor.