In einem konkreten Kundenprojekt wurden als Quellsysteme 12 Order Management Systeme (OMS) identifiziert, welche Orderdaten erzeugen, die für das ORK für Anfragen von Aufsichtsbehörden für die Dauer von sieben Jahren vorzuhalten sind. Der Kern der Big Data-Lösung ist ein Hortonworks Hadoop Cluster. Sechs der oben genannten OMS treten zudem als Systematische Internalisierer (SI) auf, für die sich Publizitätspflichten gemäß MiFIR (konkretisiert in den Regulatory Technical Standards (RTS) 1 und 2) ergeben. Die einzuhaltenden Zeitfenster bis zur Veröffentlichung betragen hierbei 1 Minute für Aktien und Aktien-ähnliche Produkte und 15 Minuten für Nicht-Aktien Produkte.
Daten erreichen das ORK auf zwei unterschiedlichen Wegen: Um die oben erwähnten Anforderungen erfüllen zu können, wurde die Data Streaming-Komponente „Apache Kafka“ eingesetzt. Dabei werden Order-Events in Form einer Nachricht in Echtzeit vom OMS ausgeleitet. OMS, für die keine Publizitätspflichten bestehen und die das Sammeln der Nachrichten unterstützen, schreiben diese in eine Datei (meist ein csv file) und übermitteln diese am Tagesende an das ORK.
Für beide Übertragungswege wurde zunächst definiert, welche Datenfelder einer Order für das ORK und die Publikationspflichten für die Vorhandelstransparenz benötigt werden. Als Nachrichtenformat für Anlieferungen über die Real Time-Strecke wurde Apache Avro verwendet. Avro ist ein System zur Datenserialisierung. Es wurde ein Schema für die Datenanlieferung modelliert. Das Schema besteht aus Datensätzen, die wiederum Felder enthalten. Jedes Feld hat einen festen Datentypen (z.B. Dezimalzahl), und es wurde definiert, ob das Feld optional ist und ob es einen Defaultwert hat.
Eine Avro Message besteht aus einem Header mit Informationen zum Quellsystem, Zeitstempel etc. und einem Body, der die benötigten Datenfelder enthält. Der Transfer der Nachrichten geschieht über einen beim Quellsystem installierten Kafka-Producer als Teil eines Kafka-Clusters. Dieser schreibt die Messages im Kafka-Broker in sein dediziertes Topic in eine Message Queue. Aus dieser Queue liest dann ein Kafka-Consumer, der in der Komponente Spark eingebettet läuft. Die Aufgabe von Spark ist es an dieser Stelle, den Datenstrom zu überprüfen und anhand von definierten Filterkriterien die Nachrichten, die im Zuge der Vorhandelstransparenz publiziert werden müssen, herauszufiltern. Alle Nachrichten, die zu veröffentlichen sind, werden ins FIX-Format konvertiert und an das entsprechende externe System zur Veröffentlichung weitergeleitet. Alle über den Real Time- Pfad erhaltenen Orders werden anschließend von Spark in einen Ordner geschrieben, aus dem die Applikation Informatica liest.
Von Informatica werden auch die über den Batch-Weg erhaltenen Orderdaten verarbeitet. Alle Orders werden mit Metadaten versehen und um Stammdaten von Personen, Händlern und Instrumenten angereichert. Die so erstellten Datensätze werden im Hadoop Cluster abgelegt.
Fazit: Durch das parallele Verarbeiten der Daten können große Datenmengen in kurzer Zeit verarbeitet und gespeichert werden. Da die Orderdaten der gesamten Bank zentralisiert und harmonisiert an einem Ort vorgehalten werden, ergeben sich hier noch viele denkbare Anwendungsfälle. Die Daten können mit Business Intelligence für unterschiedliche Abteilungen der Bank entsprechend aufbereitet und zur Verfügung gestellt werden.
Die Wertpapierspezialisten der FINCON unterstützen Sie in der Beantwortung von Fragestellungen rund um die Themen „Wertpapiere und Derivate“., z.B. bei der Umsetzung regulatorischer Anforderungen, der Auswahl von WP-Software-Anwendungen, der Anbindung von Handelsplattformen und Lagerstellen.
Der Autor und Ansprechpartner für dieses Thema, Thomas Schulte, ist Senior Consultant bei FINCON. Er kann auf langjährige praktische Erfahrungen entlang der Wertpapierprozesskette zurückblicken, u.a. durch eine Leitungsposition im Back Office. Seine Projekterfahrungen umfassen z.B. die Konzeption und Einführung einer automatischen Abstimmung von Trades und Positionen gegen die Verbuchungen und Bestände, die Automatisierung der §9 WpHG Meldungen, die Einführung von FX-Geschäften als neue Asset Klasse., verbunden mit einer hohen IT-Affinität wie zuletzt in einem Big-Data-Projekt.