Trading cuantitativo sistemático

Qué es el trading cuantitativo sistemático y qué no es

El trading cuantitativo sistemático consiste en tomar decisiones de trading mediante reglas escritas, programadas y aplicadas de forma coherente, en lugar de mediante un juicio caso por caso. Las reglas suelen proceder del análisis estadístico de datos de mercado. Su propiedad definitoria es que las mismas entradas deberían producir siempre la misma decisión. Esa coherencia es la principal fortaleza del método y también el origen de la mayoría de sus riesgos.

Un proceso sistemático no es lo mismo que un proceso rentable, y no elimina la incertidumbre. Una regla puede aplicarse con disciplina perfecta y aun así ser errónea, porque los mercados cambian, los datos contienen errores y la ejecución rara vez coincide con lo que suponía un modelo. Antes de actuar con cualquier enfoque sistemático, la pregunta más útil no es si una regla parece buena sobre el papel. Es si todo el sistema que rodea a la regla puede acotarse, observarse, supervisarse y volver a probarse.

IMRYN publica material sobre infraestructura de trading y ejecución en varios mercados con fines educativos, no como asesoramiento de inversión. El resto de este artículo sigue el mismo enfoque. Aborda las preguntas operativas que debería plantearse un lector técnico y no valora si merece la pena seguir una estrategia concreta.

Los límites de riesgo explícitos van antes que la estrategia

En un esquema sistemático bien diseñado, los límites de riesgo se definen por escrito como restricciones estrictas que la estrategia no puede anular. Entre los límites habituales figuran el tamaño máximo de posición por instrumento, topes de exposición bruta y neta, una pérdida máxima por día o por periodo, límites de frecuencia de órdenes y comprobaciones de desviación de precio que rechazan órdenes alejadas de un precio de referencia. Lo importante es que estos límites sean explícitos y que los aplique la máquina. No deberían existir como expectativas informales en la cabeza de alguien.

Una prueba práctica consiste en preguntarse qué ocurre cuando la lógica de la estrategia falla. Si un error genera una serie de órdenes desproporcionadas, la capa de límites debería detenerlas con independencia de la intención de la estrategia. Los límites que solo comprueba la propia estrategia no son realmente controles independientes. La arquitectura debería separar la decisión de qué operar de la decisión de si una orden está permitida.

Los límites también necesitan responsables y un proceso de cambio. Alguien debería responder de cada umbral, los cambios deberían registrarse y relajar un límite debería exigir más escrutinio que endurecerlo. Sin esa disciplina, los límites tienden a subir tras los buenos periodos, que es justo cuando la complacencia sale más cara.

Ejecución observable: comparar la intención con la realidad

La decisión simulada de un modelo y la ejecución que realmente se produjo son dos sucesos distintos. El deslizamiento, las ejecuciones parciales, las órdenes rechazadas, la latencia, las caídas de los mercados y las diferencias de comisiones abren una brecha entre ambos. La ejecución observable significa que puedes ver esa brecha con claridad, para cada orden y casi en tiempo real. Lo ideal es poder reconstruir también después por qué se envió cada orden, adónde se dirigió y qué respuesta se recibió.

Cuando la ejecución abarca varios mercados, la observabilidad importa todavía más, porque el estado está repartido. Las posiciones, las órdenes abiertas y los saldos deben conciliarse con los registros propios de cada mercado, no solo con la visión interna del sistema. Un desajuste que pasa desapercibido durante horas puede convertir un pequeño error operativo en una exposición considerable.

Entre las señales útiles están la calidad de ejecución frente a una referencia definida, las tasas de rechazo y cancelación, el tiempo entre la decisión y la confirmación, y las discrepancias de conciliación. Vigilarlas de forma continua, con alertas vinculadas a umbrales claros, convierte la ejecución de una caja negra en algo sobre lo que una persona puede razonar.

Supervisión humana en un circuito automatizado

La automatización no elimina la necesidad de personas. Cambia lo que hacen. En un diseño con salvaguardas, el sistema actúa dentro de los límites que fijan las personas, y estas conservan la autoridad para pausarlo, anularlo o apagarlo. Las preguntas de diseño clave son quién puede intervenir, con qué rapidez y si está garantizado que la intervención funcione cuando otras partes del sistema están fallando.

Un kill switch que depende del mismo proceso que debe detener ofrece poca protección. Los mecanismos de supervisión deberían ser sencillos, probarse con regularidad y, en la medida de lo posible, ser independientes del código de la estrategia. Las vías de escalado deberían acordarse de antemano, para que nadie esté discutiendo responsabilidades en mitad de un incidente.

La supervisión también abarca decisiones tomadas fuera del circuito en vivo: aprobar nuevas estrategias, revisar incidentes y decidir cuándo debe retirarse un modelo. En estas revisiones es donde la evidencia acumulada sobre el comportamiento real debería retroalimentar los límites y el diseño.

Evaluación reproducible y los límites de los backtests

Los backtests y las simulaciones son útiles para descartar malas ideas, pero no pueden confirmar las buenas. Los resultados históricos, simulados o reales, no deciden lo que ocurrirá después. Entre los fallos habituales están el sesgo de anticipación, el sesgo de supervivencia, el sobreajuste a un periodo concreto y los supuestos poco realistas sobre costes y ejecuciones.

La reproducibilidad es el estándar mínimo. Con la misma versión del código, la misma instantánea de datos y la misma configuración, una evaluación debería producir el mismo resultado. Si no lo hace, nadie puede saber si un cambio en los resultados procede de la estrategia, de los datos o del entorno. Versionar los datos, fijar las dependencias y registrar los parámetros de cada ejecución lo hacen posible.

La evaluación también debería incluir pruebas de estrés y comprobaciones fuera de muestra. Algunos ejemplos son probar con periodos reservados durante el desarrollo, variar los supuestos de costes y examinar el comportamiento en ventanas históricamente volátiles. El objetivo no es obtener una cifra más atractiva. Es tener una imagen honesta de dónde falla el enfoque.

Ejemplo: una lista de verificación previa al despliegue

Lo siguiente es un ejemplo hipotético, no una recomendación ni la descripción de un despliegue real. Imagina un equipo que se prepara para pasar una estrategia sistemática de la simulación a una operación real a pequeña escala. Antes de empezar, podría recorrer una lista de preguntas de sí o no y tratar cualquier 'no' como motivo para esperar.

Esta lista ilustra los cuatro principios tratados anteriormente. Es un punto de partida que debe adaptarse a tus propias restricciones y a la normativa aplicable. No es un estándar de cumplimiento.

• Límites de riesgo: ¿están los límites de posición, exposición, pérdidas y frecuencia de órdenes definidos por escrito y aplicados fuera del código de la estrategia?
• Responsabilidad de los límites: ¿tiene cada límite un responsable designado y un historial de cambios registrado?
• Visibilidad de la ejecución: ¿puede rastrearse cada orden desde la decisión hasta la ejecución final, incluidos los rechazos y las respuestas de los mercados?
• Conciliación: ¿se concilian automáticamente las posiciones con cada mercado, con alertas ante discrepancias?
• Supervisión: ¿existe una forma probada e independiente de detener el trading, y saben las personas que pueden usarla cuándo hacerlo?
• Reproducibilidad: ¿puede volver a ejecutarse la última evaluación a partir de código, datos y configuración versionados y obtener el mismo resultado?
• Planteamiento honesto: ¿indica la documentación interna que los resultados simulados no predicen los resultados reales?