Pre-Trade-Daten: die fehlende Schicht in vielen Handelsarchitekturen

Wenn die Architektur einer Handelstechnologie skizziert wird, richtet sich die meiste Aufmerksamkeit auf das ETRM selbst und darauf, was nach der Geschäftserfassung passiert. Übersprungen wird häufig genau die Schicht, die davor liegt - obwohl dort ein großer Teil der nachgelagerten Probleme entsteht: die Pre-Trade-Daten.

Was wir unter Pre-Trade-Daten verstehen

Pre-Trade-Daten sind alles, was Ihr Handels- und Risikoökosystem vor einem konkreten Geschäft oder unabhängig davon erreichen muss: Marktpreise, Forward-Kurven, Volatilitätsflächen, Wetter- und Fundamentaldaten sowie Stammdaten wie Gegenparteien und Kalender. Sie sind das Rohmaterial, auf dem Bewertung, Risiko und selbst Handelsentscheidungen aufbauen.

Die typische architektonische Lücke

In einer überraschend großen Zahl der von uns geprüften Umgebungen fließen diese Daten direkt aus der API oder dem Datei-Feed eines externen Anbieters ins ETRM - mit wenig oder gar keiner unabhängigen Validierungs-, Normalisierungs- oder Abstimmungsschicht dazwischen. Damit wird das ETRM standardmäßig zu dem Ort, an dem schlechte Daten zuerst auffallen - meist als falsche Bewertung oder fehlender Preis, lange nachdem das eigentliche Problem weiter oben entstanden ist.

Wie eine saubere Pre-Trade-Datenschicht aussieht

Sinn dieser Schicht ist nicht Komplexität um ihrer selbst willen, sondern die Trennung von Verantwortlichkeiten. Das ETRM soll sich darauf verlassen können, dass die empfangenen Daten bereits validiert und normalisiert sind, statt jeden eingehenden Preis defensiv hinterfragen zu müssen. Und wenn doch etwas schiefgeht, lässt sich mit einer eigenen Schicht genau nachvollziehen, an welcher Stelle der Pipeline - Quelle, Erfassung, Validierung, Mapping - das Problem entstanden ist.

Warum diese Schicht übersprungen wird

Die wenigsten Handelsunternehmen entscheiden sich bewusst gegen diese Schicht - sie fehlt durch Unterlassung. Ein direkter Feed wird unter Zeitdruck als schnelle Lösung angebunden, funktioniert monatelang gut und wird stillschweigend zur dauerhaften Infrastruktur. Wenn die Lücken sichtbar werden, ist die direkte Verbindung tief verankert und schwerer zurückzubauen, als sie von Anfang an sauber zu bauen gewesen wäre.

Ein praktikabler Einstieg

Sie müssen nicht Ihre gesamte Datenarchitektur auf einmal neu bauen. Der wirkungsvollste Einstieg besteht meist darin, die zwei oder drei geschäftskritischsten Datenquellen zu identifizieren - jene, die im Fehlerfall P&L- oder Risikoentscheidungen am unmittelbarsten beschädigen würden - und zunächst um diese eine saubere Validierungs- und Normalisierungsschicht zu bauen.