Daten-Governance im Banking: der Datenkatalog als zentrales Werkzeug

Banken tendieren dazu, viele Gedanken und Mühe in datenbezogene Fragen zu stecken, denn sie müssen sich mehr denn je auf ihre Daten verlassen können.

Die stark regulierte Bankenbrache ist naturgemäß primär mit der defensiven Seite des Datenmanagements beschäftigt. Der Fokus liegt damit auf das effiziente Erfüllen der von Regularien wie BCBS239 oder DSGVO vorgeschriebenen Anforderungen in entsprechender Qualität sowie auf eine gut aufgestellte Lösung.

In diesem Blogbeitrag besprechen wir drei verschiedene regulatorische Anwendungsfälle für den Datenkatalog. Der Datenkatalog ist ein zentrales Werkzeug zur Verwaltung der Metadaten einer Organisation, und kann eine Vielzahl von regulatorischen Herausforderungen stemmen. Unserer Ansicht nach besteht ein Datenkatalog aus zehn Bausteinen (siehe Abbildung 1), die je nach Bedarf mehr oder weniger stark ausgeprägt sind.

In den folgenden Kapiteln werden wir beschreiben wie ein Datenkatalog Möglichkeiten eröffnet die Prozesse des Datenmanagements und des Finanz-Reportings zu verbessern, von der Regulatorik geforderte Transparenz zu schaffen und dabei eine professionelle Daten-Governance zu etablieren.

BCBS239 und MaRisk BT3: Transparenz in den Datenflüssen der Kennzahlen

Die Regularien BCBS239 und MaRisk BT3 spielen bei der Einführung von Daten-Governance-Initiativen eine wichtige Rolle. BCBS 239 ist eine Regularie für die sogenannten G-SIB Banken, also die systemrelevanten Banken die in Europa unter Aufsicht der EZB stehen. Die Banken müssen vierzehn Grundsätze zur Sammlung und zur Berichterstattung von Risikodaten, u.a. konkrete Anforderungen an Daten-Governance, erfüllen.

Für Banken, die direkt unter der Aufsicht der BaFin in Deutschland stehen, ist in diesem Zusammenhang MaRisk relevant, im BT3 (Besonderer Teil) wird eine „nachvollziehbare und aussagefähige Risikoberichterstattung“ (source) gefordert. Wie diese nachgewiesen werden soll wird in den kommenden Jahren an der Auslegung dieser Regularien liegen. Für uns bedeuten beide Regularien in der Basis vier Dinge:

Es muss klar sein wie Daten, die für Kennzahlen benutzt werden, interpretiert werden. Dies erfordert daher eine klare Definition

Business Glossare helfen bei der Erstellung einer gemeinsamen Sprache rund um die Daten. Sie enthalten Beschreibungen der Unternehmensdaten und klassifizieren diese. Damit ermöglichen sie den verschiedenen Abteilungen einer Bank jede Information, die irgendwo in der Organisation gespeichert ist, zu verstehen, zu finden und zu verwenden.

Banken müssen ihre Datenflüsse transparent und nachvollziehbar machen

Datenflüsse (oder Daten-Lineage, Datenbäume) machen die Strecke sichtbar, die Daten in einer Organisation in verschiedenen Systemen und Datenspeichern ablegen. Man sollte nachvollziehen können wo die Rohdaten der verschiedenen Kennzahlen herkommen. Das ist zum Beispiel, sehr hilfreich bei dem Aufspüren einer Fehlerquelle bei mangelnder Datenqualität. Dieses Thema haben wir ausführlicher in dem Blog „Data Trees the Capgemini way“ behandelt.

Eine entsprechende Datenqualität muss sichergestellt werden

Ein Datenkatalog bietet die Möglichkeit Datenqualitätsregeln für Daten zu erstellen und zu verwalten. Qualitätsmessungen führt der Katalog zwar nicht aus, aber er kann Resultate der Messungen in Scorecards zusammenführen. Diese machen die Datenqualität des gesamten Datenhaushalts sichtbar, womit auch negative Trends auf einem DQ-Dashboard frühzeitig erkennbar werden. So sehen Finanzinstitute, ob ihre (Risiko-)daten den Regularien entsprechen und liefern somit belastbare Berichte an das Management.

Klare Verantwortlichkeiten und Rollen

Weil Daten ihre Wege meist über verschiedene Bereiche und Systeme machen, ist die Verantwortung verwässert und Entscheidungen und Maßnahmen, die für die Qualität der Bereiche notwendig sind, werden leicht übersehen. Der Datenkatalog ist eine effektive technologische Unterstützung für eine klare Daten-Governance. Durch die Vergabe von Zugriffsrechten und die Klärung von Verantwortlichkeiten definiert ein Datenkatalog verschiedene Rollen und stellt den Zugang zu allen relevanten Daten sicher.

DSGVO: Personenbezogene Daten auf einem Blick

Banken sammeln und bearbeiten enorme Mengen persönlicher Daten von Einzelpersonen und Unternehmen, und gehören deshalb zu den Organisationen, die am stärksten von der DSGVO betroffen sind.

Der Datenkatalog ermöglicht Informationen zu kennzeichnen, die sensibel und personenbezogenen sind, und erleichtert damit die Erfüllung verschiedener Aspekte der DSGVO Regularie. Man kann schnell die Daten finden, die für die Bearbeitung eines Antrags auf Beauskunftung über die gespeicherten Informationen relevant sind. Sowohl Beauskunftung als auch Löschung sind neue Betroffenenrechte, deren Bearbeitung mit der Einführung der DSGVO zeitnah erfolgen muss. Bei fehlender Transparenz über die Datenlandschaft des Unternehmens, können hier ein hoher Zeit- und Kostenaufwand für Einzelfälle entstehen.

BIRD und IReF: Anschluss an regulatorische Datenmodelle

Wann immer ein neues aufsichtsrechtliches Framework eingeführt oder ein bestehendes aktualisiert wird, wird von den Banken erwartet, dass sie das Framework unabhängig interpretieren, Daten aus ihren internen Systemen extrahieren und dann die Daten transformieren, um die von der Verordnung geforderte endgültige Kennzahl zu erhalten. Die Kombination von zwei Regularien soll diesen Aufwand erheblich verringern.

IREF (Integrated Reporting Framework) soll die vielen Anforderungen (AnaCredit, FINREP, COREP, MIR etc.) in der Berichtserstattung von Banken integrieren. ^[1]The Banks’ Integrated Reporting Dictionary (BIRD) hat das Ziel, die Zusammenarbeit auf dem Gebiet des aufsichtsrechtlichen Meldewesens zu fördern, die Meldebelastung der Banken zu verringern und die Qualität der an die Behörden gemeldeten Daten zu verbessern. Der Inhalt des BIRD basiert auf einem harmonisierten Datenmodell, das die Daten spezifiziert, die aus den internen IT-Systemen der Banken extrahiert werden sollten, um die von den Behörden geforderten Berichte zu erstellen.^[2] Diese Regularien stehen noch in den Kinderschuhen, aber der Trend, dass Aufsichtsbehörden auf ein einheitliches Datenmodell setzen, ist klar zu erkennen.

Wenn im Datenkatalog das eigene Datenmodell mit Definitionen, Datenflüssen und Verantwortlichkeiten richtig abgebildet ist, ist der Aufwand des Mappings zu den neuen Datenmodellen erheblich geringer. Ein richtig gepflegter Datenkatalog ist somit eine gute Vorbereitung auf die nächste Welle der Bankenregulatorik.

Mit den rasch ausbreitenden Möglichkeiten der KI wird sogar ein teilautomatisiertes Mapping ermöglicht. Verschiedene Anbieter von Datenkatalog-Tools bieten schon eine Machine Learning Funktionalität an. Diese benutzen Mustererkennung um, zum Beispiel Mappings zwischen Daten und Datendefinitionen herzustellen.

Unser Implementierungsansatz

Ein Use-Case-getriebener Ansatz ist eine einfache und effektive Methode zur Priorisierung von Bereichen, auf die sich Daten-Governance-Maßnahmen konzentrieren sollten. Die Einführung und Pflege eines Datenkatalogs stellt eine entscheidende Voraussetzung dar, um diese Daten-Governance-Maßnahmen zu operationalisieren. Alle Vorschläge für Use Cases werden einer Bewertung der geschäftlichen Auswirkungen und der Durchführbarkeit unterzogen, um die Spitzenkandidaten auszuwählen, die dann in die erste Implementierungsphase gehen (mehr dazu siehe unseren Blogbeitrag „Automobilhersteller schöpfen das Potential ihrer Fahrzeugdaten nicht aus“).

Jedoch verfolgen Finanzinstitute in der Regel ein klares regulatorisches Ziel und damit ist der wichtigste Use-Case, nämlich das effiziente und rechtzeitige Erfüllen von Anforderungen, schon gegeben. Ein Datenkatalogimplementierungsprojekt besteht in diesem Fall aus drei Phasen:

Projekt-Setup

Die Setup-Phase bezieht sich auf die Phase bis ein geeignetes Datenkatalog-Tool ausgewählt wird. Da es auf dem Markt verschiedene Datenkatalog-Tools gibt, von denen jedes seine ganz eigenen Vorteile und einzigartigen Merkmale hat, hat die Auswahl eines geeigneten Tools langfristige Auswirkungen. Ein detailliertes Auswahlkonzept mit Zielen, Anwendungsfällen, funktionalen Anforderungen und grundlegendem Implementierungsansatz hilft dabei die richtige Entscheidung zu treffen und somit alle relevanten Bereiche abzudecken.

PoC (Proof of Concept)

Der Erfolg einer Datenkatalogimplementierung hängt in erheblichem Maße davon ab, wie gut und wie schnell er mit Leben gefüllt (d.h. mit relevanten (Meta-)Daten geladen) wird. Daher muss eine Bank in der PoC Phase Prozesse und Rollen (z.B. einen Data Steward) etablieren, um Daten und weitere Inhalte im Datenkatalog bereitzustellen und die Integration des Datenkatalogs an die bankinternen Systeme testen.

Implementierung

Sobald die ersten Fähigkeiten aufgebaut werden erfolgt die eigentliche praktische Umsetzung. Die letzte Projektphase beinhaltet das Onboarding der Business-Organisation und daraus folgende Entwicklung von Schulungsinitiativen und anderen Handlungen zur Steigerung der Mitarbeiterakzeptanz. Im Folgenden werden bankinterne Systeme angeschlossen und neue Daten-Governance Prozesse etabliert.

Vielen Dank an den Co-Autoren Joshua de Haan.

[1] https://www.ecb.europa.eu/pub/pdf/other/ecb.escb_integrated_reporting_framework201804.en.pdf

[2] https://www.ecb.europa.eu/stats/ecb_statistics/co-operation_and_standards/reporting/html/bird_dedicated.en.html