¿Por qué mi backtest sigue reemplazando sus datos de opciones?

Un backtest de opciones puede cambiar aunque no se toque ni una línea del código de la estrategia. Un proveedor corrige una cotización errónea, añade una operación tardía, revisa los metadatos de un contrato o cambia el filtro para mercados cruzados. Vuelves a ejecutar las mismas fechas y obtienes una ejecución distinta, una posición distinta y quizá un Sharpe distinto. Eso no significa necesariamente que la estrategia tenga un error. Significa que cambió la evidencia con la que se puso a prueba.

Para que un backtest de opciones sea reproducible, trata los datos de mercado como una entrada con versiones. Registra qué instantánea usaste, conserva las observaciones sin procesar que determinaron cada decisión y compara los resultados que cambiaron a nivel de contrato y marca de tiempo antes de confiar en el nuevo agregado.

¿Por qué cambió mi backtest de opciones si el código no cambió?

Los registros de opciones son especialmente sensibles a las correcciones porque la posibilidad aparente de negociar un contrato depende de varios campos que cambian en conjunto: bid, ask, tamaños, precio del subyacente, vencimiento, strike y multiplicador o activo entregable del contrato. Una cotización corregida puede convertir una oportunidad aparente en un mercado cruzado. Una corrección de metadatos puede cambiar el significado del multiplicador de una posición.

Imagina una estrategia que compra una call cuando el ask está por debajo de $2.00. En la primera carga de datos, la cotización de las 10:14 tiene un ask de $1.95, un bid de $1.90 y tamaño 5. Una revisión posterior del proveedor cambia el ask a $2.05 tras conciliar un mensaje tardío de la bolsa. Una observación basta para invertir la señal. Si ese contrato fue la única operación de la estrategia ese día, una corrección de datos modesta puede dominar el rendimiento diario.

El filtrado de cotizaciones también importa. Los proveedores pueden descartar cotizaciones obsoletas, eliminar mercados cruzados o normalizar las marcas de tiempo de otra manera. Esas políticas pueden tener sentido, pero forman parte de la identidad del conjunto de datos. “Opciones de SPY, de enero a marzo” no define un historial reproducible.

¿Qué es una versión de los datos de opciones?

Una versión de los datos es la versión exacta de las observaciones históricas disponible para una ejecución de investigación concreta. Guarda el proveedor y el nombre del conjunto de datos, la hora de recuperación, el rango de fechas, la versión del esquema y las reglas de limpieza o filtrado. Si el proveedor ofrece identificadores de instantánea o marcas de tiempo de revisión, guárdalos también.

Para cada decisión simulada, conserva suficiente trazabilidad para responder: qué contrato se evaluó, qué cotización se seleccionó, cuándo se publicó o recibió esa cotización y qué regla la hizo válida. Tanto el registro sin procesar como el derivado son importantes. Un NBBO depurado sin las marcas de tiempo de origen puede ocultar si una cotización estaba obsoleta o llegó después de la decisión simulada.

¿Cómo compruebo si una revisión del proveedor cambió mis resultados?

Ejecuta la misma estrategia y configuración con ambas instantáneas. Primero compara el número de observaciones y contratos válidos por fecha. Después compara las decisiones y las ejecuciones: qué señales aparecieron o desaparecieron, qué cotización cambió y si el nuevo registro modificó el precio de ejecución modelado.

No te limites al rendimiento total. Haz seguimiento de los cambios en el número de operaciones, los precios de entrada y salida, las señales rechazadas y la proporción de P&L procedente de operaciones que aparecen en una sola versión. Una ejecución puede mantener un Sharpe parecido aunque se estén reemplazando operaciones individuales; la estadística principal no te dirá que el historial subyacente cambió.

Para que la auditoría sea útil, mantén fijos la estrategia, las comisiones y los supuestos de ejecución. Si cambian varias cosas a la vez, no sabrás si la divergencia se debió a la corrección del proveedor o a tu propio experimento.

¿Debería usar siempre el historial de opciones más reciente?

Usa el historial más reciente cuando el objetivo sea trabajar con la mejor reconstrucción actual del proveedor. Conserva la instantánea anterior cuando necesites reproducir un resultado previo o entender qué información tenía tu sistema de investigación en ese momento. Son preguntas distintas.

En la investigación point-in-time, un registro corregido puede ser más preciso ahora y, aun así, no haber estado disponible para la estrategia entonces. Conserva las horas de publicación y recepción cuando sea posible; de lo contrario, deja clara la limitación. Una reconstrucción actual no equivale automáticamente al conjunto de información histórico.

Cuando cambia un backtest de opciones, la primera pregunta debería ser: “¿Qué observaciones cambiaron?”. La pregunta “¿Qué ejecución es correcta?” viene después, cuando ya puedas responder a la primera.

¿Qué debería guardar con cada backtest?

Guarda junto a los resultados un manifiesto conciso: proveedor e instantánea de datos, hora de recuperación, versiones del esquema y de limpieza, fuente de los metadatos de contratos, commit de la estrategia, supuestos de ejecución y configuración de la ejecución. Incluye un enlace desde cada operación a los registros de cotización que la justificaron.

Ese pequeño registro convierte una nueva ejecución misteriosa en una comparación que puedes inspeccionar. El historial de opciones seguirá recibiendo correcciones. Tu proceso de investigación debe hacer visible cada corrección, para que un archivo mejor aporte evidencia más sólida sin reescribir el experimento en silencio.