Setup (bróker, margen, productos)#
Esta página es la lista de materiales del sistema: qué hace falta, por qué precisamente eso, y dónde están los puntos de rotura. La divido en tres capas: la cuenta en el bróker, el hardware en casa, y el software que corre encima. Aviso de entrada: es la página que envejecerá más deprisa de todo el sitio — los modelos y precios citados valen hoy — pero los criterios de elección permanecen.
La cuenta: bróker, margen, productos#
El bróker de referencia para estas estrategias es Interactive Brokers, por tres razones no negociables: es de los pocos que conceden al retail el portfolio margin y la venta de opciones naked sobre índice; tiene una API documentada y madura sobre la que construir; y aplica márgenes y tipos de los más competitivos del mercado. La cuenta se configura así: tipo IBKR Pro (el plan Lite no tiene API), régimen portfolio margin — que exige un patrimonio mínimo de 110.000 dólares y un cuestionario de experiencia (página Capital efficiency) — y permisos de trading en opciones al nivel que permite las ventas descubiertas, más futuros y opciones sobre futuros si quieres los ES/MES para coberturas (páginas Futures y El bot DHCS). Los productos a habilitar: opciones sobre índices USA (para las SPX/SPXW) y futuros CME. Hace falta además la suscripción a los datos de mercado en tiempo real: el paquete OPRA para las opciones y los datos CME para los futuros — pocos dólares al mes, a menudo compensados por las comisiones generadas, e imprescindibles: un bot que decide sobre datos retrasados 15 minutos es un bot que vende strikes equivocados. Por último, dos precauciones de seguridad: la lista de IP de confianza para las sesiones API, y sobre todo la cuenta paper gemela, que IBKR proporciona gratis y que es el entorno donde el bot vivirá sus primeros meses (página Ejecución).
Una nota sobre el margen que retoma la página Capital efficiency pero en clave operativa: la API expone la función what-if, que devuelve el impacto de margen de una orden antes de enviarla. El bot la usa como puerta de control: ninguna orden sale si el margen posoperación supera el umbral configurado (yo uso una fracción prudente de la excess liquidity, porque — página Capital efficiency — el requisito se duplica por sí solo en los días malos). Es el límite de apalancamiento de la página Ergodicidad convertido en una línea de código que no se puede olvidar.
El hardware: pequeño, dedicado, alcanzable#
Primera pregunta: ¿por qué un ordenador en casa y no un VPS en un centro de datos? Para estrategias low frequency la latencia es irrelevante (Principio 1: las órdenes críticas descansan de todos modos en los servidores del bróker), así que el VPS no compra velocidad; compra fiabilidad de alimentación y de red, y la paga con una cuota mensual perpetua, con la gestión de claves y credenciales de la cuenta en una máquina ajena, y con un entorno que no puedes tocar físicamente cuando algo se atasca de verdad. Mi elección es la máquina doméstica dedicada — nada de usos dobles, nada de navegador, solo el bot — con las debilidades de casa (corriente, internet) mitigadas una por una. Es también la elección más económica: todo el rack que describo cuesta lo que un año de un VPS decente. No descarto pasarme a un VPS en el futuro, pero de momento me atengo al principio: «si no está roto, no lo arregles».
El mini PC. El candidato que elegí es el GMKtec NucBox G11, en torno a los 250 euros: procesador AMD Ryzen Embedded R2514 (cuatro núcleos, ocho hilos), plataforma embedded pensada para uso industrial continuo, doble puerto Ethernet de 2,5 Gb y un consumo de bombilla. Como procesador es cosa anticuada — y así está perfecto: IB Gateway más un proceso Python que trabaja diez minutos al día ocupan una fracción de una máquina así, y el requisito de verdad no es la potencia sino la capacidad de estar encendido 24/7 durante años sin dramas. Único reparo: tiene ventilador, es decir, una pieza móvil que tarde o temprano puede morir — es el recambio que conviene tener en el cajón.
La alimentación. Un UPS aguas arriba del mini PC y del router, conectado por USB al mini PC con el demonio NUT (Network UPS Tools): así el bot sabe que está funcionando con batería, puede avisarme y, si la carga baja del umbral con posiciones abiertas, ejecutar el procedimiento de apagado limpio tras escribir el estado en el journal. Fíjate en la coherencia con el Principio 2: el apagón con la TRPS en posición no es una emergencia — las protecciones, sean los stops diurnos o la guardia nocturna, ya están en los servidores del bróker y del exchange, o las introduzco yo desde el móvil — pero el bot que muere sucio, a mitad de una escritura en la base de datos, es el tipo de avería que cuesta una mañana de reconciliación.
La red. Es el verdadero single point of failure de todo el tinglado, y merece el mayor gasto: conexión primaria de fibra más un failover LTE/5G (router con SIM de datos que entra en acción por sí solo), porque la ventana de las 16:00 no espera al técnico. Y una regla de seguridad no negociable: ningún puerto abierto hacia internet en el router de casa, para no exponer la máquina.
La lista del rack: doble salida hacia internet, UPS monitorizado vía NUT, el canal de mensajería bidireccional hacia el teléfono, y ningún puerto abierto en el router.
El software: pocas piezas, bien vigiladas#
La capa de software, desde abajo: Ubuntu Server estable, headless, actualizaciones de seguridad automáticas y nada más que se actualice solo. IB Gateway, la versión sin interfaz de la plataforma de IBKR que expone la API: es el componente más caprichoso de todo el sistema — sesiones que caducan, reinicios semanales obligados, ventanas de autenticación — y por eso hay que domarlo con IBC, la utilidad que gestiona su login automático y sus reinicios programados. La regla práctica: el reinicio nocturno del Gateway se planifica a una hora en la que por construcción no pasa nada (para la TRPS, la primera hora de la tarde de Nueva York, lejos tanto de la apertura como de la ventana vespertina). Sobre el Gateway, el bot propiamente dicho: Python con la librería ib_async (la evolución comunitaria de la histórica ib_insync), que encapsula la API en un modelo de eventos limpio. El estado vive en una base de datos SQLite — el journal del Principio 4: cada intención escrita antes de la orden, cada resultado después, de modo que en cada reinicio el bot sepa exactamente dónde se había quedado. Todo orquestado por systemd: servicios con reinicio automático, dependencias explícitas (el bot arranca solo si el Gateway responde), logs centralizados.
La vigilancia es por capas, de la más tonta a la más paranoica: el watchdog de systemd que reinicia el proceso muerto; el control interno del bot, que verifica la conexión al Gateway y la frescura de los datos antes de cada acción; y el dead-man switch externo — un servicio como healthchecks.io que espera un ping del bot en cada paso de la jornada y me manda una notificación si el ping no llega. El punto conceptual: la vigilancia interna no puede señalar la muerte de quien la aloja; siempre hace falta un observador fuera de la máquina.
La pieza que lo conecta todo con el teléfono es el canal de mensajería, bidireccional por diseño. De salida: cada operación ejecutada por los bots de trading — orden enviada, fill recibido, stop saltado, roll completado, reequilibrio MES, transición de estado, error — se convierte en un mensaje en el teléfono en el instante en que ocurre, con los números que hacen falta para juzgar (strike, prima, precio de ejecución, margen restante). De entrada: por el mismo canal imparto comandos — el comando de estado devuelve posiciones, órdenes vivas y último heartbeat; el comando de parada es el kill switch: detiene la máquina de estados, cancela las órdenes pendientes no protectoras y congela toda nueva operativa, dejando intactos los stops en los servidores del bróker (apagar el bot no debe significar nunca apagar las protecciones — es el Principio 1 aplicado también a la correa); y solo se reanuda tras una reconciliación limpia. La implementación es trivial (la API de un servicio de mensajería más una librería Python; el proceso de mensajería corre separado del bot de trading, así sobrevive a sus crashes y puede reportarlos), pero dos precauciones de seguridad son obligatorias: el bot responde solo a mi usuario — cualquier otro que escriba es ignorado y queda en el log — y el conjunto de comandos respeta la asimetría de la página Ejecución: desde el teléfono se puede parar, consultar, nunca abrir posiciones ni subir la size. El teléfono es un freno, no un acelerador.
Última quisquillosidad que vale oro: el reloj. NTP activo, y toda la planificación expresada en el huso America/New_York, nunca en hora local — mi país no observa el horario de verano, Estados Unidos sí, y un bot que vende las 1DTE una hora después del cierre dos veces al año es un bot despedido.