Datos pre-trade: la capa que falta en muchas arquitecturas de trading

Cuando se dibuja la arquitectura tecnológica de un negocio de trading, casi toda la atención se dirige al propio ETRM y a lo que ocurre después de capturar una operación. Lo que suele pasarse por alto, pese a ser el origen de buena parte de los problemas posteriores, es la capa que se sitúa antes de todo eso: los datos pre-trade.

Qué entendemos por datos pre-trade

Los datos pre-trade son todo aquello que debe llegar a su ecosistema de trading y riesgo antes de una operación concreta o con independencia de ella: precios de mercado, curvas forward, superficies de volatilidad, datos meteorológicos y fundamentales, y datos maestros como contrapartes y calendarios. Son la materia prima sobre la que se construyen la valoración, el riesgo e incluso las decisiones de trading.

La carencia arquitectónica habitual

En un número sorprendente de entornos que hemos revisado, estos datos fluyen directamente desde la API o el fichero de un proveedor externo hasta el ETRM, con poca o ninguna capa intermedia independiente de validación, normalización o conciliación. El ETRM se convierte, por defecto, en el lugar donde se detectan por primera vez los datos erróneos, normalmente porque aparecen como una valoración incorrecta o un precio ausente, mucho después de que el problema real se produjera aguas arriba.

Cómo es una capa de datos pre-trade en condiciones

El sentido de esta capa no es añadir complejidad por sí misma, sino separar responsabilidades. El ETRM debería poder confiar en que los datos que recibe ya han sido validados y normalizados, en lugar de tener que cuestionar defensivamente cada precio entrante. Y cuando algo va mal, disponer de una capa dedicada permite rastrear exactamente en qué punto del pipeline (origen, ingesta, validación, mapeo) se introdujo el problema.

Por qué se omite esta capa

La mayoría de los negocios de trading no deciden deliberadamente prescindir de esta capa: simplemente se acumula por omisión. Se conecta un feed directo como solución rápida bajo presión de tiempo, funciona bien durante meses y acaba convirtiéndose en infraestructura permanente por inercia. Cuando las carencias afloran, la conexión directa está ya profundamente arraigada y resulta más difícil de desmontar de lo que habría sido construirla bien desde el principio.

Un punto de partida práctico

No hace falta reconstruir toda la arquitectura de datos de una vez. El punto de partida con mayor retorno suele ser identificar las dos o tres fuentes de datos más críticas para el negocio (aquellas que, si son erróneas, dañarían más directamente el P&L o las decisiones de riesgo) y construir primero una capa adecuada de validación y normalización en torno a ellas.