Tu backtest encontró una ventaja del 20%. ¿Cuánto se debió a una marca de tiempo incorrecta?

Un backtest arrojó un rendimiento anualizado del 20%. Usó 8 años de datos, 1,640 operaciones y una división walk-forward limpia. Después sustituimos el historial actual del proveedor por los valores registrados en cada momento, y la ventaja cayó al 3%.

La cifra sorprendente no fue el rendimiento original. Fueron los 17 puntos porcentuales que dependían de datos revisados. Ese tipo de sesgo retrospectivo puede esconderse en publicaciones económicas, fundamentales de empresas, composición de índices e incluso en campos de mercado aparentemente sencillos. Los datos históricos te dicen lo que la fuente afirma ahora. Un conjunto de datos point-in-time te dice lo que tu estrategia podría haber sabido entonces.

¿Por qué pueden cambiar los datos históricos después de un evento?

Algunos valores son primero estimaciones y después se corrigen. Una estadística económica publicada un viernes puede revisarse al mes siguiente. Una empresa puede reformular una cifra de beneficios. Un proveedor de datos puede corregir un precio erróneo, completar un intervalo que faltaba o sustituir un valor preliminar por uno definitivo. Una base de datos que solo almacena el valor más reciente hace que todos esos cambios parezcan haber sido siempre ciertos.

Esto importa cuando una estrategia clasifica empresas por ingresos declarados o negocia en un mercado tras una publicación de datos programada. Si ve la cifra corregida meses antes, el backtest le ha dado información que no estaba en el mercado al tomar la decisión. El cálculo de la señal puede ser impecable; aun así, su entrada corresponde a una versión equivocada de la historia.

Hay una trampa fácil: un campo llamado date suele describir el período que abarca un valor, no cuándo estuvo disponible. Puede que una fila de ingresos trimestrales marcada como 31 de marzo no se publicara hasta mayo. La etiqueta se refiere al período de actividad de la empresa, no al conjunto de información de la estrategia.

¿Qué marca de tiempo debe usar un backtest?

Registra por separado el período efectivo del valor y la hora a la que estuvo disponible. Cuando sea posible, conserva también la hora de publicación y la de ingestión. Una estrategia solo podía usar un valor después de que se publicara y el sistema lo recibiera; si esas horas difieren, usa la más tardía para una reproducción conservadora.

Por ejemplo, supongamos que las ventas trimestrales de una empresa abarcan de enero a marzo, se publican el 8 de mayo a las 16:15, hora del Este, y llegan a tu almacén de investigación a las 16:17. Una estrategia que decide al cierre del 8 de mayo no puede usar ese informe si tomó su decisión de cierre a las 16:00. Una estrategia que decide a la mañana siguiente sí puede. La fecha de cierre del trimestre no basta para responder a ninguna de las dos preguntas.

¿Cómo compruebo si las revisiones están impulsando el resultado?

Ejecuta la misma estrategia dos veces: una con la versión de los datos disponible en cada momento histórico de decisión, y otra con el historial revisado más reciente. Mantén fijos los supuestos de ejecución, el universo y el código. La diferencia mide la sensibilidad a las revisiones; no es una comparación entre estrategias distintas.

Después, analiza de dónde viene la brecha. ¿Cambia el rendimiento en los días de publicación? ¿Se concentran las mayores diferencias en unas pocas empresas que reformularon sus cifras o en observaciones corregidas? ¿Opera la estrategia antes de la hora de publicación correspondiente? Una pequeña auditoría a nivel de evento suele explicar más que otro gráfico de rendimientos acumulados.

Esas cifras son un ejemplo, no una penalización universal. Lo útil es obtener un resultado emparejado para tu propia estrategia, con las mismas operaciones y costes siempre que sea posible. Si la versión revisada gana por un margen amplio, averigua qué campos y fechas explican la diferencia antes de confiar en el resultado principal del backtest.

¿Qué debe registrar una auditoría de datos point-in-time?

Empieza por los campos que realmente usa tu estrategia. Para cada uno, identifica la fuente, el significado de la marca de tiempo, la política de revisiones y si es posible recuperar versiones anteriores. Pregunta al proveedor cómo representa las correcciones: filas sobrescritas, filas con nuevas versiones o un registro de auditoría independiente. Que una página de producto diga «histórico» no resuelve la cuestión.

• Guarda cada versión con su marca de tiempo de publicación o de primera disponibilidad.
• Vincula las variables a las decisiones según la hora de disponibilidad, no las etiquetas de período.
• Conserva una instantánea fija o una versión de la fuente para poder reproducir las ejecuciones.
• Marca los valores que llegan tarde, se revisan o carecen de un historial fiable.

Mantén también un alcance práctico. Si tu estrategia solo usa operaciones y velas de un exchange, las revisiones de datos económicos pueden ser irrelevantes. Pero las correcciones de velas y las incorporaciones retroactivas del proveedor aún pueden importar, sobre todo cuando una señal depende de un mercado poco líquido o de una ventana de evento precisa.

Cuando no hay un historial point-in-time disponible

No trates discretamente el valor de hoy como si fuera el de ayer. Marca el campo como una limitación, exclúyelo de las afirmaciones que dependan de su disponibilidad histórica o aplica un retraso conservador y muestra cuánto cambia el resultado. Una aproximación con retraso puede ser útil para la investigación, siempre que el retraso sea explícito y la limitación acompañe al resultado.

La función del backtest es reconstruir una decisión con el conjunto de información que existía en ese momento. Si tus datos solo muestran la versión más reciente, el resultado tiene un límite claro: permite evaluar la estrategia frente al historial reconstruido de hoy, pero no demostrar exactamente qué habría podido ver un agente histórico.