A quién va dirigido — A quien haya definido una versión de una estrategia y quiera observarla sobre datos que llegarán después de congelarla, sin reescribir reglas, muestra ni criterios a la luz de los resultados.
Un forward test es la evaluación prospectiva de una versión congelada: la especificación queda identificada en un momento preciso y, desde entonces, produce decisiones siguiendo el flujo real del tiempo. Los datos futuros no pueden rebobinarse, seleccionarse ni sustituirse después de haber visto su resultado. La prueba mide el comportamiento de la versión durante el periodo observado; no demuestra que la ventaja vaya a continuar ni garantiza la misma ejecución a una escala mayor.
Out-of-sample y forward test responden a preguntas distintas. OOS describe si los datos participaron en el desarrollo: incluso un segmento histórico que ya existe puede ser OOS si permaneció realmente sellado. Un forward test describe, en cambio, el orden cronológico: los datos llegan después de la congelación. Paper, shadow y micro-live son entornos de implementación en los que puede realizarse un forward test; no son sinónimos de forward ni de OOS.
Relación entre datos, tiempo y entorno
| Término | Qué clasifica | Pregunta correcta | Ejemplo |
|---|---|---|---|
| Out-of-sample | Relación entre datos y desarrollo | ¿Influyeron los datos en alguna elección? | Holdout histórico nunca consultado |
| Forward test | Relación temporal | ¿La decisión precede a la llegada de los datos? | Versión congelada a fecha de hoy |
| Paper trading | Entorno simulado | ¿La orden expone capital real? | Cuenta demo con ejecuciones modelizadas |
| Shadow mode | Implementación paralela | ¿El flujo genera órdenes, pero no las enruta? | Órdenes sombra y logs en tiempo real |
| Micro-live | Entorno real reducido | ¿Qué efectos aparecen con pequeñas órdenes reales? | Enrutamiento y ejecuciones bajo límites estrictos |
Las categorías pueden solaparse. Una observación generada mañana por una versión congelada y nunca utilizada para modificarla es tanto forward como OOS respecto a esa versión. Si su resultado guía un filtro nuevo, se convierte en información de desarrollo para la siguiente versión.
Qué debe congelarse
Congelar «las reglas» no basta. La versión incluye al menos:
- código, dependencias, configuraciones y semillas pertinentes;
- universo, fuente de datos, calendario, timestamps y reglas para datos ausentes;
- variables, parámetros, señales y tratamiento de los casos sin operación;
- construcción de cartera, dimensionamiento, apalancamiento y restricciones;
- tipos de orden, modelo de ejecución, costes, financiación y benchmark;
- métricas principales, controles, umbrales de alerta y criterio de finalización;
- modo paper, shadow o live y sus diferencias conocidas.
Un cambio material crea un identificador nuevo. Corregir una errata en la documentación puede no alterar la versión; cambiar variables, universo, retraso, costes, dimensionamiento o comportamiento de las órdenes normalmente sí lo hace. El registro debe hacer verificable la decisión.
Protocolo prospectivo
- Escribir el mandato. Distinguir objetivo estadístico, comprobación del flujo, calidad de ejecución y formación operativa.
- Aplicar la congelación. Conservar versión, hashes de artefactos, fecha y hora, responsabilidades y criterios predefinidos de modificación o parada.
- Elegir el entorno. Declarar qué eventos son simulados y cuáles reales; documentar modelo de ejecución, bróker, centro de negociación, feed y latencia.
- Registrar todo el flujo. Conservar datos recibidos, señales nulas, intenciones, órdenes, rechazos, ejecuciones, posiciones, costes, alertas e intervenciones humanas.
- No limpiar retrospectivamente. Los errores y las interrupciones permanecen en el registro; cualquier exclusión sigue reglas definidas de antemano y se muestra.
- Comparar con las expectativas declaradas. Evaluar distribución, riesgo, exposición, rotación, ejecución y benchmark con su incertidumbre.
- Clasificar las desviaciones. Separar incidente de datos u operativo, error de implementación, deriva de ejecución, variabilidad normal y posible deterioro del modelo.
- Cerrar con una decisión trazable. Continuar, limitar, suspender, revalidar o crear una versión nueva son resultados distintos de «beneficio» y «pérdida».
Duración y cantidad de información
No existe una duración universal. El tiempo de calendario necesario depende de la frecuencia de la estrategia, la dependencia entre señales, el horizonte de las posiciones, la rareza de los eventos y la precisión exigida. Muchas operaciones correlacionadas no equivalen al mismo número de observaciones independientes; unas pocas semanas rentables pueden no incluir condiciones materiales.
El protocolo debería definir criterios basados en la cobertura y en la decisión: tipos de orden observados, sesiones y eventos relevantes, volumen de información, precisión de las métricas y ausencia de incidentes sin resolver. Una fecha final puede ser necesaria para la gobernanza, pero eso no la convierte en prueba estadística de suficiencia.
Tampoco una sola ratio de profit factor o Sharpe ni un umbral de drawdown pueden decidir la prueba. Las métricas deben leerse conjuntamente, netas de costes, frente a un benchmark elegido de antemano y con intervalos coherentes con la dependencia y la distribución. Un resultado puede ser favorable, incompatible con la hipótesis o simplemente no concluyente.
Cambios, incidentes y pureza
Durante el forward test pueden aparecer defectos operativos que exijan una intervención inmediata. La seguridad prevalece sobre la pureza estadística: un kill switch no debe retrasarse para «salvar la prueba». El registro conserva el incidente, la decisión y los datos implicados. Si la corrección modifica el comportamiento, comienza una versión nueva con un periodo prospectivo nuevo.
Consultar repetidamente los resultados y ajustar la estrategia convierte el forward test en desarrollo iterativo. La iteración es legítima, pero debe llamarse por su nombre; concatenar segmentos de versiones diferentes y presentarlos como un único track record no contaminado es incorrecto.
Ejemplo ilustrativo
Ejemplo expresamente ilustrativo — La versión 1.0 se congela con señales, dimensionamiento, costes y umbrales operativos. En shadow mode registra la orden que habría enviado para cada evento. Tras el inicio se descubre que los datos de una sesión reducida llegan con un calendario incorrecto: se conserva el incidente, se corrige el flujo y comienza la versión 1.1. Los resultados de la 1.0 no se atribuyen a la 1.1. No se especifica un número de días ni de operaciones porque dependen del objetivo y de la estructura de la información.
El paso siguiente podría ser una fase micro-live limitada para observar enrutamiento y conciliación. No es obligatoria ni suficiente en todos los contextos y requiere autorizaciones, límites de riesgo y capacidad operativa adecuados.
Limitaciones
- Un forward test solo observa los regímenes que se producen después de la congelación.
- Paper y shadow no reproducen plenamente la posición en la cola, el impacto, el préstamo ni la presión económica; micro-live no demuestra la capacidad al tamaño objetivo.
- Una versión congelada puede compartir sesgos de datos y diseño con el backtest.
- Monitorizar muchas métricas o estrategias aumenta el riesgo de selección ex post.
- El carácter prospectivo mejora la trazabilidad; no convierte correlación en causalidad.
Fuentes
- Leonard J. Tashman, Out-of-sample tests of forecasting accuracy: an analysis and review, 2000 — orden temporal, origen móvil y evaluaciones out-of-sample sucesivas.
- Joseph Simonian, CFA Institute Research Foundation, Investment Model Validation: A Guide for Practitioners, 2024 — validación proactiva y fiabilidad de los modelos de inversión.
- National Futures Association, Interpretive Notice 9025 — Use of Promotional Material Containing Hypothetical Performance Results — limitaciones del rendimiento hipotético dentro de su ámbito NFA.
- U.S. Securities and Exchange Commission, Staff Report on Algorithmic Trading in U.S. Capital Markets, 2020 — automatización, centros de negociación e interacción de órdenes en los mercados reales.
- Comisión Europea, Reglamento Delegado (UE) 2017/589, RTS 6 — pruebas, controles, documentación y despliegue dentro del ámbito regulatorio de la UE al que se aplica.