Trading sin pantallas

El dolor

El problema no era la estrategia. Era que la estrategia dependía de que él estuviera bien descansado, sin nada que lo distrajera, sin noticias malas recientes. Un mercado que se mueve contra ti a las 3 de la tarde no se siente igual que uno que se mueve a las 9 de la mañana. Eso se notaba en las decisiones.

Sin métricas claras, tampoco había forma de saber si la estrategia era buena o simplemente había tenido suerte. Cada día era una improvisación sobre una base que nadie había validado en serio. La disciplina de operar con reglas fijas dura hasta que el mercado va en tu contra tres días seguidos.

Lo que cambió

Construí un sistema que separa las reglas de las emociones. La estrategia se define una vez, se valida contra años de datos históricos, y luego el sistema la ejecuta. Antes de operar con plata real, corre en paper trading para demostrar que funciona en condiciones actuales de mercado.

Cuando está lista para operar live, el sistema pide aprobación desde el teléfono y manda el reporte diario con lo que hizo y por qué. El trader no necesita mirar ninguna pantalla — el trabajo ya está hecho. Si algo sale mal, hay un log completo de cada decisión.

Recuperó 4 horas diarias. La estrategia opera con gestión de riesgo institucional que él no podía aplicar manualmente.

Arquitectura

La primera trampa fue Interactive Brokers. La API de IB no es REST — es un protocolo propio que requiere tener corriendo la plataforma TWS o IBC en background en el mismo servidor. No se puede simplemente hacer un POST a un endpoint. El sistema mantiene una conexión persistente y maneja reconexiones automáticas cuando IB la corta, que hace cada 24 horas sin excepción.

Para el backtesting usé PostgreSQL con datos OHLCV particionados por año. El problema que aparece rápido es el volumen: años de datos para varios instrumentos pesan. En lugar de migrar a InfluxDB, la solución fue ser más estricto con qué granularidad realmente valida una estrategia. Datos de 1 minuto cubrían el 90% de los casos de uso y la tabla quedó manejable.

La arquitectura separó el engine de backtesting del engine de ejecución live. Comparten la misma interfaz de estrategia, pero por dentro son completamente distintos: el de backtesting simula fills con slippage configurable, el live habla con IB y espera confirmación real. Esta separación fue la que dejó en evidencia que los supuestos del backtesting estaban mal calibrados cuando llegó la hora de operar en vivo.

El bot de Telegram para aprobaciones no fue un capricho de UX. El trader quería poder aprobar o vetar una operación desde cualquier lugar, en tiempo real. Una app nativa habría tardado semanas más. El bot tomó dos días, manda el resumen de la operación propuesta con botones de confirmar o cancelar, y registra la decisión con timestamp.

Stack

Qué aprendimos

La gestión de riesgo fue lo que más subestimé en el diseño inicial. El trader asumía que con stop-loss era suficiente. Después de ver el comportamiento en sesiones volátiles, agregamos límites de exposición diaria, límite de drawdown máximo antes de apagado automático, y un modo de emergencia que cancela todas las posiciones desde el Telegram. Eso no estaba en el scope original y terminó siendo la parte más importante del sistema.

El paper trading de IB simula fills de forma optimista: asume que tu orden se ejecutó al precio pedido, lo que en mercados ilíquidos no ocurre. Cuando fuimos a live, el slippage real era el doble de lo que el paper mostraba. Tuvimos que recalibrar los parámetros de la estrategia para compensar. Ahora el backtesting aplica un factor de slippage pesimista por defecto.

Aprendí a no confiar en el reloj del servidor para el timing de órdenes. PostgreSQL, Python y la API de IB tienen tres definiciones distintas de 'ahora mismo'. Sincronizar con NTP y usar timestamps UTC en todo fue algo que debí haber hecho desde el día uno. Lo corregí después de un bug que tomó dos días encontrar.

Servicios relacionados