Monitoring kumulierter Risiken im Kreditportfolio

Die Finanzmarkt- und Staatsschuldenkrise hat die Anforderungen an die Reaktionsgeschwindigkeit der Finanzbranche deutlich erhöht. Für die Darstellung und das Reporting von Risikopositionen ergeben sich daraus neue Herausforderungen. Doch nicht nur das eigene Geschäftsinteresse, sondern auch die umfangreichen aufsichtlichen Anfragen und Änderungen der Rahmenbedingungen stellen die Institute vor die Aufgabe, die eigenen Prozesse permanent zu überprüfen und gegebenenfalls anzupassen.

Das Gesetz zur Umsetzung der geänderten Bankenrichtlinie und der geänderten Kapitaladäquanzrichtlinie (CRD II-Umsetzungsgesetz) der Europäischen Union wurde am 24.11.2010 im Bundesgesetzblatt verkündet. Im Zuge der Umsetzung wurden die Großkreditvorschriften durch die Verabschiedung der neuen Groß- und Millionenkreditverordnung (GroMiKV) und des Kreditwesengesetzes (KWG) zum 31.12.2010 zur besseren Identifizierung von Konzentrationsrisiken neu geregelt. Mit den Mindestanforderungen an das Risikomanagement (MaRisk) in ihrer letzten Fassung vom 15.12.2010 wurde die Erfassung und Begrenzung von Risikokonzentrationen in deutsches Aufsichtsrecht überführt.

Besonderes Augenmerk verdienen dabei Konzentrationen auf bestimmte Länder oder Branchen sowie unerwünschte Klumpen-Risiken: Konstellationen, in denen mehrere Geschäftspartner der Bank untereinander in so engen geschäftlichen Beziehungen stehen, dass die Schieflage eines Partners auch den Rest des jeweiligen Risiko-Verbunds bedroht. Im schlimmsten Fall löst die Zahlungsunfähigkeit eines einzelnen Unternehmens eine ganze Kette weiterer Insolvenzen aus – ein gefürchteter Domino-Effekt beginnt. Der Umgang mit solchen Risiken ist auch eine Schlüsselaufgabe für ein verlässliches Risikomanagement – wie auch unter der Weiterentwicklung CRD III gefordert.

Vor diesem Hintergrund setzte sich die Deutsche Postbank AG das Ziel, künftig eine Software einzusetzen, die es ermöglicht, Risiken sowohl für einzelne Geschäftspartner als auch für Kreditportfolien auszuweisen. Es wurde ein „Neues Obligo-Informationssystem“ (NOBIS) entwickelt, dessen Möglichkeiten über die gesetzlichen Vorschriften hinausgehen und das zusätzliche betriebswirtschaftliche Ziele erfüllt.

Kreditnehmer, Kreditnehmereinheiten, Risikoeinheiten
Damit Kreditinstitute die einzelnen Vorschriften des KWG korrekt umsetzen können, ist es notwendig zunächst den Umfang des Begriffs „Kreditnehmer“ zu klären. Diese Definition erfolgt in § 4 GroMiKV, während § 19 Abs. 2 KWG so genannte Kreditnehmereinheiten definiert. Kreditnehmereinheiten müssen in der Risikobewertung als einheitlicher Kreditnehmer behandelt werden, obwohl sie aus mehreren rechtlich eigenständigen Kreditnehmern bestehen. Diese gesetzliche Regelung kommt beispielsweise bei Unternehmen zum Tragen, die alle zum selben Konzern gehören und von derselben Konzernmutter beherrscht werden, oder wenn Kredite an Gesellschaften wie auch die persönlich haftenden Gesellschafter vergeben werden. Darüber hinaus sind noch einige weitere Formen der Kreditnehmereinheit gesetzlich geregelt, beispielsweise getrennte Unternehmen von Ehepartnern, wenn diese eine gemeinsame Geschäftspolitik verfolgen.

Unabhängig davon gibt es allerdings Klumpen-Risiken, die nicht durch die Definition einer Kreditnehmereinheit ausdrücklich erfasst werden, beim Risikomanagement aber dennoch berücksichtigt werden sollten. Die Definition des neu eingeführten Begriffs der Risikoeinheit wird in § 19 Abs. 2 Satz 6 KWG dargestellt, welche nun auch die gleiche Zielrichtung wie der Begriff der Schuldnergesamtheit aus § 4 Absatz 8 der Solvabilitätsverordnung (SolvV) verfolgt.

Als klassisches Beispiel gelten hochspezialisierte Zulieferer, die Produkte zur späteren Veredlung für wenige oder sogar einzelne Unternehmen fertigen – ein übliches Geschäftsmodell beispielsweise in der Automobilindustrie. Ein Rückgang des Neuwagen-Verkaufs ist demnach nicht nur ein Problem für den Automobilbauer, sondern auch für dessen Teilelieferanten und wiederum deren Zulieferer von Rohmaterialien. Solche Risiken zu erkennen, zu bewerten und automatisiert abzubilden, ist eine wichtige Voraussetzung für ein funktionstüchtiges Risikomanagement. Die für die Deutsche Postbank entwickelte IT-Lösung bildet daher die Obligo-Positionen des Non-Retail-Bereichs in übersichtlichen, praxistauglichen Berichten ab. Davon erfasst sind nicht nur die gesetzlich definierten Kreditnehmereinheiten, sondern alle erfassten Risikoeinheiten im Portfolio.

Die Ausgangslage
Obwohl die Erkennung von Klumpen-Risiken zentrales Ziel des NOBIS-Projekts war, stellte sich die Gesamtaufgabe noch ambitionierter dar: Die Postbank nutzte den Anlass, um das gesamte Obligo-Monitoring konzernweit zu vereinheitlichen. Vorher überprüften die Mitarbeiter das Obligo mit Hilfe einer IT-Struktur, die im Rahmen der Expansion und Internationalisierung des Konzerns historisch gewachsen war. Für eine Darstellung des Kreditnehmerobligos mussten bei bestimmten Konstellation Daten aus zwei Systemen ausgewertet werden.

Zu den originären Datenquellen zählten unter anderem Hauptbücher, Kontokorrentkredite, Darlehensvereinbarungen, Factoring-Positionen und die Bestände von Auslandstöchtern in Luxemburg, London und New York. Erfasst und geführt werden diese Informationen in zwei unterschiedlichen Softwarewelten. Optimierungsbedarf zeigte sich zunächst in Art und Umfang, wie diese vielfältigen Informationen im Obligo-Berichtswesen zusammengeführt wurden.

Ablösung Altsystem
Um eine vollständige Obligo-Auswertung eines Kunden, eines Risiko-Verbunds oder gar des gesamten Konzernengagements zu bieten, mussten die Daten also aus zwei Systemen erhoben und zusammengeführt werden – ein aufwändiger Prozess. Die notwendigen Berechnungen konnten nicht vollständig softwarebasiert durchgeführt werden, Dies war jedoch keineswegs der einzige Aspekt, in dem Verbesserungspotenzial ausgemacht wurde. So sollten mit dem NOBIS-Projekt betriebswirtschaftliche Vorteile realisiert werden: Neue Produkte ließen sich zuvor nur in einem festgelegten IT-Releasezyklus mit einem recht hohen Zeit- und Kostenaufwand in die Analyseprogramme einpflegen.

Das neue System ermöglicht es nun, Obligen zu gewünschten Zeitpunkten aus der Vergangenheit anzuzeigen – eine Funktion, die in der Vorgängerversion nicht implementiert war. Eine zusätzliche Beeinträchtigung bei der täglichen Arbeit, die im Rahmen der Neuprogrammierung beseitigt werden sollte, gründete in der Komplexität der bisherigen Anwendungen: Diese stellten eine solch umfassende Menge an Informationen bereit, dass eine komfortable Nutzung des Programms nur schwer möglich war. Eine Obligo-Auswertung nahm zu viele Tabellenspalten ein, so dass die Nutzer der Software waagerecht scrollen mussten, um alle für sie relevanten Daten einzusehen – eine Vorgehensweise, die der gewünschten Anwenderfreundlichkeit im Umgang mit Computerprogrammen im Wege stand.

Komplexe aufsichtsrechtliche Anforderungen
Die Ziele des IT-Projekts resultierten somit aus drei Motiven: Zum ersten mussten die aufsichtsrechtlichen Vorgaben umgesetzt werden. Dann sollte die Software die jüngsten Erkenntnisse über modernes Risikomanagement abbilden. Abschließend war es der klare Wunsch aller Beteiligten, die alltägliche Arbeit durch praktikable Benutzeroberflächen soweit wie möglich zu erleichtern und zu beschleunigen. Die Grundanforderungen an das neue System ergaben sich aus den gesetzlichen Anforderungen KWG, GroMiKV, SolvV sowie den MaRisk.

Aufgabe der Deutsche Postbank AG war es, ein einheitliches, konzernweites Obligo-System zu erarbeiten. Dieses sollte in der Lage sein, Obligo-Berechnungen auf Knopfdruck zu erstellen und dies nicht nur für einfache Abfragen, beispielsweise für einzelne Kunden oder Kreditnehmereinheiten, sondern auch für komplexe Konstellationen: Angefordert wurden beispielsweise die Darstellung sämtlicher Engagements sortiert nach Engagementsgröße bzw. die Auskunft über eine frei wählbare Anzahl der größten Engagements der Bank. Dazu kam die Darstellung aller Positionen, die einen definierten Wertbetrag überschreiten, oder die Auskunft über Risiken, beispielsweise in einzelnen Branchen.

Überführung in konkrete Projektziele
Um diese Aufgaben zu erfüllen und zugleich die im laufenden Betrieb ermittelten Verbesserungspotenziale zu realisieren, erarbeiteten die Projektmitarbeiter einen passgenauen Anforderungskatalog für die neu zu entwickelnde Software: Alle bestandsführenden Systeme, die im Konzern zum Einsatz kommen, sollten in einer einzigen, einheitlichen Oberfläche zur Auswertung zusammengeführt werden. Dafür mussten diverse Module mehrerer unterschiedlicher Hersteller ausgelesen und zusammengeführt werden.

Um einen konzernweit einheitlichen Einsatz zu ermöglichen, der gleichzeitig möglichst anwenderfreundlich ist, wurden von vornherein zwei Benutzersprachen vorgesehen: Bei deutschsprachigen Nutzern startet das System automatisch auf Deutsch, bei Nutzern aus dem Ausland lädt automatisch die englischsprachige Variante. Die internationale Ausrichtung der Benutzeroberfläche setzt sich darüber hinaus inhaltlich fort. So wird beispielsweise den weltweiten Aktivitäten des Konzerns Rechnung getragen, indem Fremdwährungskonten uneingeschränkt ausgewertet werden können und für ausgewählte Produkte die Umrechnung zwischen Euro und Dollar oder zwischen Euro und britischem Pfund hinterlegt sind. Auch die Anzeigewährung kann durch den User definiert werden.

Eine hohe Priorität hatte zudem der Aspekt, die bereitzustellenden Informationen auf ein Maß zu reduzieren, das bei der Arbeit tatsächlich von Relevanz ist. Aus dem Datenmodell des Vorgängersystems wurden die benötigten Informationen isoliert. Unter anderem die Stammdaten des Geschäftspartners (inklusive Rechtsform, Branche, Land und Zugehörigkeit zu Kreditnehmereinheiten oder anderen Risikoeinheiten) sowie selbstverständlich die Obligo-relevanten Informationen.

Dazu zählen beispielsweise Daten wie das Vertragskapital, die Art des Geschäfts respektive des Produkts, die verwendete Währung, eventuelle Kreditlinien und deren aktuelle Inanspruchnahme, Informationen über Rückstände und Überzahlungen bis hin zur Teilnahme an öffentlich-rechtlichen Förderprogrammen, die sich auf das Obligo auswirken – beispielsweise bei einer Haftungsfreistellung, die sich aus einer Förderung etwa durch die KfW-Bankengruppe ergeben kann. Ebenfalls angezeigt werden Engagements anderer Geschäftspartner der Deutsche Postbank AG, wenn diese mit dem geprüften Partner eine Kreditnehmer- oder Risikoeinheit bilden.

Insgesamt besteht damit eine Informations- und Datenbasis, die parallel aus allen bestandsführenden Subprogrammen zusammengeführt wird. Mit der Reduktion der abgefragten Felder hatten sich die Beteiligten zudem eine Beschleunigung der Datenabfrage vorgenommen. Mit den alten Systemen konnte es mehrere Minuten dauern, bis alle notwendigen Angaben abgefragt, verarbeitet und angezeigt wurden. Durch die Datenreduktion und eine moderner Architektur ist es nun selbst bei komplexen Engagementstrukturen möglich, umfangreiche Obligo-Berichte in kürzester Zeit auszugeben.

Die Angaben sollten allerdings nicht nur für den jeweiligen Tag der Abfrage zur Verfügung stehen, sondern auch für historische Daten ermittelt werden können. Eine vollständige Abfragemöglichkeit für alle erdenklichen Zeitpunkte in der Vergangenheit hätte allerdings mehrere Probleme mit sich gebracht. Erstens hätten gewaltige, potenziell irrelevante Datenmengen archiviert werden müssen, zum anderen hätte die Auswertung dieser Daten erhebliche Rechenzeit in Anspruch genommen.

Um eine praxistaugliche Lösung zu finden, einigte man sich daher auf Abfragemöglichkeiten für die letzten drei Jahre vor dem Zeitpunkt der Anfrage, bei denen jeweils das Monats- oder Quartalsultimo als Stichtag ausgewählt werden konnte. Zusätzlich sollte jeweils der Vortag des aktuellen Abfragezeitpunkts als möglicher Stichtag zur Verfügung stehen. Zu guter Letzt sollte die Zukunftssicherheit des Systems gewährleistet werden: Wenn im Konzern neue Produkte in die bestandsführenden Systeme aufgenommen werden, sollen diese mit geringem Aufwand auch in das neue Obligo-Informationssystem Einzug finden. Ziel war, Betriebs- und Investitionskosten gegenüber den Vorgängersystemen spürbar zu reduzieren.

Präzise geplante Umsetzung
Alle genannten Anforderungen wurden in einem Fachfeinkonzept festgehalten, bei dessen Erstellung zugleich Abhängigkeiten mit anderen IT-Systemen der Deutsche Postbank AG überprüft wurden, um spätere Komplikationen zu vermeiden. Bevor mit der Entwicklung der notwendigen Komponenten begonnen wurde, mussten in enger Abstimmung mit dem Fachbereich die Pläne für die spätere Nutzung des neuen Systems erarbeitet werden: Dutzende Anwendungsfälle wurden in allen Details beschrieben. In zahlreichen Review-Schleifen erfolgte anschließend eine immer weitere Verfeinerung, bis bei allen Beteiligten Einigkeit herrschte, wie das neue System die erarbeiteten Zielanforderungen konkret erfüllen würde.

Am Ende dieses Arbeitsschritts standen drei exakt definierte Standardreports und diverse Portfolioreports, bei denen genau bekannt war, auf welchem Weg man zur gewünschten Anzeige kommt und welche Daten dafür benötigt werden. Weiter wurde dokumentiert, aus welchem der bestandsführenden Subsysteme welche dieser Daten erhoben werden und entsprechende Feld-Mapping- und Filetransfer-Dokumente erstellt.

Um von Anfang an eine vollständige Abbildung des Obligo-Bestands zu erreichen, wurde der gesamte Bestand an vorhandenen Produktgruppen nach risikorelevanten Kriterien analysiert. Diese Analyse erstreckte sich von klassischen Bankprodukten wie Darlehen und Kontokorrent bis hin zu komplexen Finanzierungsstrukturen. Insgesamt etwa die Hälfte der analysierten Produkte erwiesen sich dabei als obligo-relevant und fand bei der Datenüberführung und Auswertung in NOBIS Berücksichtigung. Damit erreicht die Deutsche Postbank AG eine vollständige Wiedergabe des ökonomischen Ausfallrisikos sämtlicher Risikopositionen.

Völliges Neuland betraten die Projektteilnehmer mit der Abbildung von Risikoeinheiten. Parallel zur Fachfeinkonzeption wurden Richtlinien erarbeitet, welche Fälle geschäftlicher Verbindungen eine Obligo-Relevanz haben. Sind diese Vernetzungen in den Ausgangssystemen hinterlegt, ermöglichen die Obligo-Berichte nun eine detaillierte Risikobewertung. 643 Testfälle später, in denen mehr als 3.000 mögliche Varianten der Nutzung geprüft wurden, und nach der Erstellung von mehr als 1.200 Seiten Dokumentation war das neue System bereit für die Live-Schaltung. Vom Projektstart im September 2009 bis zur Aktivierung der letzten Komponenten dauerte die Entwicklung cirka eineinhalb Jahre – im Frühjahr 2011 wurde das neue Obligo-Informationssystem vollständig in Betrieb genommen. Über die verschiedenen Projekphasen waren rund 150 verschiedene Mitarbeiter mit den sehr vielfältigen Themen und Intensitäten aus unterschiedlichsten Bereichen betraut.

Resümee
Aus Sicht der Verantwortlichen hat sich der Aufwand gelohnt. Zum einen werden die neuen regulatorischen Anforderungen vollständig erfüllt: Ein einheitliches Obligo-System gibt per Knopfdruck Auskunft auf der Ebene von Einzelkreditnehmern, Kreditnehmereinheiten, Risikoeinheiten und über das gesamte Portfolio. Die Portfolioreports bieten etwa wahlweise eine schnelle Auskunft über einzelne Branchen, eine detaillierte Analyse nach Ratingklassen, kurzfristige Auswertungen über Länderkonzentrationen und eine Übersicht der größten Kreditnehmer und Kreditnehmereinheiten. Dabei werden alle bestandsführenden Systeme ausgewertet, wahlweise tagesaktuell oder zu historisch relevanten Stichtagen. Es können künftig damit die maximalen Ausfallrisiken für alle gewählten und gewünschten Perspektiven untersucht werden – ein wichtiger Beitrag zum Kreditrisikocontrolling.

Über die Abbildung der rechtlichen Anforderungen hinaus rentiert sich das Projekt auch in betriebswirtschaftlicher Hinsicht: Zukünftig muss nur noch ein einziges System gepflegt werden. Die Kosten für Support, Benutzerverwaltung, Wartung und Weiterentwicklung lassen sich dadurch deutlich reduzieren. Insbesondere bei der Einführung neuer Produkte sind dadurch Einsparungen möglich. Ein nicht zu unterschätzender Faktor ist zudem die erheblich reduzierte Arbeitszeit, die aus der schnelleren Datenabfrage und der im Vergleich zum Vorgängersystem vereinfachten, nutzergerechten Benutzeroberfläche resultiert. Die vereinfachten Prozesse und die übersichtliche Report-Darstellung reduzieren das Fehlerrisiko deutlich. Insgesamt eine gute Basis für die Zukunft.ó