Meldewesen: So gelingt Banken die Abacus360-Schnittstellenmigration

Keyfacts:

• Im Meldewesen vieler Banken hat die Abacus-Software große Bedeutung. Der Anbieter der Abacus360-Software stellt die Wartung zur Konvertierung der Anlieferungen voraussichtlich Ende 2025 ein – deshalb entsteht in vielen Instituten jetzt Handlungsbedarf.
• Künftige Software-Updates und die Auswirkungen neuer regulatorischer Anforderungen – seien es etwa Basel IV / CRR III oder ESG Reporting – werden nur noch in Abacus360 Native umgesetzt, und nicht mehr in Embedded.
• Eine Anpassung der Zulieferungen ist notwendig zur Sicherstellung der Meldefähigkeit – eine Schnittstellenmigration bietet die Chance für Performance-Gewinne und schafft Grundlagen für die Migration auf eine Cloud-Plattform.

Neue Vorgaben zum Meldewesen auf europäischer Ebene beschäftigen die Banken – und das umso mehr, als der Anbieter der verbreiteten Meldewesen-Software Abacus eine weitreichende Migration vollzieht. Um das zu verstehen, muss man sich die technische Lieferstrecke im Meldewesen einmal vor Augen führen.

Die Migration auf die Plattform Abacus360 besteht für viele Institute im Wesentlichen aus zwei Komponenten: Zum einen aus der Migration der Meldemodule (zum Beispiel OWF, STAT, LCR und NSFR) innerhalb von Abacus und zum anderen aus der Migration der Zulieferschnittstelle(n) aus den Banksystemen an das neue Datenmodell Abacus360 Native.

Die Migration der Meldemodule ist bei vielen Banken seit Ende 2023 weitgehend abgeschlossen. Doch für die Lieferung der Daten bis zur fertigen Meldung benötigen sie den sogenannten bi-direktionalen Adapter.

Meldewesen-Softwareanbieter stellt Wartung des Adapters ein – Banken müssen handeln

Der bi-direktionale Adapter in Abacus transformiert die Datenanlieferung gemäß der Embedded-Strukturen in das Abacus360-Zielformat. Die Wartung des Adapters zur Konvertierung der Anlieferungen wird der Softwareanbieter Regnology allerdings voraussichtlich Ende 2025 einstellen.

Von diesem Zeitpunkt an wird er Anpassungen in Abacus, zum Beispiel Fehlerbehebungen im Standard – auch „Defecterhebungen“ genannt – nicht mehr in Embedded und dem bi-direktionalen Adapter vornehmen, sondern nur noch in A360 Native. Erfolgt ab dem Zeitpunkt die Datenanlieferung weiterhin über Embedded, sind kosten- und zeitintensive Workarounds zur Sicherstellung der Meldefähigkeit die Folge.

Weniger komplexe Lieferstrecke – Anpassung der Zulieferschnittstellen als Chance

Die direkte Anbindung der Banksysteme an das Abacus360-Datenmodell bietet große Vorteile. Die Komplexität der Lieferstrecke wird durch weniger Schnittstellen entlang der Verarbeitungsketten verringert – Embedded und der bi-direktionale Adapter entfallen (siehe unsere Darstellung). Dadurch wird die Lieferstrecke weniger fehleranfällig, schneller und besser nachvollziehbar für Drill-down-Analysen.

Durch den Wegfall von zwei Datentransformationsschritten wird außerdem die Performance deutlich verbessert. Neben den monatlichen Meldungen werden unter anderem auch die täglichen Liquiditätsverarbeitungen sowie die Großkreditüberwachung schneller prozessiert. Dadurch gewinnt der Fachbereich künftig mehr Zeit im Meldeerstellungsprozess.

Im Zuge der Anpassungen Potenziale für neue Datenanlieferung heben

Im Zuge der notwendigen Anpassung der Zulieferschnittstelle auf die Abacus360-Strukturen haben Institute zusätzlich die Möglichkeit, weitere Potenziale zu heben. Hierzu zählen der Abbau von historisch entstandenen Workarounds, die stärkere Nutzung von Abacus-Standardfunktionalitäten sowie die Berücksichtigung des Integrated Reporting Framework (IReF) in den neuen Datenanlieferungen.

Daneben hat der Softwareanbieter kommuniziert, dass sich Abacus zukünftig auf Software-as-a-Service (SaaS) in der Cloud ausrichten wird – mit größter Wahrscheinlichkeit auf die Google Cloud Platform (GCP). Bevor ein Institut den Schritt mit Abacus in die Cloud geht, empfiehlt es sich allerdings, zunächst die Zulieferschnittstelle auf die Abacus360-Strukturen zu migrieren. Dadurch werden Projektabhängigkeiten vermieden und überlagernde Effekte bei möglichen Abweichungsanalysen verhindert.

Unser Vorgehensmodell: Grobanalyse gefolgt von Umsetzung entlang der Entitäten

Wie also sollen Banken vorgehen? Auf Basis unserer langjährigen Erfahrungen aus Abacus- und Implementierungsprojekten im Meldewesen empfehlen wir folgende Schritte für eine erfolgreiche Schnittstellenmigration auf die Abacus360-Strukturen:

Erstellen einer Grobanalyse: Betroffene Banken sollten eine Grobanalyse erstellen. Auf Basis der vom Institut lizensierten Abacus-Module wird dargestellt, welche fachlichen Anpassungen nötig sind, um die bisherigen Zulieferungen gemäß der Embedded-Strukturen auf die Abacus360-Strukturen umzustellen. Das Herzstück ist dabei die Logik des bi-direktionalen Adapters.

Im Rahmen der notwendigen Anpassungen der Zulieferungen empfiehlt es sich, weitere Vorhaben wie die Vorbereitung des bankinternen Datenmodells auf IReF oder den Abbau manueller Workarounds im gleichen Projekt zu berücksichtigen. Damit werden Synergien in der einmaligen Anpassung der Schnittstelle ausgenutzt.

Im Ergebnis entsteht bei der Grobanalyse ein Anforderungskatalog mit den anzupassenden Feldern je Abacus360-Entität inklusive eines Testkonzepts. Die Anpassungen je Entität werden hierbei analysiert und für die Umsetzung strukturiert auf einer Zeitachse abgebildet.

Unsere Darstellung zeigt beispielhaft für ein signifikantes Kreditinstitut (Significant Institution, SI), wie sich die Anpassungsbedarfe bei der Migration der Anlieferungen von den aktuellen Embedded-Strukturen auf die A360-Strukturen verteilen:

Betrachtet wurde dafür ein EZB-beaufsichtigtes Kreditinstitut, das das EBA-Reporting, das statistische deutsche Reporting sowie das Single Resolution Board (SRB) Reporting über Abacus abdeckt. Hierbei wäre die Anlieferungslogik von bis zu 1050 Embedded-Datenfeldern betroffen und anzupassen. Die anzupassende Anlieferungslogik gemäß Embedded zahlt auf circa 1800 Datenfelder in Abacus360 ein.

Daneben werden in A360 Native weitere Datenfelder automatisch erzeugt. Informationen hierzu brauchen nicht angepasst oder angebunden zu werden. Die genaue Anzahl der anzupassenden Datenfelder bei einem Kreditinstitut ist anhängig vom Partner- und Produktportfolio sowie den lizensierten Meldemodulen.

Schrittweise Umsetzung entlang der Abacus360-Entitäten: Es empfiehlt sich, die fachlichen Anforderungen iterativ entlang der Abacus360-Entitäten umzusetzen. Das Testing und die Abnahme sollte in zwei Schritten erfolgen: Als erstes in einem Massendatenabgleich in der Abacus360-Eingangsschicht je Entität – das bedeutet, dass ein Vergleich des Abacus360- Datenbestands einmal mit und einmal ohne Adapter erfolgt. Das ist überwiegend ein technischer Vollständigkeitstest und nur bei Abweichungen wird das fachlich plausibilisiert und entsprechend dokumentiert.

Ist die Abacus360-Eingangsschicht analysiert, werden im zweiten Schritt die Meldebögen betrachtet. Das Referenzcluster auf Embedded-Basis wird mittels eines Regressionstests mit dem Zielcluster auf A30 Native abgeglichen. Die erfolgreichen Abnahmetests des Fachbereichs bilden den Abschluss und setzen die Anlieferungen gemäß den Abacus360-Strukturen produktiv.

Anpassung Prozesse und Kontrollen: Schließlich werden für den Go-Live die Batches und alle notwendigen Unterlagen, zum Beispiel Anwenderdokumentationen und Checklisten für die Meldeerstellung, aktualisiert. Wurden im Rahmen der Zulieferanpassungen gemäß den Abacus360-Strukturen darüber hinaus manuelle Workarounds abgebaut oder wesentliche Funktionalitäten, zum Beispiel Ermittlung der risikogewichten Aktiva, verlagert, sind die bisherigen Zulieferprozesse zusätzlich anzupassen.