Arquitectura de un sistema de trading algorítmico

Un sistema de trading algorítmico puede parecer un conjunto de módulos separados: carga de datos, estrategia, backtesting, ejecución, gestión del riesgo, logs, monitoreo. Pero en la operación real lo importante no es la lista de componentes, sino las fronteras entre ellos. Justo en esas fronteras suele romperse la conexión entre una investigación convincente y el mercado real.

La misma idea pasa por varios entornos: research, backtest, paper trading y production. Si cada entorno usa datos distintos, reglas de ejecución distintas y controles de riesgo distintos, el sistema prueba una estrategia y opera otra. La arquitectura importa no por el diagrama, sino por la reproducibilidad: la señal, el tamaño de la posición, la revisión de límites y el envío de la orden deben conservar el mismo significado desde la hipótesis hasta el capital en vivo.

Por eso una buena arquitectura de trading se parece menos a un "modelo inteligente" y más a un circuito de ingeniería con contratos claros. Los datos deben llegar en un formato verificable. La estrategia debe generar una decisión, no hablar directamente con la bolsa. El backtest debe modelar las restricciones de la ejecución real. El execution engine debe conocer el estado de las órdenes, no solo enviar solicitudes HTTP. El risk management debe estar antes de la operación, después de la operación y por encima de todo el sistema.

Data ingestion: la capa de entrada del mercado

Data ingestion no significa "descargar velas". Es la capa que convierte el mercado externo en un flujo interno de eventos: operaciones, actualizaciones del libro de órdenes, candles, funding, estado de instrumentos, comisiones, restricciones de negociación y, si hace falta, noticias o eventos corporativos.

La tarea principal de esta capa es no perder el significado de los datos durante la normalización. Las bolsas difieren en símbolos, precisión de precio y cantidad, timestamps, tipos de órdenes, límites de solicitudes y reglas de agregación. Incluso una simple vela puede tener límites de intervalo distintos, una política distinta para barras vacías y un tratamiento diferente de correcciones tardías. Si esas diferencias se ocultan demasiado pronto, la estrategia recibe una tabla limpia que ya no corresponde a un venue concreto.

Por eso conviene separar raw layer y normalized layer. El raw layer guarda los mensajes originales o una representación lo más cercana posible: qué llegó, cuándo llegó, de qué fuente, con qué sequence number o update id. El normalized layer lleva los datos al modelo interno: symbol ids unificados, timestamps, tipos de eventos, precios, volúmenes y estado de calidad.

En datos en streaming, los gaps y el orden de los eventos son especialmente importantes. La documentación de Coinbase advierte explícitamente que los sequence numbers pueden indicar mensajes perdidos o llegados fuera de orden, y que el consumidor debe poder restaurar el estado correcto. 6 Binance describe un procedimiento separado para mantener un order book local: primero WebSocket, luego un snapshot REST, después aplicar los depth events almacenados por update id. 5 No es un detalle técnico menor. Es parte del modelo de trading: si el libro se reconstruye mal, la ejecución y el slippage se calculan sobre liquidez imaginaria.

Base de datos y almacenamiento

En un sistema de trading normalmente no existe una sola "base de datos para todo". Hay varias clases de almacenamiento, y mezclarlas es peligroso.

La primera clase es el market data store. Sirve para cotizaciones históricas, operaciones, datos del libro de órdenes, funding, datos de referencia de instrumentos y todos los datos sobre los que se construyen research y backtest. Aquí importan la lógica append-only, el versionado, el control de huecos, la posibilidad de reconstruir velas desde un nivel más bajo y saber con qué versión de la historia se obtuvo un resultado concreto.

La segunda clase es el operational state. Incluye órdenes, ejecuciones, posiciones, saldos, cash movements, comisiones, errores de API, estado de límites de riesgo y eventos internos del sistema. Estos datos no sirven solo para informes, sino también para la reconciliación: ¿coincide la visión del sistema con lo que ve la bolsa o el bróker?

La tercera clase son los research artifacts: parámetros de estrategias, resultados de optimización, ventanas walk-forward, informes de métricas y conjuntos de experimentos. No deberían guardarse como CSV anónimos llamados "final_v3". Si un resultado de backtest no puede vincularse a la versión de datos, el código de la estrategia, los parámetros y el modelo de costes, no puede reproducirse. Y si no puede reproducirse, no debería llegar a production.

Strategy engine

El strategy engine convierte datos y estado en intención de trading. En una buena arquitectura, la estrategia no envía una orden directamente a la bolsa. Dice: con este estado de mercado, cartera y riesgo, quiero esta exposición, esta posición objetivo o este conjunto de órdenes.

Esta separación puede parecer formal, pero protege al sistema de una confusión central: señal y ejecución son tareas distintas. La señal responde "qué quiero hacer". La ejecución responde "cómo se puede hacer esto de forma segura y realista en un venue concreto". Si la estrategia conoce la API de la bolsa, calcula límites y procesa partial fills por sí misma, se vuelve casi imposible trasladarla de forma honesta del backtest al live.

Conviene diseñar el strategy engine como una capa determinista. El mismo input debe producir la misma decisión. Si hay aleatoriedad, debe fijarse explícitamente mediante seed, versión del modelo o estado. Si se usan modelos de ML, deben acompañarse de versión de features, versión del modelo, momento de entrenamiento y prohibición de datos que aún no habrían estado disponibles en el momento de decidir.

El contrato práctico es simple: la estrategia recibe solo los datos que habrían estado disponibles en ese momento y no sabe si su decisión se ejecutará en backtest, paper trading o production. Así, el mismo strategy engine puede comprobarse en distintos entornos sin reescribir la lógica.

Backtesting engine

El backtesting engine no existe para mostrar una equity curve bonita. Existe para comprobar una hipótesis en condiciones lo más cercanas posible a la ejecución futura. Cuantas más suposiciones estén escondidas dentro del backtest, mayor es el riesgo de que el sistema se optimice para el simulador y no para el mercado.

El primer requisito es la ausencia de look-ahead bias. La estrategia no debe ver un close futuro, correcciones tardías de datos, una composición del universe que solo se conoce hoy o corporate actions aplicadas como si se hubieran conocido de antemano. El segundo requisito es un modelo honesto de costes: comisiones, spread, slippage, funding, borrow cost, market impact y restricciones de liquidez. El tercero es la secuencia correcta de eventos: señal, revisión de límites, colocación de orden, ejecución, actualización de posición, registro del resultado.

Un backtest vectorizado es cómodo para research, pero suele modelar mal la cola de eventos. Un backtest event-driven es más lento, pero está más cerca de production: obliga a la estrategia a vivir en el mismo orden de eventos en el que operará. Para estrategias de medio plazo, el enfoque vectorizado puede bastar. Pero para sistemas intraday, basados en order book o sensibles a la ejecución, sin modelo de eventos es fácil obtener un resultado que no sobrevive al primer lanzamiento en una bolsa real.

La sobreoptimización es un problema aparte. Bailey, Borwein, López de Prado y Zhu describen el backtest overfitting como una situación en la que una estrategia se selecciona mediante una simulación histórica y luego se degrada fuera de la muestra; proponen estimar la probabilidad de sobreajuste con procedimientos especiales de cross-validation para backtests de inversión. 7 La conclusión arquitectónica es simple: el backtesting engine debe guardar no solo el "mejor resultado", sino también la huella de los experimentos, para que se vea cuántas variantes se probaron antes de que apareciera una curva atractiva.

Execution engine

El execution engine es la capa que convierte la intención de trading en órdenes reales. Trabaja en un mundo mucho más sucio que el strategy engine: latencias, solicitudes repetidas, ejecuciones parciales, cancelaciones, rechazos, rate limits, desincronización de posiciones, distintos tipos de órdenes y distintos estados de una misma orden del lado de la bolsa.

Un execution engine mínimo debe poder gestionar el ciclo de vida de la orden: created, submitted, acknowledged, partially filled, filled, cancelled, rejected, expired. Necesita idempotencia: repetir una solicitud después de un timeout no debe abrir por accidente una posición duplicada. Necesita reconciliación: si el sistema cree que una orden fue cancelada pero la bolsa muestra un fill, debe prevalecer la fuente externa de verdad.

En mercados institucionales, FIX suele ser la frontera estándar. FIX Trading Community describe el FIX Protocol como un estándar global y abierto para intercambiar información de trading: órdenes, ejecuciones y market data, independiente de un transporte concreto. 3 En infraestructura cripto son más comunes las API REST y WebSocket de cada venue, pero la tarea de ingeniería es la misma: separar el modelo interno de orden del protocolo externo.

Una buena práctica es construir la ejecución mediante adaptadores. Dentro del sistema hay un OrderIntent, OrderState, Fill y Position unificados. Fuera están Binance, Coinbase, un gateway FIX de bróker o una sandbox. Así la estrategia y la capa de riesgo no se reescriben para cada venue, y las diferencias específicas del venue permanecen en el adaptador de ejecución.

APIs de bolsas como frontera externa

Una API de bolsa no es solo transporte. Es la frontera externa del sistema, donde aparecen authentication, rate limits, límites de suscripciones WebSocket, reglas de heartbeat, latencias, ventanas de mantenimiento, formatos de error distintos y cambios repentinos de comportamiento.

La documentación de Binance, por ejemplo, separa REST market data endpoints y WebSocket streams, especifica límites de mensajes entrantes, lógica ping/pong y el procedimiento para restaurar un order book local. 4 Coinbase describe por separado endpoints de production y sandbox, canales de suscripción, heartbeat, sequence numbers y la necesidad de manejar gaps. 6 Estos detalles afectan directamente a la arquitectura: ingestion debe poder recuperarse, execution debe distinguir un reject de un timeout, y monitoring debe detectar la pérdida de heartbeat antes de que la estrategia empiece a decidir con datos obsoletos.

La fragmentación es especialmente visible en cripto. El mismo par en distintos venues puede tener comisiones, profundidad, tick size, min order size, velocidad de actualización y comportamiento ante paradas de trading diferentes. Por eso la capa API no debe filtrarse hacia la estrategia. La estrategia puede saber que trabaja con un instrumento y liquidez disponible; pero reglas concretas de LOT_SIZE, la firma de una solicitud o el formato de una cancel response deben vivir más abajo.

Risk management como circuito transversal

El risk management no debería ser el último módulo al final del pipeline. En un sistema de trading, el riesgo debe ser un circuito transversal: antes de la operación, durante la ejecución, después de la operación y a nivel de todo el sistema.

Los pre-trade risk checks responden preguntas como: ¿la orden supera el límite de tamaño?, ¿viola la max position?, ¿hay saldo o margin suficiente?, ¿se superó el límite diario de pérdida?, ¿el instrumento está deshabilitado?, ¿los datos están obsoletos?, ¿se perdió la conexión con la bolsa? Los post-trade checks verifican la posición real, PnL, comisiones, exposure, concentración y desviación respecto al estado esperado.

La práctica regulatoria lleva tiempo formalizando estos requisitos. Las guidelines de ESMA sobre automated trading exigen a las investment firms sistemas y controles eficaces, incluidos pre-trade y post-trade controls, pruebas de algoritmos, gestión de accesos y procedimientos ante fallos. 1 La SEC Rule 15c3-5 exige a los broker-dealers con market access mantener un sistema de risk controls y supervisory procedures para limitar los riesgos financieros y regulatorios del market access. 2

Para una aplicación como ai-trader, la conclusión práctica no es imitar un documento regulatorio, sino hacer que la capa de riesgo sea una parte obligatoria del camino de la orden: una señal no se convierte en orden hasta pasar los límites, y una superación de drawdown, una discrepancia de posición o la pérdida de market data deben poder detener el trading sin intervención humana.

Logging

El logging en un sistema de trading no es un flujo de mensajes que dicen "algo ocurrió". Es un audit trail que permite reconstruir por qué el sistema tomó una decisión, qué input vio, qué risk check pasó la orden, qué se envió a la bolsa y qué respuesta volvió.

Los logs deben conectar eventos mediante identificadores trazables: signal id, decision id, order id, exchange order id, fill id, strategy version, data version. Sin esa conexión, la investigación se convierte en una búsqueda manual por tiempo, y el tiempo en sistemas de trading suele ser imperfecto: distintos servicios pueden tener clocks distintos, y los eventos pueden llegar en un orden diferente del de creación.

Es importante registrar no solo errores. También hacen falta las decisiones correctas: por qué la estrategia no entró, por qué la capa de riesgo rechazó una orden, por qué execution eligió una limit order en vez de una market order, por qué se redujo la posición. La ausencia de una operación a veces es más importante que la operación misma, sobre todo al comparar el resultado live con el backtest.

Al mismo tiempo, el logging no debe convertirse en una nueva fuente de riesgo. Los secretos de API, claves privadas y authentication payloads completos no pertenecen a los logs. Para production hacen falta niveles de logging, enmascaramiento de campos sensibles, almacenamiento separado de eventos de auditoría y una política clara de retention.

Monitoring

Monitoring no responde a la pregunta "qué ocurrió en los logs", sino "si el sistema está funcionando ahora dentro de un régimen aceptable". Esa es la diferencia entre investigación histórica y control operativo.

En la práctica SRE, el monitoreo se construye alrededor de síntomas visibles para el usuario o para el sistema, no solo alrededor de causas internas; el Google SRE Book subraya la importancia de métricas, alertas y señales que reflejan el estado real del servicio. 8 Para un sistema de trading, esos síntomas son freshness market data, latency ingestion-to-signal, latency signal-to-order, tasa de reject, diferencia entre posición local y posición en la bolsa, errores de reconciliación, stale orders, heartbeat, drawdown, exposure y live-vs-backtest drift.

Un mal monitoreo dice "la API devolvió un error". Un buen monitoreo dice "la estrategia sigue tomando decisiones, pero los market data de este instrumento no se actualizan desde hace 40 segundos" o "la posición local difiere de la posición en la bolsa después del último fill". Lo primero es solo un evento. Lo segundo es un estado en el que el sistema debería degradarse, detenerse o pasar a safe mode.

Las alertas sobre silencio son especialmente importantes. Si un servicio falla ruidosamente, es más fácil notarlo. Si un WebSocket deja de enviar actualizaciones, pero el proceso sigue vivo y la estrategia continúa leyendo un state antiguo, el error parece operación normal. Por eso monitoring debe observar no solo exceptions, sino también frescura de datos, velocidad de eventos e invariantes de estado.

Paper trading y production: un solo camino de código, circuitos distintos

El paper trading solo es útil cuando prueba el mismo camino que irá a production. Si el paper environment es una implementación simplificada separada, donde las órdenes se "ejecutan" inmediatamente al último precio, prueba más la interfaz que el sistema de trading.

Es mejor mantener un solo camino de señal: data ingestion, strategy engine, risk checks, order intent, execution adapter, order state, fills, positions, logs, monitoring. La diferencia entre paper y production debe estar en el adaptador de ejecución y en la fuente de confirmaciones. En el paper adapter, el fill se simula con un modelo definido. En el production adapter, el fill llega de la bolsa o del bróker. El resto del sistema debe ver los mismos tipos de eventos.

Este enfoque permite un staged rollout. Primero la estrategia pasa por historical backtest. Luego paper trading con live data comprueba frescura de datos, orden de eventos, límites de riesgo y operational behavior. Después se pueden activar tamaño mínimo de posición, universe limitado, límites más estrictos y monitoring reforzado. Production trading no es un gran interruptor, sino una retirada gradual de restricciones a medida que el sistema demuestra que su comportamiento live se parece al esperado.

Incluso así, paper trading no es una prueba de rentabilidad. No reproduce la cola completa de órdenes, el market impact ni el estrés de liquidez. Su tarea es más modesta y más útil: comprobar que el circuito de trading no se separa de la realidad antes de que el error empiece a costar dinero.

Conclusión

La arquitectura de un sistema de trading algorítmico no empieza con la elección de un framework ni con el modelo de señal. Empieza con una pregunta: ¿puede la misma lógica recorrer el camino desde los datos hasta la orden sin cambiar de significado?

Data ingestion se asegura de que el mercado esté representado de forma honesta. El almacenamiento aporta reproducibilidad. El strategy engine separa la idea de la ejecución. El backtesting engine comprueba la hipótesis teniendo en cuenta restricciones reales. El execution engine gestiona el ciclo de vida de las órdenes. Los exchange adapters aíslan el caos de las API externas. El risk management limita el daño antes de que sea irreversible. Logging da memoria al sistema; monitoring le da visión operativa. Paper trading conecta research y production sin un salto a ciegas.

Un sistema sólido no tiene que ser complejo. Pero debe tener fronteras claras, invariantes verificables y un único camino de decisión. De lo contrario, una estrategia puede parecer funcional en research, mientras que en realidad no opera el mercado, sino un conjunto de supuestos arquitectónicos.