Anspruchsvolles ­Datenmanagement (Fortsetzung)

Historie erforderlich
Die beiden IRB-Ansätze stellen unterschiedliche Anforderungen an die erforderlichen Datenhistorien: Der Basis-IRB-Ansatz setzt zum Start von Basel II eine zweijährige Datenhistorie voraus. Der Zeitraum dieser Datenhistorie verlängert sich bis zum Ende der dreijährigen Datenhistorie auf fünf Jahre. Für den fortgeschrittenen Ansatz ist bereits zum Startzeitpunkt eine siebenjährige Datenhistorie erforderlich. Neben den Datenhistorien ist zudem eine konsistente und durchgängige Verwendung der Ausfalldefinition notwendig. Der Ausfall eines Kreditnehmers tritt gemäß Basel II ein, wenn mindestens eines der vorgegebenen Ausfallkriterien erfüllt ist. Ein Teil lässt sich durch die IT maschinell ableiten. Ein typisches Beispiel stellt die Anzahl der Überziehungstage dar: Ist das Konto des Kreditnehmers mehr als 90 Tage überzogen, gilt es im Sinn von Basel II als ausgefallen.
Die Mindestanforderungen an das Kreditgeschäft (MaK) sind bis zum 31.12.2005 von den Kreditinstituten umzusetzen. Bestandteile der MaK, die kaum ohne IT-Unterstützung in den Kreditinstituten realisiert werden können, sind das Berichtswesen und das Frühwarnsystem. Im Gegensatz zu Basel II fordern die Aufsichtsbehörden nicht explizit die Aufbewahrung von Historien, aber ohne die zugehörigen Datenreihen ist die Implementierung MaK-relevanter Systeme kaum machbar. So sind Periodenvergleiche eine wesentliche Voraussetzung eines aussagekräftigen Berichtswesens. Für die Umsetzung der MaK sind damit implizit vergangenheitsbezogene Daten erforderlich.

Data Warehouse nötig
Für die Umsetzung von Basel II und MaK ist die Zusammenführung vielfältiger Informationen aus verschiedenen Bereichen erforderlich. Dazu gehören Konto- und Kundendaten, Rating- und Scoring-Einstufungen sowie Fakten zu Kreditsicherheiten. Häufige Probleme in der Praxis sind mangelnde Datenqualität in den Liefersystemen sowie die geringe Datenverfügbarkeit. Oft fehlen Daten oder sie sind unvollständig, redundant oder inkonsistent. Zudem müssen Daten aus heterogenen IT-Architekturen zusammengeführt werden und dies ist häufig mit Medienbrüchen und unterschiedlichen Formaten verbunden.
Um einen homogenen und konsistenten Datenbestand für die Umsetzung von Basel II und MaK zu schaffen, empfiehlt sich der Aufbau eines zentralen Data Warehouse. Auf dieser Basis können die verschiedenen dispositiven Systeme für Basel II und MaK auf einer einheitlichen und skalierbaren Datenbasis aufsetzen. Dies hilft die Wiederverwendbarkeit von Daten zu erhöhen und Redundanzen und Inkonsistenzen zu vermeiden. Ein solcher zentraler Datenbestand lässt sich wie in Warehouses üblich mit Hilfe eines ETL-Prozesses bewirtschaften. ETL steht für Extrahieren, Transformieren und Laden und bezeichnet den Vorgang, Daten aus den verschiedenen Liefersystemen zu extrahieren, zu transformieren und in die zentrale Datenbank zu laden. Bei der täglichen Extraktion der Daten ist in der Regel ein festes Zeitfenster einzuhalten, damit die Liefersysteme rechtzeitig wieder für den operativen Betrieb zur Verfügung stehen. Im Rahmen der Transformation sind die Daten so anzupassen, dass sie zusammengeführt werden können. Vor diesem Hintergrund sind Schlüssel anzupassen und Währungen zu vereinheitlichen.
Die Bewirtschaftung kann mit spezialisierten ETL-Werkzeugen realisiert werden. Diese unterstützen eine automatische Transformation, Aggregation und Bereinigung von Daten. Zudem lassen sich durch zentrale Metadaten Extraktions- und Transformationsregeln so festlegen, dass die Wartung und Weiterentwicklung des Systems zeitsparend und kostengünstig erfolgen kann.
Viele Daten ändern sich nicht täglich. Daher ist eine Deltaverarbeitung empfehlenswert, bei der nur die tatsächlichen Änderungen übertragen werden. Von besonderer Bedeutung ist die Erhöhung der Datenqualität in den Liefersystemen, denn aus Daten mit einer schlechten Qualität können auch durch einen guten ETL-Prozess keine Daten mit guter Qualität erzeugt werden. Die Datenqualität lässt sich beispielsweise erhöhen, indem mit fachlichen Plausibilitätsprüfungen im ETL-Prozess Fehlerlisten erzeugt werden. Mit diesen Fehlerlisten können die fehlerhaften und unvollständigen Daten in den Liefersystemen korrigiert werden. Da für die Umsetzung von Basel II und MaK Mengendaten aus den operativen Systemen mit hohen wechselseitigen Abhängigkeiten zu verarbeiten sind, empfehlen sich frühzeitige Performance-Tests und Optimierungen. Dies ist insbesondere vor dem Hintergrund wichtig, dass häufig nur kurze Zeitfenster für einen vollständigen Durchlauf eines ETL-Prozesses zur Verfügung stehen.

Passende Verfahren
Auf Basis der zentralen Datensammlung kann eine Aufbereitung der Daten für Basel II durch eine so genannte Basel-II-Logik erfolgen. Hier werden die aufsichtsrechtlichen Parameter wie Verlustquoten und Ausfallhöhen geschätzt oder mit den aufsichtsrechtlich vorgegebenen Werten verglichen. Die Ergebnisdaten stehen im Anschluss für die Berechnung der Eigenkapitalunterlegung gemäß Basel II zur Verfügung. Auch die von Basel II geforderte Validierung der Daten kann auf dieser Basis durchgeführt werden, indem beispielsweise die verschiedenen Rating-Noten interner und externer Herkunft verglichen werden. Und auch der erforderliche Lasttest kann auf diese Weise unterstützt werden, etwa durch Herabsetzen der Rating-Noten von Krediten oder Kreditnehmern um jeweils eine Stufe. Hierdurch lässt sich eine Erhöhung der Eigenkapitalvorhaltung durch eine pauschale Bonitätsverschlechterung simulieren.

Mehrwert durch ­Einheitlichkeit
Mit guten IT-Lösungen für die neuen Compliance-Anforderungen schaffen die Banken eine einheitliche Datengrundlage, von der sie auch sonst beim Risikomanagement und bei der Unternehmenssteuerung profitieren können. Ein zentraler konsistenter Datenbestand kann nämlich den unterschiedlichsten dispositiven Systemen als Basis dienen. So können dann Steuerungsinformationen einheitlich und widerspruchsfrei angezeigt werden. Weiterhin ist denkbar, dass dispositive Daten auch an operative Systeme weitergegeben werden. Zum Beispiel können die vom Frühwarnsystem benötigten verdichteten Girodaten zur Erkennung der Überziehungstage auch von Rating- und Scoringsystemen als Inputparameter genutzt werden.

Oliver Tiebing ist Berater bei dem IT-Dienstleister Mummert Consulting.