El error de sincronización más peligroso de un backtest puede pasar inadvertido incluso tras auditar a la perfección las marcas de tiempo. Dos eventos pueden indicar las 10:00:00.000 y, aun así, haber ocurrido en un orden que el simulador tuvo que adivinar.
Esto importa siempre que una estrategia reaccione a algo más que velas cerradas: una actualización de cotización, una operación, un aviso de financiación, un cambio de estado del exchange o la confirmación de una orden propia. Una marca de tiempo indica cuándo se etiqueta un evento. Puede que no indique cuándo tu estrategia pudo actuar en función de él.
¿Qué cambia el orden de los eventos?
Imagina una estrategia que compra cuando el mejor precio de venta cae por debajo de $100.00. En el mismo milisegundo, el feed registra una actualización del precio de venta a $99.99 y una operación a $99.99. Si tu backtest procesa primero la operación y luego la cotización, la estrategia ve el nuevo precio de venta y envía una orden. Procesar primero la cotización también puede ser válido, siempre que el evento ya estuviera disponible. Pero si la operación consumió la liquidez mostrada antes de que llegara la orden, una ejecución a $99.99 es ficticia.
Ordenar las filas solo por marca de tiempo deja que el simulador elija una secuencia para los eventos empatados. El orden del archivo, el orden de los símbolos o el plan de consulta de una base de datos pueden convertirse accidentalmente en reglas de ejecución. La curva de capital puede cambiar aunque los datos subyacentes no hayan cambiado.
Hay una forma clara de ver hasta qué punto puede ser arbitrario: ordenar los eventos con la misma hora por nombre del símbolo, en vez de por secuencia de llegada. Así, una estrategia con varios activos puede comportarse de manera distinta simplemente porque un ticker aparece antes que otro al ordenar.
¿Qué relojes debería conservar un backtest?
Los datos de mercado y la gestión de órdenes suelen implicar varias horas distintas. Conserva los campos que proporcione tu fuente y define sus significados con precisión. En muchos feeds, tanto la marca de tiempo del exchange como la hora de recepción local son útiles; ninguna representa una verdad universal sobre lo que vio cada participante.
| Reloj | Qué registra | Qué no puede demostrar por sí solo |
|---|---|---|
| Hora del evento en el exchange | Cuándo dice el exchange que ocurrió un evento | El orden en que lo observó otro feed o tu proceso |
| Hora de recepción | Cuándo recibió el mensaje tu colector | Cuándo terminó de procesarlo tu estrategia |
| Hora de decisión | Cuándo evaluó el código la señal | Que el precio cotizado siguiera disponible |
| Hora de llegada de la orden | Cuándo pudo actuar el exchange sobre la orden | Una ejecución, salvo que las reglas de casación y la liquidez la permitan |
Si los datos históricos no incluyen horas de recepción, indica qué supones. Un backtest podría procesar los eventos del exchange en secuencia y aplicar un retraso fijo de 5 ms entre la decisión y la llegada de la orden. Eso es un modelo, no un registro histórico recuperado. Si no tienes números de secuencia para los eventos con la misma marca de tiempo del exchange, la regla para desempatar también es una suposición.
¿Cómo modelo los eventos con la misma hora?
Primero, conserva los números de secuencia de la fuente cuando existan. Un número de secuencia establece un orden más sólido dentro de su feed que una marca de tiempo, aunque las secuencias pueden ser independientes entre canales o productos.
Después, define explícitamente la regla de procesamiento del simulador. Para cada evento, decide si puede actualizar la información de la estrategia, cambiar la liquidez disponible, activar una orden o confirmar una orden. Son acciones distintas; reducirlas todas a «procesar fila» es cómo se cuelan ejecuciones imposibles.
- Aplica únicamente la información del mercado que haya llegado antes de la hora de decisión de la estrategia.
- Genera la orden y luego avánzala hasta la hora modelada de llegada al exchange.
- Permite la ejecución solo contra liquidez válida después de la llegada, según las suposiciones de ejecución para ese tipo de orden.
- Registra los datos de entrada, el orden de los eventos y el retraso usado para cada ejecución simulada.
Para una estrategia basada en velas, quizá sea más complejidad de la necesaria. Si la señal usa velas de 1 minuto ya cerradas y las órdenes se ejecutan en la apertura de la vela siguiente con un modelo de costes conservador, es poco probable que el orden submilisegundo cambie la conclusión de la investigación. La clave es ajustar el nivel de detalle temporal a lo que afirma el backtest.
¿Puedo confiar en un backtest sin datos de hora de llegada?
Puedes usarlo, pero deja claros sus límites. Si la estrategia opera despacio y tiene límites de riesgo amplios, unos milisegundos pueden ser irrelevantes. Si reacciona a cotizaciones fugaces, compite por la posición en la cola o depende de una señal de adelanto y retraso entre exchanges, la falta de horas de llegada puede ser determinante para el resultado.
Los críticos tienen razón al decir que la precisión temporal de los eventos puede dar una falsa impresión de exactitud. Los feeds históricos están incompletos, los relojes se desajustan y las marcas de tiempo del exchange no revelan cada salto de red. Un simulador con campos de nanosegundos aún puede basarse en una suposición burda de ejecución.
Así que comprueba la sensibilidad en vez de afirmar que tienes certeza: repite la simulación con reglas plausibles para desempatar eventos y distintos retrasos de órdenes, y compara el número de operaciones, el precio de ejecución y qué señales sobreviven. Si el resultado depende de una secuencia que los datos no permiten establecer, incluye esa dependencia en el informe de investigación. Un backtest puede ser útil aunque su reloj sea imperfecto. Solo tiene que reconocer qué hora conoce realmente.
← Todos los artículos
