Einheitliches Datenmodell: Der Golden Record für Trading und Risk
In vielen Direktvermarktungsunternehmen existieren Handelsdaten in mehreren Versionen: Das ETRM-System hat eine Sicht auf die Positionen, das Risikomanagement eine andere, und die Abrechnung arbeitet mit einer dritten. Diese Inkonsistenzen sind nicht bösartig – sie entstehen organisch, wenn verschiedene Teams mit unterschiedlichen Systemen und Zeitständen arbeiten. Aber sie sind gefährlich: Wenn das Front Office eine andere offene Position sieht als das Risk Management, werden Limits falsch bewertet und Handelsentscheidungen auf falscher Grundlage getroffen.
Ein Golden Record löst dieses Problem durch eine einzige, autoritaative Datenbasis für alle Handels- und Risikodaten. Das Konzept bedeutet nicht, dass es nur ein System gibt – aber es gibt eine eindeutige Hierarchie: Welches System ist die Quelle für welche Datenart? Wie werden Änderungen propagiert? Wie schnell müssen nachgelagerte Systeme aktualisiert sein?
Kernprinzip: Jeder Datenpunkt hat genau einen Owner und genau eine führende Quelle. Trades werden im ETRM erfasst und von dort an Risk, Abrechnung und Reporting verteilt – nicht umgekehrt. Marktdaten kommen von einem zentralen Feed und werden versioniert gespeichert. Prognosedaten haben einen definierten Release-Prozess.
Versionierung von Prognosemodellen und Handelsstrategien
Prognosemodelle sind kein statisches Artefakt – sie werden kontinuierlich verbessert, umtrainiert und angepasst. Ohne eine systematische Versionierung wird es schnell unmöglich nachzuvollziehen, welches Modell zu welchem Zeitpunkt welche Prognose erzeugt hat. Das ist nicht nur ein akademisches Problem: Wenn ein Modell-Update zu einer schlechteren Prognose führt, muss das Team schnell auf die vorherige Version zurückrollen können. Und wenn ein Auditor fragt, auf welcher Grundlage eine bestimmte Handelsentscheidung getroffen wurde, muss die Antwort eindeutig sein.
- Model Registry: Zentrale Ablage aller Modellversionen mit Metadaten (Trainingsdata, Hyperparameter, Performance-Metriken, Freigabestatus).
- A/B-Testing-Framework: Neue Modellversionen werden parallel zur Produktionsversion getestet, bevor sie live gehen.
- Rollback-Fähigkeit: Jede Modellversion kann innerhalb von Minuten wiederhergestellt werden.
- Audit-Log: Lückenlose Dokumentation, wann welches Modell für welche Entscheidung verwendet wurde.
Dasselbe Prinzip gilt für Handelsstrategien: Wann wurde die Intraday-Strategie angepasst? Wer hat die Änderung freigegeben? Welchen Effekt hatte sie auf die Performance? Eine Git-basierte Versionierung für Strategiekonfigurationen und Modellcode schafft hier die nötige Transparenz.
Trennung von Front-, Middle- und Back-Office-Datenzugriff
Die organisatorische Trennung zwischen Front Office (Handel), Middle Office (Risikomanagement) und Back Office (Abrechnung, Settlement) ist nicht nur regulatorische Best Practice, sondern eine zentrale Säule der internen Kontrolle. Diese Trennung muss sich auch in den Datenzugriffsrechten widerspiegeln.
Konkret bedeutet das: Ein Trader darf Positionen eingeben und die eigene P&L sehen, aber nicht die Risikolimits ändern. Das Risk Management hat Lesezugriff auf alle Positionen, aber keinen Schreibzugriff auf das ETRM. Das Back Office sieht alle Daten für die Abrechnung, aber keine offenen Handelsstrategien. Diese Berechtigungsmatrix muss technisch durchgesetzt werden – nicht durch Konventionen, sondern durch systemseitige Zugriffskontrollen.
Dokumentation von Bewertungsmodellen für Auditoren
Direktvermarkter, die Termingeschäfte oder PPAs abschliessen, müssen ihre Bewertungsmodelle gegenüber Wirtschaftsprüfern dokumentieren können. Das betrifft insbesondere die Mark-to-Market-Bewertung offener Positionen, die Berechnung von Fair Values für langfristige Verträge und die Methodik der Prognosemodelle, die in die Bewertung einfliessen.
Die Dokumentationsanforderungen gehen über eine reine Modellbeschreibung hinaus: Auditoren wollen wissen, welche Marktdaten als Input verwendet werden, wie diese Daten beschafft und validiert werden, welche Annahmen in die Modelle einfliessen und wie sensitiv die Ergebnisse gegenüber Parametervariationen sind. Eine strukturierte Modelldokumentation – idealerweise automatisch aus dem Model Registry generiert – spart nicht nur Zeit bei der Prüfung, sondern erhöt auch das Vertrauen der Prüfer in die Ergebnisse.
Change Management bei ETRM-Systemwechsel
Der Wechsel des ETRM-Systems ist eines der riskantesten IT-Projekte für einen Direktvermarkter. Alle historischen Trades, offenen Positionen, Vertragsdaten und Konfigurationen müssen migriert werden – ohne Datenverlust und ohne Unterbrechung des laufenden Handels. Gleichzeitig ändern sich Prozesse, Schnittstellen und Berechtigungsstrukturen.
Ein strukturiertes Change Management für ETRM-Migrationen umfasst:
- Data Contracts: Formal definierte Schnittstellen zwischen dem ETRM und allen vor- und nachgelagerten Systemen. Diese Contracts stellen sicher, dass ein Systemwechsel die Integrationen nicht bricht.
- Parallelbetrieb: Altes und neues System laufen für einen definierten Zeitraum parallel, um Ergebnisse zu vergleichen und Differenzen zu identifizieren.
- Datenmigrations-Validierung: Automatisierte Checks, die nach der Migration prüfen, ob alle Positionen, Trades und Stammdaten korrekt übertragen wurden.
- Rollback-Plan: Ein klar definierter Plan, wie auf das alte System zurückgeschwenkt wird, falls kritische Probleme auftreten.
Technologien und Konzepte
Fazit: Ordnung als Grundlage für Geschwindigkeit
Es mag paradox klingen, aber organisatorische Strukturen und Governance verlangsamen den Handel nicht – sie beschleunigen ihn. Wenn klar ist, welche Daten führend sind, wer welche Änderungen vornehmen darf und wie Modelle versioniert werden, können Teams schneller und sicherer agieren. Ohne diese Strukturen bremsen Unsicherheit, manuelle Abstimmungen und Fehlersuche den Handelsalltag.
Für wachsende Direktvermarkter, die neue Märkte erschliessen, zusätzliche Bilanzkreise aufbauen oder ihr ETRM modernisieren wollen, ist eine solide Data Governance im Trading-Bereich die Voraussetzung dafür, dass das Wachstum nicht an der Dateninfrastruktur scheitert.