Un backtest no es un historial en vivo

Un backtest es una prueba sobre datos que ya ocurrieron: se aplica un conjunto de reglas a un histórico de precios y se observa qué habría hecho ese sistema en esas condiciones. Es una herramienta habitual y útil en el trabajo cuantitativo. Sirve para investigar ideas, comparar variantes, comprobar si una lógica es coherente y descartar enfoques que no resisten el análisis antes de arriesgar capital. Nada de eso es sospechoso.

El malentendido aparece en otro punto: en confundir lo que un backtest mide con lo que registra un historial en vivo. Uno es un ejercicio de simulación sobre un pasado conocido; el otro es el resultado de aplicar la misma lógica en condiciones que no se pueden reproducir del todo, con costes, decisiones y fricciones reales. Este artículo trata de la frontera entre ambos, no de descalificar la herramienta.

Qué prueba un backtest y qué no

Un backtest bien planteado demuestra varias cosas concretas. Que las reglas se pueden aplicar sin intervención subjetiva. Que, sobre esos datos y bajo esos supuestos, la lógica produjo un conjunto de operaciones identificable. Que el resultado no depende de un único episodio. Y que la idea se comporta de forma distinta a una versión aleatoria o más simple. Estas comprobaciones tienen valor: muchas estrategias que suenan bien no superan ni la primera.

Lo que un backtest no puede demostrar es igual de importante. No dice qué hará el mercado mañana. No reproduce tu tamaño de posición real ni el efecto que tu propia orden tiene sobre el precio. No captura el momento en que la liquidez desaparece. No mide la disciplina de quien ejecuta cuando el resultado lleva semanas siendo incómodo. Es una descripción de una hipótesis bajo condiciones definidas, no una predicción.

El ajuste al pasado: cuando las reglas se adaptan a los datos

El riesgo central de cualquier prueba retrospectiva es el ajuste al pasado. Ocurre cuando los parámetros se modifican una y otra vez hasta que la curva encaja con los datos utilizados. Con suficientes intentos, casi cualquier histórico puede producir un resultado atractivo. Ese resultado no es una predicción: es una descripción muy precisa de algo que ya pasó.

El fenómeno no requiere mala intención. Basta con buscar la mejor combinación sin límite y sin una razón previa que explique por qué esa combinación debería funcionar. Cuanto más se itera sobre los mismos datos, más se aprende sobre el pasado concreto y menos sobre el comportamiento general.

Las formas de reducirlo son conocidas y exigentes: definir las reglas antes de probarlas, limitar el número de variantes, exigir una lógica que explique por qué la ventaja debería existir —y no solo que existió en una ventana concreta— y reservar datos que no se hayan usado para decidir nada. Un backtest excelente sobre el periodo que se ajustó habla sobre todo del proceso de búsqueda.

Los supuestos sostienen la prueba

Todo backtest se apoya en supuestos. Cómo se llena una orden, a qué precio, con qué diferencial entre compra y venta, en qué momento se decide, si se opera al cierre o a la apertura, qué ocurre cuando el precio salta por encima del nivel previsto. Los supuestos no son un defecto: son simplificaciones necesarias para poder calcular algo.

El punto es si están declarados y si son prudentes. Un supuesto explícito permite discutir la prueba y estimar cuánto cambia el resultado si se endurece. Un supuesto implícito la convierte en una caja cerrada. Cuando el resultado depende de una condición optimista, lo que aparece no es el comportamiento del sistema, sino el de una condición concreta que quizá no se repita.

Costes y ejecución no son un detalle

Un histórico limpio tiende a ignorar la fricción. En la operativa real hay diferencial de compra y venta, comisiones, costes de financiación de las posiciones que se mantienen y deslizamiento: la diferencia entre el precio esperado y el obtenido. Estos elementos actúan todos en la misma dirección y reducen el resultado.

Aun así, un modelo de costes fijo sigue siendo una aproximación. La ejecución real incluye retrasos, momentos de poca liquidez, diferencias entre proveedores y variaciones que una constante no recoge. Un sistema que solo resulta rentable antes de costes no ha superado una prueba: ha omitido la parte más difícil de trasladar a la práctica.

Validar fuera de muestra: el examen que sí aporta

La prueba más informativa no es la que se hace sobre los datos usados para diseñar, sino sobre datos que el sistema no vio. Separar una muestra para construir y otra para validar es el mínimo. Ir más allá implica validaciones sucesivas en ventanas que avanzan en el tiempo, volviendo a estimar parámetros con la información disponible en cada tramo.

La lógica es simple: si las reglas capturan algo real, deberían mantener un comportamiento razonable donde no fueron ajustadas. Si solo funcionan en el tramo que las vio nacer, estamos ante una descripción, no ante un método.

Conviene añadir una advertencia honesta: la validación fuera de muestra tampoco es infalible. Si se repite muchas veces sobre la misma muestra reservada, esa muestra deja de ser externa y pasa a formar parte de la búsqueda. La degradación entre el resultado ajustado y el resultado en datos no vistos es esperable. Lo importante es que sea moderada y que exista una explicación, no que el número final sea llamativo.

Preguntas útiles antes de tomar un backtest como referencia

Ante una prueba retrospectiva, conviene cambiar la impresión por una revisión ordenada:

• ¿Qué periodo cubre y por qué se eligió ese?
• ¿Se distingue entre los datos usados para diseñar y los reservados para validar?
• ¿Los supuestos de ejecución están descritos y son prudentes?
• ¿Se incluyen costes, comisiones y financiación?
• ¿Cuántas variantes se probaron antes de quedarse con esta?
• ¿Se explican las reglas, o solo se enseña el resultado?
• ¿Funciona en instrumentos o periodos distintos de los que se usaron para ajustarlo?
• ¿Cómo se comporta en sus peores tramos y cómo se gestiona el riesgo ahí?

Ninguna respuesta convierte una prueba en certeza. Su utilidad es otra: separar una investigación honesta de una presentación brillante. Y si no hay respuesta a la mayoría, no hace falta construir una acusación. Basta con reconocer que la información disponible no permite concluir más, y aplazar una decisión que dependa de ella.

El lugar de cada prueba

Un backtest y un historial en vivo no compiten: responden a preguntas distintas. El backtest permite investigar antes de arriesgar capital y descartar ideas que no sostienen el análisis. El historial en vivo comprueba qué ocurre cuando esa misma lógica se enfrenta a costes reales, decisiones en tiempo real y condiciones que nadie había previsto.

La postura educativa de FX Capital es la misma en los dos casos: mostrar el proceso y explicar sus límites antes que presentar un resultado como conclusión. Un backtest no es una promesa ni una condena; es una prueba con un alcance definido. Leerlo bien consiste en preguntar qué se probó, bajo qué supuestos, con qué costes y sobre qué datos no vistos. Ahí empieza la evaluación seria, y ahí es donde un historial en vivo sigue siendo insustituible.

Nota de riesgo: este artículo es educativo. La operativa en mercados financieros implica riesgo de pérdida. Un backtest o un historial pasado, incluso verificable, no garantiza resultados futuros ni constituye una recomendación personalizada.