Backtest vs cuenta real.

Un backtest responde a una pregunta concreta y limitada: si estas reglas hubieran estado activas durante este periodo histórico, ¿qué habría pasado? Es una reconstrucción. Se toman los datos de precio del pasado, se aplican las reglas del sistema operación a operación y se obtiene una curva de resultados.

Una cuenta real responde a otra pregunta: con estas reglas activas, en este mercado, con este bróker y este capital, ¿qué está pasando? No hay reconstrucción. Las órdenes se envían, se ejecutan a un precio que no eliges y el resultado es un hecho contable, no una estimación.

La distinción parece obvia enunciada así, pero se disuelve en la práctica porque ambas cosas se presentan con el mismo formato: una curva ascendente, un porcentaje de rentabilidad, una cifra de drawdown. Visualmente son idénticas. Epistemológicamente no tienen nada que ver. Una es lo que un modelo cree; la otra es lo que el mercado hizo.

De ahí sale la regla más útil de todo este artículo: un backtest sirve para descartar sistemas, no para seleccionarlos. Si un sistema no funciona ni siquiera sobre el pasado, con todas las condiciones a su favor, no merece un euro. Pero que funcione sobre el pasado no dice casi nada sobre el futuro, y desde luego no dice lo que la curva parece estar diciendo.

Entre lo que el backtest promete y lo que la cuenta entrega hay una distancia sistemática. No es mala suerte: es estructural, y tiene fuentes identificables.

El backtest conoce el futuro del periodo. No en el sentido trivial de hacer trampas, sino en uno más sutil: quien diseñó las reglas ya sabía qué había pasado en esos años. Sabía que hubo una crisis en tal fecha y una tendencia en tal otra. Esa información se filtra en las decisiones de diseño aunque nadie la introduzca a propósito. Un sistema construido después de 2020 “sabe” cómo se comportaron los mercados en marzo de 2020.

El backtest ejecuta en un mundo perfecto. Asume que la orden se llena al precio que aparece en los datos, que siempre hay contrapartida, que la conexión no falla y que el spread es el habitual. En una cuenta real, los momentos en que el sistema más quiere operar son exactamente los momentos en que el mercado está más tenso: es cuando el spread se abre, cuando la ejecución se desplaza y cuando la liquidez desaparece.

El backtest no tiene una persona detrás. Este es el factor que casi nadie modela y que más resultados destruye. La curva simulada atraviesa el drawdown del mes catorce sin inmutarse. La cuenta real la atraviesa con un ser humano mirando el saldo cada mañana, y ese humano tiene la capacidad de desactivar el sistema en el punto más bajo. Cuando eso pasa, el resultado del inversor y el resultado del sistema dejan de ser el mismo número para siempre.

Hay una parte de la brecha que sí se puede calcular con aritmética simple, y conviene hacerlo porque el resultado suele sorprender. Los costes de fricción — spread, comisión, deslizamiento — se pagan por operación, y por tanto su impacto anual depende de cuántas operaciones haga el sistema.

Supongamos, como ejemplo aritmético genérico, un coste total de fricción de 0,05% del capital por operación. Ese número parece despreciable. Multiplícalo por la frecuencia:

La conclusión práctica es incómoda para media industria: cuanto más opera un sistema, más frágil es su backtest. Un sistema de baja frecuencia puede equivocarse en la estimación de costes y seguir siendo viable. Uno de alta frecuencia que subestime el deslizamiento en unas décimas puede pasar de rentable a ruinoso sin cambiar una sola regla.

Por eso, cuando alguien te enseñe un backtest, la primera pregunta no es cuánto gana. Es qué costes ha descontado y de dónde salen esos costes. Si la respuesta es vaga, la curva es decorativa.

Si el backtest no basta y la cuenta real tarda años en dar información concluyente, ¿qué queda? Queda una secuencia. No es original ni ingeniosa: es simplemente lo que hace cualquiera que se tome en serio no engañarse a sí mismo.

Primero, backtest sobre histórico extenso, e idealmente fuera de muestra: una parte de los datos que no se usó para construir las reglas y que sirve para comprobar si la lógica sobrevive a un periodo que no la vio nacer.

Segundo, forward-test en demo, mínimo tres meses. Aquí el sistema opera sobre precios que aún no existían cuando se escribió la regla. Es la primera vez que el futuro es de verdad futuro. La demo no reproduce bien la ejecución, pero sí verifica que la lógica no se rompe en movimiento.

Tercero, forward-test con capital propio, mínimo tres meses. Este paso no es ceremonial. Es donde aparecen el deslizamiento real, los rechazos de orden, las noches de baja liquidez y todo lo que la demo suaviza. Y es donde quien construye el sistema pone su propio dinero antes de pedirle a nadie que ponga el suyo.

Cuarto, revisión técnica: comparar las métricas observadas contra las que el backtest predecía. No para celebrar que coinciden, sino para entender en qué difieren y si esa diferencia tiene una explicación mecánica o es una señal de que el modelo no describe la realidad.

La comparación mal hecha consiste en mirar la rentabilidad del backtest, mirar la del real y ver si se parecen. Eso no informa de nada, porque un periodo corto de operativa real puede desviarse mucho por puro azar sin que el sistema tenga ningún problema.

La comparación bien hecha se fija en la forma. Estas son las preguntas que sí discriminan:

• ¿El sistema gana y pierde en los mismos contextos que en el backtest? Si el simulado sufría en mercados laterales y el real está sufriendo en tendencias, algo no cuadra.
• ¿La profundidad de las caídas reales está dentro del rango característico que el backtest anunció, o lo ha superado ya?
• ¿La frecuencia operativa coincide? Un sistema que en real hace la mitad de operaciones que en simulado está viendo un mercado distinto del que se modeló.
• ¿El porcentaje de aciertos y el tamaño medio de ganancia y pérdida se mantienen? Estas dos métricas son más estables que la rentabilidad y por eso delatan antes.

Y una advertencia contraintuitiva: si el real va mejor que el backtest de forma persistente, no lo celebres. Significa que el modelo no describe correctamente el proceso, y un modelo que se equivoca a tu favor hoy se equivocará en tu contra mañana. Lo que quieres no es que la realidad supere a la simulación: quieres que la simulación sea aburridamente parecida a la realidad.

La aplicación práctica es sencilla. Cuando alguien te presente un sistema, separa mentalmente en dos columnas todo lo que te enseñe: lo que es simulación y lo que es medición. Casi siempre descubrirás que la columna de la simulación está llena y la de la medición, casi vacía. Esa asimetría es el dato.

Después haz las tres preguntas que ordenan la conversación: ¿hay operativa real y verificable por un tercero, o solo curvas generadas por quien vende? ¿Cuánto tiempo lleva funcionando y cuántas operaciones contiene ese periodo? ¿Y qué dijo el backtest que iba a pasar, para poder contrastarlo?

Esto aplica también a nosotros, y conviene decirlo explícitamente porque es el sentido de publicar este artículo. Tienes derecho a exigirle a VERTEX exactamente el mismo estándar: mirar el histórico real, comparar lo observado con lo declarado y decidir con la brecha delante. Si algo no encaja, la conclusión correcta es no entrar. Preferimos un inversor que se va con criterio a uno que entra sin él.

Si quieres ir más a fondo, dos lecturas encajan aquí: la de cómo leer un backtest sin engañarte — los sesgos concretos que inflan una curva — y la de overfitting en trading algorítmico, que explica por qué un backtest excelente es a menudo una mala señal. Y nuestros números observados están en transparencia.