Especificación de una estrategia sistemática

La especificación de una estrategia sistemática es el documento versionado que describe una estrategia antes de evaluarla: propósito, hipótesis, información permitida, transformaciones, señales, posiciones, riesgo, órdenes, costes, benchmark, controles y criterios de revisión. Es a la vez un contrato de investigación, una interfaz entre investigación y producción y un registro de auditoría.

Una frase como «comprar la ruptura con volumen» no es una especificación. Deja sin definir el universo, el calendario, los ajustes, la longitud de la ventana, la inclusión de la barra actual, el momento del cálculo, el primer precio ejecutable, el tamaño, la salida, la gestión de gaps y el comportamiento ante datos ausentes. Cada ambigüedad permite que el backtest incorpore decisiones retrospectivas que no habrían estado disponibles en tiempo real.

Bloques mínimos

Los campos pueden residir en texto, configuración y código, siempre que puedan conciliarse. Las unidades deben ser explícitas: porcentaje de capital, nocional, volatilidad, delta, divisa y frecuencia no son intercambiables.

El reloj causal

La especificación debe ordenar al menos cuatro momentos:

«Precio de cierre diario» no es suficiente. El cierre oficial puede conocerse solo después de la subasta; un dato fundamental puede referirse a un trimestre pero hacerse público semanas más tarde; una serie macroeconómica puede ser revisada. Si la señal utiliza el cierre y el backtest compra a ese mismo cierre, debe existir un mecanismo explícito que permita participar en la subasta con la información necesaria. Sin ese mecanismo, el primer precio posterior es una elección más coherente, aunque también debe modelar gaps y costes.

Para cada dato de entrada resultan útiles al menos tres fechas: el periodo económico de referencia, la publicación inicial y la versión o vintage utilizada. Cada orden necesita un estado, una marca temporal o timestamp, la cantidad solicitada, la cantidad ejecutada, el precio y el motivo de rechazo o cancelación.

Estados y excepciones

Una estrategia real no vive únicamente en la rama «señal presente → orden ejecutada». La especificación establece qué sucede cuando:

• faltan datos o llegan tarde;
• un instrumento se suspende, deja de cotizar o cambia de identificador;
• un contrato de futuros entra en su ventana de roll;
• el préstamo de valores no está disponible o su coste supera el límite;
• una orden se ejecuta parcialmente, se rechaza o continúa abierta al final de la sesión;
• el precio, la posición, el margen o el P&L no concuerdan;
• un control de riesgo o la conexión con el bróker deja de responder.

«No hacer nada» es una regla válida solo cuando se especifica el estado resultante: mantener la posición anterior, reducirla, liquidarla o bloquear nuevas órdenes genera riesgos diferentes.

Protocolo de investigación conectado

Antes de observar el resultado destinado a respaldar una decisión, el protocolo registra:

1. la pregunta y la hipótesis falsable;
2. la versión de la especificación y el repositorio del código;
3. el conjunto de datos, el perímetro temporal y el universo;
4. una referencia sencilla y un benchmark coherente;
5. las métricas principales y secundarias, brutas y netas;
6. el diseño in-sample, de validación y de prueba final;
7. el conjunto de parámetros o modelos candidatos;
8. los supuestos de costes, liquidez y capacidad;
9. el criterio para continuar, modificar o rechazar la estrategia;
10. un registro de todos los intentos, incluidos los resultados negativos.

Un criterio no tiene que ser un único umbral. Puede exigir coherencia económica, un signo estable entre segmentos, incertidumbre aceptable, materialidad neta y ausencia de dependencia de un solo dato o variante. La elección debe ajustarse al uso: una herramienta exploratoria interna y una estrategia que despliega capital tienen consecuencias diferentes.

Versiones, reproducibilidad y replicación

Cada resultado debe identificar el commit o la versión del código, el archivo de configuración, el entorno y las dependencias, las semillas aleatorias, la versión del conjunto de datos y el resultado generado. Una instantánea o un hash ayuda a demostrar que la entrada no ha cambiado. Ejecutar de nuevo el mismo código sobre los mismos datos se refiere a la reproducibilidad; obtener evidencia coherente a partir de una realización independiente se refiere a la replicación. Ambas propiedades están relacionadas, pero no son equivalentes.

Cuando una prueba out-of-sample motiva una modificación, comienza una nueva versión. El segmento ya inspeccionado no vuelve a quedar incontaminado: debe registrarse como información de desarrollo. Esta genealogía evita que las iteraciones sucesivas acumulen data snooping invisible.

Separar funciones puede hacer más eficaz la revisión, pero «independiente» no significa necesariamente externo. Significa que quien cuestiona los supuestos, la implementación y el uso tiene los conocimientos, la autoridad y los incentivos para rebatir el resultado.

Ejemplo ilustrativo: una señal al cierre de la jornada

Una especificación hipotética indica que la señal utiliza solo datos consolidados hasta el cierre de t; se calcula después de recibir los archivos definitivos; las órdenes no pueden enviarse antes de la apertura de t+1. El universo se reconstruye a partir de su composición histórica; los instrumentos no negociables generan un estado de excepción; el tamaño respeta límites de participación y concentración; el coste depende del spread y de la cantidad.

El ejemplo no prescribe la apertura siguiente como una elección universalmente correcta. Muestra cómo hacer controlable la causalidad. Una estrategia que participe en la subasta de cierre necesitaría, en cambio, señales calculables antes de la hora límite y un modelo de ejecución coherente con esa subasta.

Criterios de calidad

• Un implementador independiente no debe tener que inventar una regla ausente.
• Cada variable tiene definición, unidad, marca temporal y comportamiento ante datos ausentes.
• Los resultados pueden rastrearse hasta una versión inmutable.
• Los supuestos de backtest y producción pueden compararse línea por línea.
• Las excepciones conducen a estados seguros y observables.
• Los límites están vinculados al riesgo, la capacidad o el uso previsto, no son cifras decorativas.
• Cada cambio material vuelve a abrir las comprobaciones pertinentes.

La especificación no elimina el riesgo de modelo. Sin embargo, hace visibles las elecciones y permite distinguir un error de investigación de un error de implementación o de uso.

Fuentes

• Joseph Simonian, CFA Institute Research Foundation, Investment Model Validation: A Guide for Practitioners — propósito, técnicas de validación, benchmarking, pruebas de estrés y documentación.
• Federal Reserve, SR 26-2 — Revised Guidance on Model Risk Management — principios vigentes de desarrollo, uso, validación, gobernanza y monitorización en el ámbito bancario supervisado.
• U.S. Securities and Exchange Commission, Staff Report on Algorithmic Trading in U.S. Capital Markets — contexto institucional de los algoritmos de decisión y ejecución y de sus riesgos.
• National Futures Association, Interpretive Notice 9025 — Hypothetical Results — limitaciones de los resultados hipotéticos y relevancia de los supuestos, la liquidez, el slippage y el comportamiento; su aplicación se limita a su propio ámbito.

Enlaces

• Trading sistemático: estrategias, backtesting y validación
• Trading cuantitativo y trading sistemático
• Backtest
• Datos point-in-time
• Monitorización y suspensión de estrategias