Trade Stores erfolgreich aufbauen

Die MiFID-II-Checkliste für Banken

| Autor / Redakteur: Stefano Marmonti* / Rainer Graefen

6 Checkpoints die Banken bei MiFID-II-Repositories einhalten sollten.
6 Checkpoints die Banken bei MiFID-II-Repositories einhalten sollten. (Bild: Rainer Graefen / Microsoft)

Demnächst treten Bestimmungen wie MiFID II und Dodd-Frank in Kraft. Die Gefahr ist groß, dass Banken unzureichend auf die neuen Anforderungen vorbereitet sind.

Aufsichtsbehörden verlangen, dass Banken in der Lage sind, Handelsvorgänge rekonstruieren können. Aber ohne geeignete Tools ist das ebenso unmöglich wie das Rekonstruieren der Traube, aus der der Champagner hergestellt wurde. Um schnell auf die strengen und ständig neuen regulatorischen Anforderungen reagieren zu können, müssen Banken dafür sorgen, dass ihre Daten zu Handelsvorgängen möglichst schnell abruf- und durchsuchbar vorliegen.

Ein Trade Store bietet eine integrierte, zuverlässige Referenzquelle, weil alle Daten zentral gespeichert werden und in einer konsolidierten Ansicht verfügbar sind. Das erleichtert Banken die Einhaltung bestehender und neuer Vorschriften. Durch die Zusammenführung großer Mengen an strukturierten und unstrukturierten Handelsdaten in einem zentralen Repository liegt zu jedem Handel ein einheitlicher, kontinuierlicher und transparenter Datensatz vor, der als vollständiger Audit-Vorgang für Buchprüfer und Regulierungsbehörden dient.

Was also sollte bei der Einführung eines Trade Stores auf der Checkliste stehen, um die sichere Aggregation der Risiko- und Finanzdaten zu gewährleisten?

1. SQL/NoSQL

SQL oder NoSQL - das ist hier die Frage: Banken und Finanzinstitute setzen sowohl SQL- als auch NoSQL-Datenbanken (Not Only SQL = nicht nur SQL) ein. Im heutigen Umfeld der vielfältigen Formate und umfangreichen Inhalte sind 80 Prozent aller Daten unstrukturiert. Bietet eine für strukturierte Daten konzipierte SQL-Datenbank wirklich noch die erforderliche Flexibilität?

Handelsdaten andern sich, sind vielfältig und komplex und daher nicht für das unflexible, schemabasierte relationale Modell geeignet. Jedes Handelssystem bringt ein neues Schema mit sich, sodass die Abstimmung der uneinheitlichen Datenfelder komplexe Schnittstellen erfordert. Bei jeder Veränderung – und Änderungen gibt es ständig – muss das alles erneut getestet und zumeist auch neu gestaltet werden.

Ein weiteres Problem bei relationalen Datenbanken ist die Notwendigkeit, die künftig erforderlichen Abfragen bereits in der Planungsphase vorauszusehen. Die Erfahrung zeigt, dass relationale Datenbanken einfach nicht die erforderliche Agilität zum Zusammenführen unternehmenskritischer Daten aus unterschiedlichen Silos bieten.

Es kommt natürlich auf die Auswahl der richtigen NoSQL-Datenbank an: Viele NoSQL-Datenbanken stellen ein hohes Maß an Flexibilität bereit, doch Open-Source-Varianten bieten nicht die Enterprise-Funktionen, die gewährleisten, dass Daten sicher gespeichert und vor Änderungen oder Verlust geschützt sind. Diese Funktionen umfassen z. B. höchste Sicherheitsstandards, Elasticity, Hochverfügbarkeit, erweiterte Replikation und – der nächste Punkt auf der Checkliste – ACID-Konformität.

2. ACID

ACID steht für Atomicity, Consistency, Isolation und Durability. Diese Eigenschaften gewährleisten die zuverlässige Verarbeitung von Datenbanktransaktionen. Für unternehmenskritische Anwendungen, bei denen z. B. Finanzdaten oder vertrauliche Daten verarbeitet werden, ist die Transaktionskonsistenz unerlässlich. Systeme ohne ACID-Funktionalität bringen Risiken mit sich, wenn die IT-Abteilung nicht die komplexe und ressourcenintensive Verpflichtung eingeht, jede einzelne Anwendung ACID-konform zu gestalten.

Ein Beispiel: Eine führende Investmentbank verarbeitet jeden Tag über 100.000 komplexe Handelsvorgänge und sie hat durchschnittlich rund 32 Millionen aktive Transaktionen in ihrem System. Wenn die Daten der Bank nicht absolut korrekt, konsistent und aktuell wären, entstünde ein Chaos.

3. Skalierbarkeit

Mit dem Trade-Store-Ansatz können Banken nicht nur empfindliche Bußgelder vermeiden, sondern auch die Kosten für die Entwicklung und Wartung zahlreicher verschiedener Systeme einsparen. Das neue Enterprise NoSQL-System baut auf einer skalierbaren Commodity-Architektur auf. Das Ergebnis sind geringere Kosten pro Handelsvorgang. Ein weiterer Vorteil ist das bessere Risikomanagement, das der Trade Store bietet. Aufsichtsbehörden gestatten dann in der Regel den Banken, weniger Kapital zu halten.

Darüber hinaus kann das System schnell angepasst, erweitert und optimiert werden, um neuen regulatorischen Anforderungen gerecht zu werden. Dabei ist weder eine Schema-Neugestaltung noch ETL (Extrahieren, Transformieren, Laden) erforderlich.

4. Semantik

Die Fähigkeit, hochwertige Risiko- und Finanzdaten zu aggregieren, zählt zu den grundlegenden Anforderungen im neuen regulatorischen Umfeld für Banken. Semantik erleichtert das Ableiten von Fakten und Beziehungen und ermöglicht die Erstellung von Konzepten und Kategorien sowie die Einordnung in den Kontext.

Durch die Zusammenführung von Dokumenten, Daten und verknüpften Daten in einer gemeinsamen Architektur schaffen Sie die Voraussetzungen für eine fundiertere Entscheidungsfindung, den Abbau von Risiken und die Bereitstellung präziserer Informationen.

5. Suchfunktionen

Neben der Datenabfrage zählen auch Suchfunktionen zu den grundlegenden Elementen einer Datenbanksoftware. Das Zusammentragen der Daten allein ist nutzlos: Wenn sie nicht durchsucht werden können, lassen sich die Daten nicht verwenden.

Eine Datenbank mit integrierten Suchfunktionen ermöglicht es Banken und Finanzinstituten, Petabyte an Daten aus einer Vielzahl bestehender Systeme in verwertbare Informationen und Ergebnisse umzuwandeln. Wenn die Suchfunktion dagegen nachträglich aufgesetzt wird, führt das in der Regel zu längeren Wartezeiten auf Ergebnisse, Leistungsminderungen und geringerer Genauigkeit. Außerdem gehen die nuancierten Details der Daten durch das Shredding verloren. Diese Probleme stellen sich auch bei Suchfunktionen von Drittanbietern.

Neue Ansätze bei der Durchsuchung und Analyse der Handelsdaten und KPIs erschließen einer weiteren internationalen Bank, mit der wir zusammenarbeiten, neue Einblicke in die Business Intelligence, darunter das Aufdecken von Trends bei Handelsvorgängen.

6. Bitemporales Datenmanagement

Ein anderes Beispiel: Eine führende Investmentbank entschied sich für die Einführung eines Trade Stores. Durch die Kombination von technischer Innovation und Einblicken in die Betriebsvorgänge lässt sich jederzeitig feststellen, welche Informationen zu einem bestimmten Zeitpunkt vorlagen - ein Aspekt, der in Zukunft sehr wichtig sein wird. Zu diesem Zweck wurde das bitemporale Datenmanagement entwickelt.

Die bitemporale Funktion verringert die Risiken, die den Banken durch technikbedingte Zeitverschiebungen entstehen. Dokumente werden mit Zeitstempeln versehen, und Änderungen können zurückverfolgt werden, ohne dass erst Daten-Backups geladen werden müssen. Dies ist unerlässlich, um die Einhaltung der Anforderungen an Datenanalyseprozesse nachzuweisen, die sich beispielsweise durch die Dodd-Frank-Vorschriften ergeben.

Für Banken und Finanzinstitute erleichtert das bitemporale Datenmanagement die Erfüllung regulatorischer Anforderungen, die Abwicklung von Audits sowie das Risikomanagement und die Analysen – bei geringerem Aufwand.

Richtig vorbereitet?

Banken müssen jetzt ihre Vorbereitungen treffen, um die digitale Ablage so zu gestalten, dass die Aufsichtsbehörden ihnen keine empfindlichen - und vollständig vermeidbaren - Strafgelder auferlegen.

Aus amtlicher Sicht kommt es weniger auf das eingesetzte Verfahren an, als auf die Prüfbarkeit sämtlicher Einzeldaten, von IM-Protokollen über Analysen bis hin zu den jeweiligen Handelsvorgängen. Ein Enterprise NoSQL-basierter Trade Store stellt einen bewährten Ansatz dar und lässt sich in kurzer Zeit entwickeln und umsetzen.

Wer Risiken minimieren und die Compliance gewährleisten möchte, sollten sichergehen, dass auf der Checkliste ACID, bitemporales Datenmanagement, NoSQL, Suchfunktionen, Semantik und Skalierbarkeit abgehakt werden können.

* *Stefano Marmonti ist DACH Sales Director bei MarkLogic

Kommentare werden geladen....

Was meinen Sie zu diesem Thema?

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44431316 / ECM/Datenbanken)