El backtest pasó. La estrategia en paper se perdió el 37% de sus órdenes.

Nuestro backtest contó 91 ejecuciones de 100 órdenes enviadas. En paper trading, la misma estrategia obtuvo 63. El tiempo mediano desde la señal hasta la confirmación de recepción de la orden fue de 84 milisegundos, y 12 de las ejecuciones que faltaron en paper eran órdenes limit que el backtest supuso ejecutadas en cuanto el precio las tocó.

Esa brecha de 28 puntos parecía un problema de estrategia hasta que separamos las decisiones sobre órdenes de las decisiones de ejecución. La estrategia eligió prácticamente el mismo lado, tamaño y precio en ambas pruebas. Lo que cambió fue el proceso de ejecución: algunas órdenes llegaron tarde, otras siguieron abiertas y algunas cruzaron un mercado que ya se había movido.

¿Qué significa la paridad de órdenes entre backtest y paper?

La paridad significa que el backtest y el sistema en paper toman decisiones comparables con la misma información disponible y luego tienen en cuenta explícitamente sus distintos modelos de ejecución. No significa que cada ejecución simulada deba coincidir con una ejecución en paper. Las velas históricas no permiten reconstruir la posición en la cola, y un mercado simulado en paper puede usar un modelo de emparejamiento distinto al de un exchange real.

La pregunta útil es más acotada: para cada orden que la estrategia pretendía colocar, ¿puedes explicar qué ocurrió después? El número de operaciones y el retorno final ocultan demasiados detalles. Conserva un registro vinculado para cada decisión, con un ID estable de decisión de estrategia que se mantenga en los eventos de señal, orden, confirmación, cancelación y ejecución.

¿Por qué las órdenes limit tocadas explicaron tantas ejecuciones perdidas?

Nuestro backtest usaba velas de 1 minuto. Si el precio limit quedaba dentro del rango máximo-mínimo de una vela, marcaba la orden como ejecutada. Esa regla responde si el mercado cotizó a ese precio en algún momento del minuto. No responde si nuestra orden ya estaba activa, si ocupaba el primer lugar en la cola o si se negoció suficiente cantidad después de que llegara.

Los registros de paper dejaron al descubierto el problema de tiempos. La estrategia calculó una señal a las 12:03:00.000, pero el evento de datos de mercado llegó al proceso de órdenes 31 milisegundos después. Las comprobaciones de riesgo tardaron otros 22 milisegundos, y el simulador del mercado confirmó la orden 31 milisegundos después. En un movimiento rápido, una vela histórica puede hacer que parezca posible alcanzar un precio, aunque la orden limit llegara después de que el mercado lo hubiera dejado atrás.

Hubo otra complicación: doce órdenes en paper seguían abiertas cuando el backtest ya había avanzado. El simulador aceptaba una solicitud de cancelación como si la orden hubiera desaparecido al instante. En el sistema en paper, la confirmación de cancelación llegó más tarde; tres órdenes se ejecutaron durante ese intervalo. Eso cambió la posición que encontró la siguiente señal.

¿Cómo mido la brecha sin engañarme?

Empieza con un informe sencillo de conciliación agrupado por intención de orden. Mantén visible el denominador. «Tasa de ejecución» puede significar ejecuciones por orden enviada, cantidad ejecutada dividida por la cantidad solicitada o órdenes ejecutadas divididas por las que llegaron al mercado. Cada medida responde a una pregunta distinta.

1. Vincula los eventos mediante un ID de decisión o de orden del cliente, no con una marca de tiempo estimada a posteriori.
2. Compara primero las decisiones: hora de la señal, lado, cantidad solicitada, tipo de orden y precio limit.
3. Para las decisiones coincidentes, compara el retraso hasta la confirmación, los rechazos, el tiempo abierta, la hora de cancelación, la cantidad ejecutada y el precio medio de ejecución ponderado por volumen.
4. Informa las tasas por tipo de orden y condición de mercado. Una tasa de ejecución general del 63% puede ocultar un 90% en órdenes de mercado y un 35% en órdenes limit pasivas.

Mantén las categorías bien diferenciadas. Una orden rechazada no es una orden sin ejecutar; una orden ejecutada parcialmente no equivale a una ejecución completa; y una orden cancelada después de una ejecución parcial ya cambió la posición. Cuenta tanto las órdenes como la cantidad solicitada para que un grupo de órdenes pequeñas no haga que el resultado parezca mejor de lo que es.

¿Qué debería cambiar en el backtest?

Usa una regla de ejecución que se ajuste a la resolución de los datos y al comportamiento previsto de la orden. Con velas, que el precio toque un nivel limit indica que una ejecución es posible, pero no la demuestra. Puedes modelar ejecuciones parciales de forma conservadora, exigir que el precio atraviese el nivel o excluir las órdenes pasivas cuya posición en la cola no se pueda estimar. Cada opción responde a una pregunta distinta; documenta la elegida y compara el resultado con más de una regla plausible.

Modela también el estado de las órdenes. Una orden sigue activa hasta que el sistema recibe un evento terminal, y una solicitud de cancelación no elimina la exposición. Si la estrategia puede enviar una segunda orden mientras la primera está pendiente, el backtest debe representar esa condición de carrera o impedirla por diseño.

Un modelo de ejecución afirma lo que tu orden podría haber conseguido. Dale una regla que puedas explicar y luego contrástala con los registros de paper.

En nuestra brecha de 28 puntos, lo sorprendente no fue que un backtest con velas de 1 minuto sobrestimara las ejecuciones pasivas. Fue que la posición de la estrategia ya había divergido antes de la siguiente decisión porque habíamos omitido los tiempos de cancelación. Cuando corregimos el modelo de estado de las órdenes y dejamos de tratar cada limit tocada como una ejecución, la comparación en paper resultó menos halagüeña y más útil.

Ese es el criterio práctico de paridad: cada diferencia significativa entre el comportamiento simulado y el de paper tiene una causa registrada, y el backtest no afirma tener certeza cuando sus datos no pueden proporcionarla.