Les données pré-trade : la couche manquante de nombreuses architectures de trading

Lorsqu'on schématise une architecture technologique de trading, l'essentiel de l'attention se porte sur l'ETRM lui-même et sur ce qui se passe après la saisie d'un deal. Ce qui est souvent escamoté - alors même que c'est là que naissent une large part des problèmes aval - c'est la couche qui précède tout cela : les données pré-trade.

Ce que nous entendons par données pré-trade

Les données pré-trade regroupent tout ce qui doit atteindre votre écosystème trading et risque avant un deal précis ou indépendamment de lui : prix de marché, courbes forward, surfaces de volatilité, données météo et fondamentales, données de référence comme les contreparties et les calendriers. C'est la matière première sur laquelle se construisent la valorisation, le risque et jusqu'aux décisions de trading.

Le manque architectural courant

Dans un nombre surprenant d'environnements que nous avons audités, ces données circulent directement de l'API ou du flux fichier d'un fournisseur externe vers l'ETRM, avec peu ou pas de couche indépendante de validation, de normalisation ou de rapprochement entre les deux. L'ETRM devient de fait l'endroit où une donnée erronée est repérée pour la première fois - généralement parce qu'elle se manifeste par une valorisation fausse ou un prix manquant, bien après que le problème réel s'est produit en amont.

À quoi ressemble une vraie couche de données pré-trade

L'intérêt de cette couche n'est pas la complexité pour elle-même : c'est la séparation des responsabilités. L'ETRM doit pouvoir se fier au fait que les données qu'il reçoit ont déjà été validées et normalisées, plutôt que de devoir remettre en doute défensivement chaque prix entrant. Et lorsqu'un problème survient, disposer d'une couche dédiée permet de retracer exactement où dans le pipeline - source, ingestion, validation, mapping - il a été introduit.

Pourquoi cette couche est souvent escamotée

La plupart des sociétés de négoce ne décident pas d'écarter cette couche : elle manque par omission. Un flux direct est branché comme solution rapide sous la pression du calendrier, fonctionne correctement pendant des mois, et devient par défaut une infrastructure permanente. Quand les manques apparaissent enfin, la connexion directe est profondément ancrée et plus difficile à démonter qu'il n'aurait été de la construire correctement dès le départ.

Un point de départ concret

Il n'est pas nécessaire de refondre toute votre architecture de données d'un coup. Le point de départ au plus fort effet de levier consiste généralement à identifier vos deux ou trois sources de données les plus critiques pour l'activité - celles qui, si elles sont fausses, endommageraient le plus directement le P&L ou les décisions de risque - et à construire d'abord une véritable couche de validation et de normalisation autour d'elles.