Backtest

Simulación histórica de una estrategia con datos point-in-time, reglas causales, ejecución realista y control de sesgos antes de realizar inferencias.

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.

Motor de backtest: eventos y contabilidadLa curva final nace de una secuencia verificable de estados. Esquema event-driven ilustrativo; frecuencia, prioridad y contabilidad deben documentarse.Motor de backtest: eventos y contabilidadLa curva final nace de una secuencia verificable de estadosEsquema event-driven ilustrativo; frecuencia, prioridad y contabilidad deben documentarse.1Reloj y eventosOrdena datos, corporateactions, señales, órdenes yliquidación.2Snapshot de datosExpone al motor solo lainformación disponible en eseinstante.3Estado de estrategiaPosiciones, cash, margen yvariables persisten entreeventos.4Simulador de órdenesAplica latencia, validez,liquidez y reglas de filldeclaradas.5LedgerRegistra cantidades, precios,costes, flujos, marks yreconciliaciones.6DiagnósticoMétricas y logs permitenatribuir resultado y errores.Cyclepedia · diagrama didáctico condicionado, no previsión ni promesa
Un resultado histórico es el último eslabón de una cadena: datos, reloj de eventos, decisión, ejecución, costes y medición.

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

Cada evento debería tener, como mínimo, un momento de disponibilidad y otro de acción. Si el cierre de la barra entra en la señal, ejecutar a ese mismo cierre exige una especificación creíble de la subasta, del tiempo de cálculo y del envío de la orden; de lo contrario, el primer precio utilizable pertenece a un evento posterior. El mismo principio se aplica a comunicados, indicadores económicos y datos fundamentales: la fecha de referencia no coincide necesariamente con aquella en la que la información se hace pública.

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

  1. 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.
  2. Congelar la especificación. Versionar señales, parámetros, sizing, restricciones, datos y calendario. Mantener un registro de todos los intentos, incluidos los fallidos.
  3. Construir el reloj de eventos. Ordenar disponibilidad de la información, decisión, envío, posible cancelación y fill.
  4. Simular la cartera. Aplicar límites de capital, apalancamiento, liquidez, rotación y concentración sin utilizar información futura.
  5. Estimar la ejecución. Declarar spread, comisiones, slippage, impacto, fills parciales, financiación y coste de oportunidad pertinentes.
  6. 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.
  7. 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.
  8. Archivar los artefactos. Conservar código, configuración, versiones de dependencias, semillas, snapshots o hashes de datos y resultados principales.

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.

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, limita la participación en el volumen y carga spread, comisiones y un impacto creciente con el tamaño. 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

Páginas relacionadas