AnaCredit – erste Erfahrungen: Auswirkungen auf die IT der deutschen Kreditinstitute

Seitdem der nationale Um­setz­ungs­plan der Bundesbank für die AnaCredit-Verordnung feststeht, stellt sich die Kreditwirtschaft gespannt die Frage, wie die granularen Daten fristgemäß gemeldet werden. Denn in den Finanzinstituten liegen die Daten, welche die EZB verlangt, selten in der geforderten Form, sondern fragmentiert vor. IKOR zieht nach den ersten Erfahrungen ein Fazit zur AnaCredit-Umsetzung.

von Stephan Grunwald, Teamleiter Projekte Fördergeschäft IKOR 

Der EZB-Rat billigte am 18. Mai die “Verordnung zur Implementierung eines granularen sta­tis­ti­schen Kreditmeldewesens” – zum 31. Dezember 2017. AnaCredit ist eine gigantische Datenbank auf Einzelkreditebene („Analytical Credit Datasets“). Die gute Nachricht: Laut EZB soll die Mega-Datenbank nun nicht im März 2018, sondern “erst” im September 2018 starten. Das entspannt zwar die Situation ein wenig – die grundlegende Aufgabe aber bleibt.

Das Volumen der zu meldenden Daten beeinflusst je nach Institutsgröße nicht unbedingt die IT-Performance. Die Herausforderungen bestehen vielmehr bei den Inhalten der geforderten Informationen bzw. der Beschaffenheit der Daten.“

Stamm-, Kredit- und Sicherheitendaten befinden sich über das Institut verteilt in unterschiedlichen Fachabteilungen und auf verschiedenen Systemen. Die AnaCredit-Umsetzung in den Banken ist somit ein Thema, das über das Meldewesen und die IT hinausgeht und diverse Instituts-Fachabteilungen bzw. deren Software-Systeme involviert. Einerseits müssen die Daten aufgespürt werden, andererseits muss die bereichsübergreifende Verständigung erfolgen, wer wann wie kontinuierlich die richtigen Daten für die Übermittlung an die Bundesbank bereitstellt.

IT-Architektur besser gleich langfristig denken

Der zweite prägende Aspekt bei der AnaCredit-Implementierung ist die Qualität der zu übermittelnden Daten. Die sogenannten Attribute nach der EZB-Verordnung entsprechen nicht logischerweise den Kennzahlen, die die Institute erfassen und vorhalten. Entsprechend sind diese hinsichtlich Vollständigkeit, Validität und Konsistenz zu prüfen. Und das rechtzeitig, damit die Übermittlung jeweils pünktlich klappt.

In ihren Umsetzungsprojekten macht daher eine Datenschicht Sinn, die der Meldesoftware vorgeschaltet ist und die benötigten Meldedaten der Finanzgeschäfte in der richtigen Qualität enthält. Eine derartige Lösung hat den Vorteil, dass sie auch bei zukünftigen Erweiterungen und für angrenzende Themen zu nutzen ist. Erweiterungen der AnaCredit-Datenbank sollten in jedem Fall jetzt schon mitgedacht werden. Denn von diesen ist nach Angaben der Bundesbank auszugehen.

An der Umsetzung der AnaCredit-Verordnung führt ohnehin kein Weg vorbei, dann besser gleich eine Gesamtlösung im Sinne der Facharchitektur entwickeln, die die heutige und zukünftige Regulatorik berücksichtigt.“

Die bisherigen Learnings zusammengefasst:

1. Informationen, die an AnaCredit zu melden sind, sind zum Teil auch Bestandteil anderer Meldeanforderungen. Dafür muss gewährleistet werden, dass diese Informationen in sich schlüssig über alle Meldeanforderungen hinweg kommuniziert werden.
2. Die 89 Attribute und sechs Identifikationsmerkmale des AnaCredit-Datensatzes setzen sich aus Informationen der gesamten Kreditbearbeitung (plus weiterer Finanzdaten) zusammen und somit ist die AnaCredit-Implementierung ein bankenweites und kein ausschließliches Meldewesen- und IT-Thema.
3. Manuelle Korrekturen innerhalb des Melderhythmus‘ sind nur rudimentär möglich. Die Datenqualität muss durch Validierung und Konsistenzchecks bereits im Vorwege sichergestellt werden.
4. Die zu meldenden Daten sind nicht aus dem aktuellen Datenhaushalt der Institute zu bedienen. Schlicht, weil sie nicht vorliegen oder aber nicht in ausreichender Qualität und Granularität vorhanden sind.aj