Una racha de pérdidas no demuestra que el sistema haya dejado de funcionar
Si un sistema tiene una ventaja o edge, esa ventaja se expresa sobre una distribución de muchas operaciones. No existe ninguna obligación de que aparezca de forma ordenada.
Puedes tener un sistema con una expectativa favorable y aun así atravesar una secuencia bastante desagradable de pérdidas. Eso no contradice necesariamente el sistema; puede ser simplemente varianza.
Aquí conviene recordar lo que ya aprendiste al estudiar la equity curve: una curva de capital no sube en línea recta. Tiene máximos, retrocesos, periodos planos y recuperaciones.
El error aparece cuando convertimos el peor drawdown observado en el pasado en una frontera mágica.
Supón que tu backtest tuvo un drawdown máximo de 12R. Llegas a trading real, alcanzas -12.2R y concluyes:
“Se rompió el sistema.”
No puedes saberlo únicamente con ese dato.
El backtest contiene una secuencia histórica concreta. El futuro puede producir otra distribución de operaciones y, por tanto, un drawdown mayor incluso aunque la ventaja subyacente siga existiendo.
Por eso herramientas como la simulación Monte Carlo son más útiles que mirar únicamente el peor resultado histórico: te permiten estudiar muchas secuencias posibles y entender mejor qué variabilidad podría producir el mismo sistema.
La idea importante no es obtener un número que prediga exactamente tu próximo drawdown. Es construir una referencia más realista de qué podría considerarse comportamiento normal y qué empezaría a resultar extraordinario.
Entonces, ¿cuándo debería preocuparme de verdad?
Yo separaría las señales en cuatro niveles.
| Situación observada | Qué significa realmente | Qué haría |
|---|---|---|
| Variación dentro de lo esperado | El sistema pierde, pero su comportamiento sigue pareciéndose al que validaste | Mantener el plan |
| Deterioro moderado o ambiguo | Algunas métricas empiezan a desviarse, pero todavía no sabes por qué | Intensificar la revisión y controlar el riesgo según tus reglas previas |
| Comportamiento fuera del rango previsto | Drawdown, duración, costes o resultados se alejan materialmente de lo validado | Pausar dinero real y diagnosticar |
| La lógica de la ventaja ya no se sostiene | Cambió la estructura que hacía posible el edge o el sistema deja de ser ejecutable tras costes | Retirar o rediseñar y validar desde cero |
Fíjate en algo: “he perdido X operaciones” no aparece como criterio suficiente.
Una secuencia de ocho pérdidas puede ser completamente extraordinaria para un sistema y bastante habitual para otro. Sin conocer la distribución del sistema, el número por sí solo casi no te dice nada.
Lo que necesitas es comparar el comportamiento real contra el comportamiento que razonablemente cabía esperar después de las pruebas de robustez.
Antes de culpar al sistema, comprueba si estás operando el mismo sistema
Esta pregunta parece obvia, pero elimina una enorme cantidad de diagnósticos equivocados.
Imagina que tu metodología fue probada con una entrada concreta, un stop determinado, un horario definido y una regla precisa para mantener las operaciones ganadoras.
En real empiezas a hacer esto:
Saltas algunas entradas después de perder. Cierras las ganancias antes porque quieres “asegurar”. Das un poco más de espacio al stop en una operación que te gusta especialmente. No tomas una señal porque acaba de publicarse una noticia. Después recuperas confianza y duplicas el tamaño.
Ya no estás evaluando el sistema del backtest.
Estás evaluando otro sistema.
Por eso el trading journal es tan importante en esta fase. No debería servir únicamente para anotar cuánto ganaste o perdiste. Debe permitirte comprobar si cada operación respetó las reglas que estás intentando evaluar.
Si la ejecución se ha desviado, separa primero el error del trader del error del modelo.
Eso tampoco significa atribuir cualquier pérdida a “falta de disciplina”. Si ejecutaste correctamente y el sistema se deteriora, insistir en que el problema eres tú solo retrasa el diagnóstico.
Comprueba también si el backtest era más optimista que tu trading real
Existe otra posibilidad: quizá la lógica del sistema no cambió, pero su resultado real nunca pudo reproducir el resultado teórico.
Aquí entran los costes.
Un sistema puede generar una ventaja pequeña antes de spread, comisión y slippage y convertirse en un sistema perdedor después de incorporarlos correctamente.
También puede ocurrir algo más sutil. Los costes estaban incluidos, pero eran demasiado optimistas.
Supón que el sistema espera capturar, en promedio, movimientos relativamente pequeños. Si cada operación pierde unas décimas adicionales de R por peor ejecución, la diferencia puede parecer insignificante de forma aislada. Multiplicada por cientos de operaciones, puede eliminar buena parte de la ventaja.
Por eso un forward test resulta tan útil antes de aumentar exposición: ayuda a encontrar diferencias entre lo que el sistema supone y lo que puedes ejecutar.
Si necesitas volver a probar el proceso sin arriesgar capital real, Pepperstone ofrece cuentas demo con fondos virtuales. La propia documentación de Pepperstone aclara que una demo sirve para probar estrategia y ejecución, pero que no necesariamente reproduce todas las condiciones de trading real.
Probar el sistema en una cuenta demo de Pepperstone
La demo puede responder “¿sé ejecutar esto correctamente?”. No puede garantizarte “esto se comportará exactamente igual con dinero real”.
El diagnóstico que yo haría antes de apagar un sistema
Cuando un sistema empieza a deteriorarse, intentaría contestar cuatro preguntas en este orden.
1. ¿La ejecución sigue siendo fiel a las reglas?
Revisaría entradas omitidas, operaciones adicionales, stops modificados, cambios de tamaño, cierres anticipados y cualquier otra diferencia entre el proceso definido y el realmente ejecutado.
Si no existe fidelidad suficiente, no tienes todavía evidencia limpia para decidir que el sistema está roto.
2. ¿La ejecución real sigue siendo económicamente viable?
Miraría spread, comisión, slippage, financiación cuando corresponda, calidad de los fills y cualquier fricción que afecte la expectativa.
Un edge teórico que desaparece después de costes no es un edge operable.
3. ¿El comportamiento sigue entrando dentro de lo que validaste?
Aquí ya entran las métricas del backtest, pero no escogería una sola.
Querría saber si se han deteriorado al mismo tiempo la profundidad del drawdown, su duración, el resultado medio por operación, la relación entre operaciones favorables y desfavorables y la estabilidad de los resultados.
Un dato aislado produce mucho ruido. Varias desviaciones coherentes cuentan una historia bastante más interesante.
4. ¿Sigue existiendo la razón por la que el sistema tenía ventaja?
Esta es, para mí, la pregunta más profunda.
Un sistema no gana porque MetaTrader, TradingView o un backtest digan que gana. Debe existir algún comportamiento suficientemente persistente que produzca una ventaja bajo determinadas condiciones.
Por ejemplo, un sistema puede depender de tendencias relativamente persistentes, de reversión a la media, de determinados niveles de volatilidad, de cierto comportamiento alrededor de una sesión o de una relación concreta entre instrumentos.
Si la condición que alimentaba la ventaja desaparece, seguir ajustando parámetros puede producir una curva histórica más bonita sin solucionar el problema real.
Y existe otra posibilidad: que la ventaja nunca hubiera sido tan sólida como parecía. La literatura sobre backtest overfitting muestra precisamente el peligro de probar muchas configuraciones y terminar seleccionando una que explica muy bien el pasado, pero pierde rendimiento fuera de muestra.
Ese matiz importa mucho: a veces el sistema no “dejó de funcionar”; simplemente descubriste en real que nunca había sido suficientemente robusto.
Un ejemplo para ver la diferencia
Supongamos un sistema hipotético que ya pasó por backtest, validación fuera de muestra y forward testing.
Tras incluir costes, su comportamiento validado sugería una pequeña ventaja positiva. Además, sus pruebas mostraban que los drawdowns podían ser largos y que una parte importante del rendimiento dependía de unas pocas operaciones muy buenas.
Comienzas a operarlo y las primeras 35 operaciones producen -7R.
¿Lo abandonas?
No necesariamente.
Si tus pruebas ya mostraban secuencias parecidas y estás ejecutando correctamente, esas 35 operaciones pueden representar una fase negativa completamente compatible con el sistema.
Ahora cambia el escenario.
Después de 120 operaciones observas que las ganancias medias son mucho menores que en la validación, los costes de ejecución son considerablemente más altos, aparecen muchas menos oportunidades con las condiciones originales y el comportamiento permanece deteriorado incluso cuando ejecutas las reglas correctamente.
Aquí la pregunta ya no es:
“¿Tengo paciencia suficiente?”
La pregunta es:
“¿Qué evidencia tengo para seguir exponiendo capital mientras investigo esto?”
Yo ahí preferiría pausar y diagnosticar.
Seguir operando únicamente porque “algún día debe volver a la media” es tan emocional como abandonar el sistema después de tres pérdidas.
Pausar no es lo mismo que declarar muerto el sistema
Esta distinción merece quedar muy clara.
Pausar significa retirar temporalmente el riesgo mientras investigas una desviación.
Modificar significa alterar alguna parte del sistema y volver a someter la nueva versión a un proceso de validación.
Retirar significa que ya no tienes una justificación suficiente para seguir destinando capital a esa metodología.
Un sistema puede pausarse porque aparece un problema de datos, porque la ejecución real se deteriora o porque el régimen actual es muy distinto de aquel para el que fue diseñado.
Eso no demuestra automáticamente que jamás pueda volver a funcionar.
Pero tampoco deberías reactivarlo simplemente porque tuvo dos semanas buenas mientras estaba apagado. Necesitas un criterio de reentrada tan serio como el criterio de salida.
Y si descubres que el sistema necesita cambios, ahí volvería a la lección anterior sobre cómo mejorar un sistema sin sobreoptimizarlo. El objetivo de esta lección no es enseñarte a retocar parámetros; es enseñarte a decidir cuándo dejar de arriesgar capital con la versión que tienes.
La regla de suspensión debería existir antes del drawdown
Yo no esperaría a estar en -15R para decidir qué significa -15R.
Lo definiría cuando el sistema todavía no me está haciendo daño emocional.
Una política de control podría especificar, por ejemplo, qué desviaciones obligan a revisar el sistema, cuándo se reduce o elimina temporalmente la exposición, qué condiciones deben cumplirse antes de reactivarlo y qué evidencia haría abandonar definitivamente la hipótesis.
La cifra concreta depende del sistema.
Un método con 300 operaciones al mes puede acumular evidencia mucho más rápido que uno que genera 25 operaciones al año. Un sistema con resultados muy dispersos necesita aceptar una variabilidad distinta de otro mucho más estable.
Por eso yo evitaría reglas universales como:
“Para después de cinco pérdidas.”
“Apaga el sistema al 10% de drawdown.”
“Si pierde durante dos meses ya no funciona.”
Parecen reglas objetivas. El problema es que son objetivas sin estar relacionadas con el sistema que pretenden controlar.
Una buena regla de suspensión debería salir de tus datos, tus stress tests, tu tolerancia de riesgo y la forma real en la que el sistema genera resultados.
El drawdown máximo histórico puede ser una alarma, pero no una sentencia
Hay un error muy extendido: tomar el máximo drawdown del backtest y convertirlo directamente en stop definitivo del sistema.
Yo no lo haría así.
Si tu peor drawdown histórico fue -10R y alcanzas -10.1R, acabas de superar una observación histórica. No acabas de demostrar matemáticamente que el sistema murió.
Eso sí: si superas de forma material el comportamiento que tus pruebas consideraban razonable, tienes una buena razón para dejar de arriesgar dinero mientras investigas.
La diferencia parece pequeña, pero cambia por completo la forma de actuar.
Un límite operativo responde:
“Hasta aquí estoy dispuesto a exponer capital antes de detenerme y revisar.”
No responde:
“A partir de aquí sé con certeza que el edge dejó de existir.”
En trading casi nunca tendrás esa certeza.
Lo que buscas es tomar una decisión suficientemente buena con información incompleta.
También debes vigilar un sistema que gana demasiado bien
Este punto suele olvidarse.
Imagina que tu metodología comienza a producir resultados muchísimo mejores que cualquier periodo del backtest.
La reacción natural es celebrarlo y aumentar tamaño.
Yo tendría curiosidad antes que euforia.
Una desviación positiva extrema también merece explicación.
Puede deberse a un régimen extraordinariamente favorable. Puede ser pura variabilidad. Puede existir un cambio estructural beneficioso. O quizá alguna diferencia en datos o ejecución está haciendo que compares dos cosas que no son realmente iguales.
El principio es el mismo: monitorizar un sistema significa comprobar si continúa comportándose de una forma compatible con lo que creías haber validado, no vigilar únicamente cuando pierde.
Los cinco errores que más evitaría cuando parece que el sistema dejó de funcionar
- Cambiar las reglas después de unas pocas pérdidas. Estás reaccionando al resultado, no a evidencia suficiente.
- Añadir filtros hasta recuperar el backtest bonito. Cuanto más ajustas al problema que acabas de observar, mayor es el riesgo de construir una solución específica para el pasado.
- Aumentar tamaño para recuperar antes. Un sistema bajo sospecha no es el momento lógico para elevar el riesgo.
- Seguir operando por orgullo. “Confío en mi sistema” no es una prueba estadística ni económica.
- Confundir un problema de ejecución con un problema de edge. Si operas algo distinto de lo probado, primero corrige esa diferencia y después evalúa.
Aquí hay dos errores opuestos: abandonar demasiado pronto y quedarse demasiado tiempo. Los dos nacen del mismo sitio: no haber definido previamente qué evidencia cambiaría tu decisión.
Si vas a reactivar el sistema, hazlo como si tuviera que volver a ganarse tu confianza
Una vez detenido, yo no regresaría directamente al tamaño anterior.
Primero comprobaría que la causa del problema está identificada o, como mínimo, que vuelve a existir evidencia compatible con las condiciones bajo las que el sistema fue validado.
Después volvería a observarlo en un entorno controlado: simulación, demo o exposición reducida, según el tipo de sistema y lo que estés intentando comprobar.
Pepperstone puede ser útil para esa fase porque permite abrir una cuenta demo y probar metodologías con fondos virtuales; aun así, recuerda que demo y real no son idénticos en todos los aspectos de ejecución. Si luego decides pasar a una cuenta real, revisa primero costes, instrumento, entidad contractual y condiciones aplicables a tu caso.
Consultar Pepperstone y la promoción disponible mediante nuestro enlace
No necesitas volver a confiar emocionalmente en el sistema. Necesitas reconstruir evidencia.
Saber detenerse también forma parte del sistema
Hay una idea con la que me gustaría cerrar todo este curso.
Crear un sistema no termina cuando defines la entrada.
Tampoco termina cuando haces un backtest bonito, pasas un forward test o empiezas a operar en real.
Un sistema serio incluye también un proceso para vigilarse a sí mismo.
¿Qué comportamiento considero normal? ¿Qué me haría investigar? ¿Qué me obligaría a retirar riesgo? ¿Qué tendría que observar para volver a activarlo? ¿Qué evidencia me haría aceptar que la hipótesis ya no merece más capital?
Si puedes responder esas preguntas antes de entrar en drawdown, has eliminado una enorme cantidad de improvisación.
Y eso conecta todo lo que has trabajado durante el curso: definir reglas, validar una hipótesis, analizar resultados, poner a prueba la robustez, ejecutar, registrar, revisar y mejorar.
Esta es la última lección del curso Cómo Crear, Testear y Mejorar un Sistema de Trading. El siguiente paso ya no es aprender otra métrica. Es aplicar el proceso completo a un sistema y conseguir que tus decisiones sobre él dependan cada vez menos de cómo te hizo sentir la última operación.
