Del backtest a la ejecución: validación cuantitativa y automatización
August 17, 2026
11
Min
En el artículo anterior analizamos cómo NinjaTrader puede utilizarse para descender desde una vela tradicional hasta niveles mucho más granulares de información: transacciones, Bid/Ask, Delta, Volumetric Bars y profundidad del mercado. Sin embargo, transformar información en variables es únicamente la primera mitad del proceso cuantitativo.
El error más frecuente en trading algorítmico ocurre después. Programamos una estrategia, ejecutamos un backtest, encontramos una curva de capital atractiva y asumimos que hemos descubierto una ventaja. Desde una perspectiva de ingeniería, ese resultado debería considerarse apenas el inicio de la investigación. Un algoritmo no demuestra su robustez porque haya explicado correctamente el pasado. Debe sobrevivir al proceso mediante el cual intentamos destruirlo.
NinjaTrader incorpora dentro de Strategy Analyzer diferentes capas para este proceso: backtesting, optimización, Walk Forward Optimization, análisis Monte Carlo y herramientas para estudiar el comportamiento de las estrategias bajo diferentes configuraciones y supuestos de ejecución.
La importancia de esta arquitectura no reside simplemente en disponer de muchas herramientas. Reside en que permite recorrer una secuencia metodológica mucho más profesional: hipótesis, backtest, optimización, estabilidad, out-of-sample, incertidumbre, simulación y ejecución. El desarrollo de un algoritmo no termina cuando el código compila. La investigación Quant apenas está comenzando.
Un backtest permite analizar el comportamiento histórico de una estrategia sobre un conjunto determinado de datos. NinjaTrader permite configurar la estrategia, instrumento, serie de datos y propiedades de la simulación dentro de Strategy Analyzer. Sin embargo, existe una diferencia conceptual importante entre ejecutar un backtest y validar una estrategia.
Supongamos que construimos un sistema con tres parámetros: una EMA rápida, una EMA lenta y un stop basado en ATR. Elegimos EMA rápida de 20, EMA lenta de 100 y un ATR Stop de 2, y el resultado histórico es excelente. La pregunta inmediata del investigador no debería ser "¿cuánto habría ganado?". Debería ser "¿por qué elegimos exactamente 20, 100 y 2?".
Si esos parámetros fueron definidos después de observar repetidamente el mismo histórico, parte de la información futura ya ha contaminado indirectamente nuestra decisión. No necesitamos utilizar explícitamente datos futuros para introducir sesgo. Basta con mirar el mismo backtest suficientes veces, modificar la estrategia y conservar únicamente los cambios que mejoraron la curva histórica.
Cada iteración puede acercarnos menos a una ventaja estructural y más a una explicación cada vez más sofisticada del pasado. Por eso el backtest debe entenderse como un experimento controlado y no como una certificación automática de rentabilidad.
Strategy Analyzer permite optimizar parámetros mediante backtests iterativos. El investigador define valores mínimos, máximos e incrementos, y el optimizador prueba diferentes combinaciones buscando maximizar una métrica objetivo. Esto es extraordinariamente útil y extraordinariamente peligroso.
Imaginemos una EMA rápida entre 5 y 30 periodos, una EMA lenta entre 40 y 200 y un ATR Stop entre 1 y 4. Un ordenador puede evaluar miles de combinaciones y decirnos cuál habría producido el mayor beneficio histórico. Pero encontrar el punto máximo no necesariamente significa encontrar la mejor estrategia.
En investigación cuantitativa suele ser mucho más interesante estudiar la superficie de resultados. Supongamos que la mejor combinación es EMA rápida 17, EMA lenta 83 y ATR 2,37, pero configuraciones muy cercanas producen resultados radicalmente peores. Esto debería generar sospechas.
Un sistema estructuralmente robusto normalmente debería mostrar cierta tolerancia alrededor de sus parámetros. No necesariamente resultados idénticos, pero sí una región razonablemente estable. Por eso considero que el objetivo profesional de una optimización no debería ser encontrar el mejor número, sino encontrar una región de estabilidad.
La optimización bien utilizada no sirve únicamente para maximizar el pasado. También puede utilizarse para estudiar qué tan frágil es una estrategia cuando modificamos ligeramente las condiciones bajo las cuales fue construida.
Una vez identificados parámetros potencialmente razonables, aparece el siguiente problema: seguimos evaluándolos sobre los mismos datos utilizados para encontrarlos. Aquí entra el Walk Forward Optimization.
El procedimiento divide la investigación en ventanas. Los parámetros son optimizados sobre un segmento histórico in-sample y posteriormente utilizados sobre un periodo futuro out-of-sample que no participó en la optimización. Después, ambas ventanas avanzan y el proceso vuelve a repetirse.
Durante el periodo in-sample permitimos que el sistema encuentre los parámetros. Durante el periodo out-of-sample, esos parámetros están congelados. Ese segundo tramo es mucho más interesante porque el modelo está siendo evaluado sobre información que no participó directamente en la selección de la configuración.
La pregunta cambia. Ya no estamos preguntando "¿qué configuración explica mejor este histórico?". Estamos preguntando "si hubiera seleccionado los parámetros utilizando únicamente la información disponible hasta ese momento, ¿qué habría ocurrido después?".
Walk Forward no elimina el riesgo de sobreajuste. Ninguna herramienta lo hace por sí sola. Pero introduce una disciplina fundamental: separar el proceso utilizado para construir el modelo del proceso utilizado para evaluarlo.
Conviene señalar además un problema de segundo orden que aparece con frecuencia. Si repetimos el Walk Forward una y otra vez, cambiando ventanas, métricas objetivo o rangos de parámetros hasta que el resultado out-of-sample nos convence, hemos reintroducido exactamente el sesgo que intentábamos evitar, solo que en una capa más profunda. Marcos López de Prado lo describe como el problema del backtesting múltiple. Cuantas más configuraciones probamos, mayor es la probabilidad de encontrar por azar una que parezca robusta. La disciplina mínima consiste en registrar cuántas variantes fueron evaluadas antes de llegar al resultado que estamos presentando, porque ese número cambia por completo la interpretación de la métrica final.
Incluso si una estrategia supera las etapas anteriores queda otra fuente de incertidumbre: la secuencia de resultados. Imaginemos un sistema con 100 operaciones, de las cuales 55 son ganadoras y 45 perdedoras. El histórico puede distribuirlas de una forma que produzca un drawdown perfectamente tolerable.
Pero el mercado no está obligado a entregarnos las operaciones en ese mismo orden. Podemos experimentar varias pérdidas consecutivas antes de que la ventaja estadística vuelva a manifestarse. La rentabilidad final podría seguir siendo compatible con el sistema mientras la experiencia financiera del trader cambia radicalmente.
NinjaTrader incorpora simulación Monte Carlo sobre los resultados de las operaciones. Esta capa permite estudiar distintos desenlaces posibles y modifica otra vez la pregunta. Un trader tradicional pregunta "¿cuál fue el máximo drawdown?". Un investigador debería preguntar "¿qué drawdowns son plausibles dada la distribución de resultados de este sistema?".
La diferencia es fundamental para gestión de capital. Si una estrategia muestra un drawdown histórico del 8%, no significa que 8% sea una frontera física que el futuro no pueda atravesar. La curva histórica es una realización, no una garantía.
Dicho esto, también conviene reconocer el límite de la herramienta. Reordenar o remuestrear las operaciones asume implícitamente que son independientes entre sí, y en los mercados reales no lo son. La volatilidad se agrupa y las rachas perdedoras tienden a concentrarse dentro de los mismos regímenes. Monte Carlo ayuda entonces a dimensionar el riesgo de secuencia, pero no captura el riesgo de régimen. Un sistema puede mostrar una distribución de drawdowns aceptable bajo remuestreo y comportarse mucho peor cuando cambia la estructura de mercado que lo hacía funcionar.
Existe todavía otro problema que suele quedar escondido detrás de una curva atractiva: el modelo de ejecución. Durante un backtest deben realizarse supuestos acerca de cuándo y a qué precio podrían haberse ejecutado las órdenes. Los fills históricos dependen del modelo de llenado y de la resolución utilizada, mientras que en simulación con datos en tiempo real o Playback interviene información de mercado que no siempre está disponible en un backtest tradicional. Es el mismo problema de resolución del dato que discutimos en el artículo anterior, ahora visto desde el lado de la orden y no desde el lado de la serie.
Esto significa que señal correcta no equivale a ejecución garantizada. Dos estrategias idénticas a nivel lógico pueden terminar produciendo resultados distintos debido a slippage, liquidez, latencia, fills parciales o comportamiento de las órdenes.
Hay además un componente que suele quedar fuera de la conversación sobre slippage, y son las comisiones. En una estrategia cuya ventaja esperada sea de dos o tres ticks, el costo de transacción no es un ajuste marginal sobre el resultado. Con frecuencia es el término dominante. NinjaTrader permite incluir comisiones dentro de la configuración del backtest, y en sistemas con alta frecuencia de operación esa casilla decide si la curva de capital existe o no. Un sistema con más de mil operaciones al año y una ventaja bruta de dos ticks puede convertirse en un sistema perdedor únicamente al cambiar el esquema de comisiones con el que fue evaluado.
Este punto es especialmente relevante en sistemas de scalping o microestructura. Una estrategia cuyo edge esperado sea dos o tres ticks tiene una sensibilidad mucho mayor al modelo de ejecución que una estrategia de varios días cuyo objetivo sea capturar movimientos mucho más amplios. La simulación debe ser proporcional al problema. La precisión del modelo debe concentrarse donde existe sensibilidad económica.
Una ventaja importante de trabajar con NinjaScript es que la lógica no tiene que detenerse en la generación de una señal. La plataforma es orientada a eventos y permite reaccionar al ciclo de vida de las órdenes.
OnOrderUpdate() recibe cambios relacionados con el estado de una orden, mientras OnExecutionUpdate() se activa cuando se produce una ejecución o fill. Una misma orden puede generar varias ejecuciones parciales. Esta diferencia permite separar claramente la intención de operar de aquello que realmente ocurrió en el mercado.
Una señal LONG no significa necesariamente una posición LONG completa. Entre ambos estados pueden existir una orden enviada, una orden aceptada, uno o varios partial fills y, finalmente, un fill completo. También puede existir un rechazo. Para un sistema profesional, esta distinción es crítica.
El algoritmo no debería limitarse a saber cuándo quiere comprar. Debe saber qué ocurrió después de intentar hacerlo. Esta arquitectura permite gestionar stops y targets en función de ejecuciones reales, reaccionar ante fills parciales y desarrollar controles más avanzados alrededor de estados operativos. Es en este punto donde la ingeniería de ejecución empieza a ser tan importante como la lógica que generó la señal.
Hasta ahora hemos asumido que la estrategia reside dentro de NinjaTrader mediante NinjaScript. Pero existe otra arquitectura posible. NinjaTrader incorpora la Automated Trading Interface, conocida como ATI, diseñada para recibir señales generadas desde aplicaciones externas y utilizar NinjaTrader como parte de la capa de automatización y ejecución.
Esto abre una arquitectura especialmente interesante para sistemas Quant. Un motor externo puede encargarse de datos macroeconómicos, machine learning, factores, modelos de portafolio o señales estadísticas; posteriormente, una capa de integración entrega la señal a NinjaTrader para continuar el proceso operativo.
Esta separación puede ser útil cuando Python permanece como entorno de investigación y procesamiento estadístico mientras NinjaTrader participa en otra capa del sistema. La plataforma contempla mecanismos como File Interface, basada en archivos de instrucciones de órdenes, y DLL Interface para la comunicación con aplicaciones externas.
Sin embargo, hay que hacer una precisión importante. ATI no debe confundirse con una API completa de brokerage o market data. Su función principal es procesar señales procedentes de aplicaciones externas y conectarlas con la automatización dentro de NinjaTrader. Esto significa que debemos verla como una interfaz de integración para ejecución, no como un reemplazo universal de una API de datos o brokerage.
Podemos pensar entonces en dos arquitecturas. En una arquitectura nativa, NinjaTrader, NinjaScript y C# contienen el modelo, la gestión de órdenes y la ejecución. En una arquitectura híbrida, un motor Quant externo genera la señal y ATI conecta esa señal con NinjaTrader. Ninguna es universalmente superior. La arquitectura debe construirse alrededor del problema.
Existe una tendencia a considerar que el trabajo cuantitativo termina cuando encontramos una estrategia históricamente rentable. Desde una perspectiva de ingeniería, debería ocurrir exactamente lo contrario. Ese es el momento en el que comienzan las preguntas difíciles.
¿Los parámetros son estables? ¿El resultado depende de un punto extraordinariamente específico del espacio de optimización? ¿Cuántas configuraciones probamos antes de encontrarlo? ¿Qué ocurre fuera de muestra? ¿Qué distribución de drawdowns podría experimentar? ¿Qué sucede cuando modificamos la secuencia de operaciones? ¿Qué supuestos utiliza el backtest para simular los fills? ¿Sobrevive la ventaja después de comisiones? ¿Qué pasa cuando la orden es parcialmente ejecutada? ¿El sistema sabe reaccionar ante un rechazo? ¿Existe continuidad entre la señal teórica y la posición real?
El trabajo profesional no consiste en demostrar que una estrategia funciona. Consiste en intentar demostrar que no funciona y observar si, después de suficientes pruebas, todavía permanece una ventaja.
En este sentido, NinjaTrader resulta particularmente interesante porque permite conectar buena parte de ese proceso dentro de un mismo ecosistema: investigación histórica, optimización, Walk Forward, Monte Carlo, simulación y automatización de órdenes.
Pero la conclusión más importante trasciende a la plataforma. El Quant no está definido por utilizar Python, C#, NinjaScript o cualquier lenguaje específico. Está definido por la metodología con la que enfrentamos una hipótesis al mercado.
El código formaliza la idea. El backtest la somete al pasado. El out-of-sample intenta enfrentarla a lo desconocido. Monte Carlo desafía nuestra percepción del riesgo. La ejecución, finalmente, obliga al modelo a enfrentarse con aquello que ninguna simulación puede reproducir completamente: el mercado real.
Cuando logramos integrar todas esas etapas, dejamos de construir scripts. Comenzamos a construir sistemas.
Escrito por
Colaborador senior. CTO y cofundador de FinancialTools.io. Especializado en programación algorítmica y trading cuantitativo.
