Sistema de trading sistemático

Qué es realmente un sistema de trading sistemático

Un sistema de trading sistemático es un conjunto de reglas explícitas y escritas que decide cuándo abrir, dimensionar y cerrar posiciones, junto con un proceso que aplica esas reglas de forma coherente. Su rasgo definitorio no es la automatización en sí, sino la trazabilidad: cada decisión puede vincularse a una regla escrita de antemano. Unas reglas ejecutadas a mano pueden ser sistemáticas, mientras que una herramienta automatizada que ejecuta una lógica que nadie sabe explicar no lo es en un sentido relevante.

Antes de actuar con un sistema así, la pregunta útil no es tanto si funciona, sino si puedes ver lo que hace, acotar lo que puede perder y reproducir cómo se evaluó. Este artículo es educativo y no constituye asesoramiento de inversión. Nada de lo que aquí se dice sugiere que algún enfoque vaya a ser rentable, y ni los resultados históricos ni los simulados determinan lo que ocurrirá después.

Las capas de un sistema de trading sistemático

Conviene dividir el sistema en capas, porque cada una puede fallar de forma independiente. Una lógica de señales limpia no sirve de nada si la fuente de datos entrega precios desactualizados, y un buen modelo de riesgo es irrelevante si la ejecución envía órdenes que el modelo nunca aprobó.

IMRYN, cuyo material público describe una infraestructura de trading basada en reglas que enruta entre varios mercados dentro de unas salvaguardas y bajo monitorización continua, enmarca estos conceptos en sus páginas de metodología y arquitectura. Tómalo como contexto para el vocabulario utilizado aquí, no como una afirmación de que algún diseño elimine el riesgo.

• Datos: precios, posiciones e información de referencia, con marcas de tiempo
• Señal: las reglas que generan intenciones de operación
• Dimensionamiento: cuánto operar según el capital y los límites
• Riesgo: comprobaciones independientes que pueden rechazar o detener
• Ejecución: enrutamiento de órdenes, ejecuciones y conciliación
• Monitorización: alertas, registros y las personas que responden

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

Los límites de riesgo deben ser cifras concretas que el sistema hace cumplir, no intenciones. Entre las categorías habituales están el tamaño máximo de posición por instrumento, la exposición bruta y neta máxima, un umbral de pérdidas que detiene la operativa durante el día o la semana y límites al ritmo de envío de órdenes. La propiedad clave es que los límites estén fuera de la lógica de la estrategia, de modo que ni un error de código ni un régimen de mercado inesperado puedan anularlos.

Un punto débil habitual son los límites que existen sobre el papel pero solo se comprueban a posteriori. Pregunta en qué punto del flujo se aplica cada límite, qué ocurre cuando se incumple (rechazar, reducir o detener) y a quién se avisa. Si la respuesta es que la estrategia está diseñada para no hacer eso, el límite no es explícito.

Ejecución observable y supervisión humana

La ejecución es donde los supuestos del modelo se encuentran con la realidad del mercado. Las ejecuciones difieren de los precios previstos, los mercados rechazan órdenes, las ejecuciones parciales dejan posiciones no deseadas y la latencia cambia los resultados. Una ejecución observable significa que cada orden, modificación, ejecución y rechazo queda registrado con su marca de tiempo y la regla que lo desencadenó, para que una persona pueda reconstruir el comportamiento tras cualquier incidente. Enrutar entre varios mercados añade más lugares donde pueden ocultarse discrepancias, lo que hace imprescindible conciliar las posiciones previstas con las reales.

La supervisión humana no significa aprobar cada operación. Significa que hay personas designadas con autoridad para pausar el sistema o cerrar todas las posiciones, umbrales de escalado claros y alertas que llegan a alguien capaz de actuar. La autonomía es más segura cuando está acotada: el sistema actúa dentro de unos límites y las personas son responsables de decidir si cambian esos límites o si se reanuda la operativa tras una parada.

La evaluación reproducible y sus límites

Los backtests y las simulaciones son útiles para detectar fallos evidentes, pero son hipótesis y no pruebas de resultados futuros. Una evaluación reproducible significa que otra persona podría volver a ejecutar la prueba con la misma versión de datos, la misma versión del código, los mismos supuestos de costes y los mismos parámetros, y obtener las mismas cifras. Sin eso, no puedes saber si un resultado refleja las reglas o una configuración afortunada.

Entre las distorsiones habituales están el sesgo de anticipación (look-ahead), el sesgo de supervivencia en el universo de instrumentos, unos costes y un deslizamiento poco realistas y el ajuste repetido sobre los mismos datos hasta que algo parece bueno. Incluso una evaluación cuidadosa solo muestra cómo se comportaron las reglas en condiciones pasadas. La liquidez varía, los regímenes cambian y una estrategia puede dejar de funcionar sin que haya ningún error en el código.

Ejemplo de lista de comprobación antes de usar un sistema de trading sistemático

Lo siguiente es una ilustración hipotética, no una recomendación. Imagina a un lector que evalúa un sistema de seguimiento de tendencia. Antes de comprometer nada, responde a cada pregunta de la lista con sí, no o desconocido. Cualquier no en los límites de pérdidas o en las paradas obliga a detenerse; varios desconocidos significan que la evaluación no está terminada.

Supongamos que el lector encuentra registros de ejecución exhaustivos, pero ningún límite estricto de pérdidas diarias. La conclusión sensata no es que el sistema sea malo, sino que su protección más importante no está verificada, por lo que la decisión debe esperar. Actuar o no depende de circunstancias personales que solo el lector, quizá con un asesor cualificado, puede valorar.

• ¿Hay un umbral de pérdidas documentado que detenga la operativa automáticamente?
• ¿Se aplican los límites de posición y exposición antes de enviar las órdenes?
• ¿Puedo ver registros de órdenes, ejecuciones y rechazos con la regla que los desencadenó?
• ¿Quién puede pausar el sistema y con qué rapidez?
• ¿Se puede reproducir el backtest a partir de las versiones declaradas de datos, costes y código?
• ¿Están los resultados simulados claramente separados de los resultados reales?
• ¿Sé en qué condiciones se espera que la estrategia funcione mal?
• ¿Podría asumir la pérdida de todo el importe comprometido?