Qué es el trading algorítmico

¿Qué es el trading algorítmico en la práctica?

El trading algorítmico es el uso de programas informáticos para decidir, dimensionar y colocar órdenes según reglas predefinidas. En lugar de que una persona pulse comprar o vender, el software lee datos de mercado, aplica una lógica escrita de antemano y envía instrucciones a uno o varios mercados de negociación. Preguntar qué es el trading algorítmico es, en realidad, preguntar por esa cadena: quién escribió las reglas, qué puede hacer el programa y cómo puede cualquiera comprobar si hizo lo que se pretendía.

El término abarca actividades distintas. Algunos algoritmos solo se ocupan de la ejecución y reparten una orden grande en el tiempo para reducir el impacto en el mercado, como hacen los calendarios ponderados por tiempo o por volumen. Otros toman la propia decisión de trading con reglas de tendencia, reversión a la media o valor relativo. Lo que comparten es la automatización; lo que los distingue es cuánto criterio se ha delegado en el código.

Este artículo procede de IMRYN, que publica material educativo sobre infraestructura de trading sistemático y enrutamiento de órdenes entre varios mercados. Explica conceptos en lugar de recomendar ninguna estrategia, y nada de lo que aquí se dice constituye asesoramiento de inversión.

Los componentes que convierten una regla en una orden

Un sistema operativo suele tener cinco capas: recepción de datos de mercado, lógica de decisión, comprobaciones de riesgo, una capa de ejecución que se comunica con los mercados y monitorización. Los lectores suelen centrarse en la señal porque parece la parte ingeniosa, pero los fallos también pueden surgir en las uniones: datos desactualizados, una posición mal interpretada o un mercado que rechaza órdenes de una forma que el código no había previsto.

Cada capa necesita un contrato claro. La capa de datos debe saber cuándo las entradas llegan tarde o faltan. La capa de riesgo debe poder bloquear una orden sin importar lo que pida la señal. La capa de ejecución debe registrar lo que envió, lo que fue confirmado y lo que se ejecutó, para que ese registro pueda conciliarse con los informes del propio mercado.

• Datos: marcas de tiempo, huecos y origen de cada precio utilizado
• Decisión: reglas escritas con parámetros versionados
• Riesgo: límites estrictos comprobados antes de cada orden
• Ejecución: enrutamiento, tipos de orden y registros de ejecución por mercado
• Monitorización: alertas vinculadas a personas concretas que pueden actuar

La calidad de ejecución es donde la estrategia se encuentra con el mercado

Una regla que parece sólida sobre el papel puede perder dinero cuando aparecen los costes reales: diferenciales, comisiones, deslizamiento entre el precio previsto y el obtenido, y ejecuciones parciales. Cuando las órdenes se reparten entre varios mercados, cada uno añade su propia latencia, sus reglas y sus modos de fallo. Por eso importa una ejecución observable: cada orden debe dejar un rastro que muestre la intención, el momento y el resultado.

En la práctica, comprueba si un sistema compara los precios obtenidos con una referencia, como el precio de llegada o una media del periodo, y si esa comparación es visible para los responsables en lugar de quedar enterrada en los registros. Si la ejecución no puede inspeccionarse, no hay una forma fiable de distinguir una estrategia débil de una implementación débil.

Los límites de riesgo y la supervisión humana son decisiones de diseño

Los límites de riesgo explícitos son fronteras que el programa no puede cruzar: tamaño máximo de posición, pérdida máxima por sesión, topes de frecuencia de órdenes e instrumentos y mercados permitidos. Deben estar por escrito, aplicarse en el código antes de que salgan las órdenes y probarse. Un límite que solo existe en un documento de políticas no detiene una orden en bucle.

La autonomía es un espectro. Un sistema con salvaguardas puede actuar por sí solo dentro de unos límites mientras las personas lo vigilan de forma continua y conservan la autoridad para pausarlo, reducirlo o detenerlo. IMRYN plantea su enfoque en esos términos, acción automatizada dentro de controles de riesgo definidos con monitorización constante, y sus páginas públicas de metodología y arquitectura describen cómo traza esa frontera. Esa documentación describe los controles previstos; por sí sola no demuestra que funcionen en un entorno real concreto. Para cualquier sistema que evalúes, pregunta quién puede activar el control de parada, con qué rapidez y si se ha ensayado.

Evaluación reproducible: leer los backtests con cuidado

Los backtests y las simulaciones reproducen reglas sobre datos pasados. Son útiles para encontrar errores y entender el comportamiento, pero un resultado histórico o simulado solo describe cómo se comportó una regla en unas condiciones concretas; no establece lo que ocurrirá después. Las pruebas repetidas y el ajuste de parámetros pueden sobreajustarse a los datos históricos, una trampa bien conocida.

La evaluación reproducible significa que otra persona puede volver a ejecutar la prueba y obtener la misma respuesta: misma instantánea de datos, versión del código, supuestos de costes y parámetros. También significa separar los datos usados para diseñar una regla de los usados para juzgarla, y declarar abiertamente los supuestos de deslizamiento. Si un resultado no puede reproducirse, trátalo como una afirmación, no como una prueba.

Ejemplo práctico: una lista de comprobación antes de confiar en un algoritmo

Ejemplo (hipotético): un equipo pequeño estudia una regla automatizada que opera un contrato de futuros líquido y enruta órdenes a dos mercados. Antes de dejarla funcionar sin supervisión directa, responden por escrito a las preguntas siguientes. Cualquier «no» se convierte en una tarea que corregir, no en un riesgo que aceptar en silencio.

La lista no dice si la regla ganará dinero; dice si el equipo entenderá lo que ocurrió tanto si lo gana como si no. Ese es un umbral realista para confiar en un algoritmo: no confianza en los resultados, sino confianza en los controles y en el registro.

• ¿Están por escrito los límites de posición, pérdida y frecuencia de órdenes, y se aplican antes de cada orden?
• ¿Puede rastrearse cada ejecución hasta la señal, la versión de parámetros y los datos que la generaron?
• ¿Se compara el precio obtenido con una referencia declarada, por mercado y con una periodicidad fija?
• ¿Recibe las alertas una persona concreta, y puede pausar el sistema dentro de un plazo definido?
• ¿Puede volver a ejecutarse el backtest a partir de los datos y el código almacenados con resultados idénticos?
• ¿Se incluyeron en la evaluación los costes, el deslizamiento y un periodo fuera de muestra?