1. Del backtest al mercado: qué cambia cuando el dinero es real

Nivel 13: Conectar con Brokers Reales

En el Nivel 12 construiste un backtest riguroso: walk-forward, costes de transacción, sin sesgo de anticipación. Ese backtest es una simulación en la que tú controlas absolutamente todo. Tú decides a qué precio se ejecuta cada operación, tú decides que la orden siempre se llena y tú decides que los datos llegan puntuales. En el mercado real no controlas nada de eso.

La diferencia fundamental es esta: un backtest calcula rentabilidades, un sistema en vivo envía órdenes. Son dos problemas de ingeniería distintos. El backtest es un problema de análisis de datos; el sistema en vivo es un problema de sistemas distribuidos, con red, latencia, fallos parciales y estado compartido entre tu máquina y el bróker.

Estas son las cosas nuevas que aparecen en cuanto conectas de verdad:

• Latencia. Entre que tu modelo genera la señal y la orden llega al motor de emparejamiento pasan milisegundos o segundos. El precio puede haberse movido.
• Slippage. El precio al que realmente se ejecuta rara vez es el precio que viste en la pantalla. En el backtest lo estimabas; en vivo lo mides.
• Ejecuciones parciales. Pides 100 acciones y te llenan 40. Tu posición ya no es la que tu código creía.
• Rechazos. Fondos insuficientes, precio fuera de rango, mercado cerrado, límite de peticiones superado. La API te dice que no, y tu programa tiene que saber qué hacer con ese no.
• Riesgo operacional. Se cae tu internet, se cae el proceso, se reinicia el servidor. La posición en el mercado sigue abierta aunque tu programa haya muerto.

De aquí sale la regla más importante de todo este nivel: la fuente de verdad del estado es el bróker, no tu variable local. Si tu código lleva una variable posicion = 100 y el bróker dice que tienes 40, quien tiene razón es el bróker. Un sistema bien diseñado consulta periódicamente el estado real de posiciones y órdenes abiertas, y reconcilia lo que cree con lo que hay. Ese proceso se llama conciliación y no es opcional.

La arquitectura mínima de un sistema en vivo tiene cinco piezas separadas, y conviene que estén separadas de verdad, en módulos distintos:

1. Ingesta de datos: recibir precios, limpiarlos, detectar huecos.

2. Motor de señales: exactamente el mismo código que usaste en el backtest. Si no es el mismo código, estás probando una estrategia y ejecutando otra.

3. Gestor de riesgo: decide si la señal se convierte en orden, con qué tamaño, y tiene poder de veto.

4. Ejecución: traduce la decisión en llamadas a la API, gestiona reintentos y confirmaciones.

5. Estado y conciliación: qué tengo, qué he pedido, qué se ha llenado.

Que el motor de señales sea literalmente el mismo módulo que corriste en el backtest es lo que hace posible comparar después el rendimiento real con el simulado. Si la lógica está duplicada en dos sitios, tarde o temprano divergen y ya nunca sabrás si la diferencia viene del mercado o de un bug.