A quién va dirigido — A quien quiera convertir una idea de trading en una simulación controlable, distinguiendo lo que el modelo habría podido conocer y negociar de lo que solo resulta visible a posteriori.
Un backtest aplica a datos históricos una especificación completa de señales, cartera, órdenes, costes y restricciones. Produce un resultado contrafactual: qué habría ocurrido según ese modelo si las reglas se hubieran ejecutado durante el periodo observado. Es, por tanto, una simulación condicionada: el resultado está condicionado por los datos, reglas, modelo de ejecución, costes y restricciones especificados. No es un track record real, no demuestra que exista una relación causal y no garantiza que la distribución futura se parezca a la pasada.
La distinción decisiva es la que existe entre estrategia y simulador. La estrategia indica cuándo asumir riesgo; el simulador traduce esa decisión en posiciones y rendimientos. Una señal razonable puede parecer excepcional por un error de timestamp, por precios no negociables o por costes omitidos. En sentido contrario, un modelo de ejecución excesivamente punitivo puede ocultar el comportamiento que se pretende estudiar. Por tanto, los supuestos deben declararse y poder verificarse.
Qué debe especificar
| Nivel | Pregunta verificable | Error que ayuda a evitar |
|---|---|---|
| Datos | ¿Qué valor estaba disponible en ese instante exacto? | Look-ahead, revisiones y survivorship bias |
| Señal | ¿Con qué variables, retardos y parámetros se decide? | Reglas reconstruidas después de ver el resultado |
| Cartera | ¿Cómo se convierten las señales en pesos, tamaños y límites? | Apalancamiento o concentración implícitos |
| Ejecución | ¿Cuándo y a qué precio puede ejecutarse la orden? | Fills imposibles en la misma barra |
| Economía | ¿Qué costes, financiación, préstamo y corporate actions se aplican? | Confundir rendimiento bruto con rendimiento realizable |
| Evaluación | ¿Qué métricas, benchmarks y pruebas se eligieron antes? | Selección a posteriori de la lectura más favorable |
Los datos deben ser point-in-time siempre que su historia pueda cambiar. Esto incluye la composición de los índices, valores excluidos de cotización, fundamentales con fecha de publicación, series macroeconómicas revisadas y clasificaciones societarias. Incluir los tickers desaparecidos no basta si faltan rendimientos de exclusión, composición histórica o un tratamiento correcto de las operaciones de capital.
Causalidad: saber, decidir, ejecutar
Hay que distinguir disponibilidad del dato, finalización de la señal, envío y aceptación de la orden, y eventual fill. Una señal que exige el precio final de cierre no puede determinar una orden ejecutada en la subasta que acaba de producirlo. Participar exige una orden admitida con información ya disponible; un precio indicativo no es el final. Un fill posterior puede coincidir numéricamente con el cierre, pero sigue siendo posterior y no está garantizado.
La fecha de referencia de un dato económico no es la de publicación. Debe conservarse la versión disponible entonces y comprobar horario y retraso del feed: una fecha diaria de revisión no demuestra disponibilidad intradía.
En futuros, opciones, bonos, instrumentos en corto o apalancados también se necesitan reglas coherentes para vencimientos, rolls, multiplicadores, márgenes, ejercicio, asignación, préstamo de valores, colateral y rendimiento del efectivo. No existe un único modelo de fill válido para todas las clases de activos.
Protocolo mínimo reproducible
Esta checklist es una síntesis editorial operativa, no un protocolo universal ni una certificación regulatoria.
- Definir la pregunta. Escribir la hipótesis económica, el universo, la frecuencia, el periodo, el benchmark y el criterio con el que se juzgará el resultado.
- Congelar la especificación. Versionar señales, parámetros, sizing, restricciones, datos y calendario. Mantener un registro de todos los intentos, incluidos los fallidos.
- Construir el reloj de eventos. Ordenar disponibilidad de la información, decisión, envío, aceptación, posible cancelación y fill; declarar zona horaria y precisión de los timestamps.
- Simular la cartera. Aplicar límites de capital, apalancamiento, liquidez, rotación y concentración sin utilizar información futura.
- Estimar la ejecución. Declarar spread, comisiones, slippage, impacto, fills parciales, financiación y coste de oportunidad pertinentes.
- Medir sin elegir a posteriori. Informar del rendimiento neto, riesgo, drawdown, rotación, exposición, capacidad y comparación con el benchmark, junto con la incertidumbre estadística.
- Validar por separado. Reservar datos temporales no usados durante el desarrollo y establecer cómo se tratarán dependencia, labels solapadas, refits y pruebas finales.
- Archivar los artefactos. Conservar código, configuración, versiones de dependencias, semillas, snapshots recuperables de datos, sus hashes y resultados principales. Un hash identifica un archivo, pero no permite reconstruirlo por sí solo.
Costes y precios de referencia
Las comisiones y el spread son solo una parte del coste. Una simulación puede tener que considerar market impact, cantidad disponible, retraso, falta de ejecución, financiación, préstamo de valores, conversión de divisa y fiscalidad pertinente al perímetro declarado. El implementation shortfall compara la ejecución con la intención en el momento de la decisión y puede incluir también la parte no ejecutada; no equivale a añadir una comisión fija al final del cálculo.
Cuando los datos lo permitan, el modelo de costes debería depender del lado, tamaño, liquidez, volatilidad, venue y tipo de orden. Un escenario con costes más severos aporta información, pero no repara datos contaminados ni fills imposibles.
Si spread o slippage ya están incluidos en los precios de los fills simulados, no deben restarse otra vez como costes separados. Debe declararse qué incluye el precio y qué se cobra aparte.
Ejemplo ilustrativo
Ejemplo declarado como ilustrativo, no como resultado operativo — Una regla diaria calcula su señal después del cierre. El protocolo usa componentes point-in-time, envía la orden en la sesión siguiente, simula fills usando solo la liquidez observable evento a evento, incorpora spread e impacto en los precios y carga comisiones por separado. Las métricas netas se comparan con un benchmark total return en la misma divisa. Si el investigador prueba doce variantes de lookback, las doce entran en el registro: no sería correcto presentar la única ganadora como hipótesis inicial.
El ejemplo no establece qué retardos o costes son adecuados para un mercado concreto. Muestra qué partes deben poder cuestionarse y recalcularse.
Cómo interpretar el resultado
Una curva ascendente no es una validación. Hay que preguntar si el rendimiento se concentra en pocos eventos, si cambia ante pequeñas perturbaciones razonables, si sobrevive a costes plausibles, si el benchmark se eligió ex ante y si la precisión estimada es compatible con la cantidad y dependencia de las observaciones. El número de trades no equivale automáticamente al número de observaciones independientes.
El backtest resulta más útil como instrumento de falsación y diagnóstico que como máquina para producir una predicción puntual. Un resultado negativo puede revelar una hipótesis incoherente; uno positivo convierte la estrategia en candidata a controles de robustez, validación out-of-sample y observación forward, no en una certeza.
Limitaciones
- El pasado observado puede no contener crisis, regímenes o microestructuras futuras.
- La calidad aparente depende del número de modelos y parámetros explorados.
- El slippage y el impacto son contrafactuales y ganan incertidumbre con el tamaño.
- Repetir el proceso con el mismo código y los mismos datos comprueba la reproducibilidad; no constituye una replicación independiente.
- Monte Carlo y stress tests describen escenarios construidos: no eliminan look-ahead, survivorship bias, data snooping ni errores de especificación.
Fuentes
Fuentes verificadas el 8 de septiembre de 2026; se indican los pasajes consultados.
- Halbert White, A Reality Check for Data Snooping, Econometrica, 2000 — abstract del editor: reutilización de datos y comparación con benchmark.
- Robert D. Arnott, Campbell R. Harvey & Harry Markowitz, A Backtesting Protocol in the Era of Machine Learning — copia del autor, Duke, versión del 29 de octubre de 2018, pp. 8–10: motivación, intentos, correlaciones y selección de muestra.
- Marcos López de Prado, What to Look for in a Backtest — 2013, abstract: número de intentos y duración; no se revisaron todas las diapositivas.
- André F. Perold, The Implementation Shortfall: Paper Versus Reality — 1988, referencia original; definición contrastada en Summary de CFA Institute, Trade Strategy and Execution.
- European Commission, Regulation (EU) 2017/589, RTS 6 — artículos 5–7: metodología, cambios y entornos de prueba en el ámbito regulatorio aplicable.
- Federal Reserve Bank of St. Louis, ALFRED Help — secciones Release Dates: versiones históricas y fechas de disponibilidad.
- NYSE, Opening and Closing Auctions — p. 2: admisión de órdenes y subasta de cierre.