Eine große, international tätige Bank musste ihre risikogewichteten Aktiva (RWA) gemäß den regulatorischen Anforderungen nach Basel II  an die jeweiligen Aufsichtsbehörden melden. Die Berechnung der Ergebnisse erfolgte mit Fermat, einem führenden Produkt zur Ermittlung von Basel II Kennzahlen.

Um die Berechnung mit Hilfe von Fermat durchführen zu können, mussten sämtliche Einzelgeschäfte in eine je nach Finanzinstrument unterschiedliche Datentabelle geladen werden. Da sich die Bank für eine dezentrale Architektur ausgesprochen hat (jede größere Organisationseinheit hat ihre eigene Fermat Installation) wurden unterschiedliche ETL Tools bemüht, um die Datenbestände gemäß den Fermat Anforderungen zu transformieren und zu beladen.
Neben den ca. 30 rein transaktionalen Geschäftstabellen für Darlehen, Netting, Kontrahenten etc., mussten ca. 60 Parametertabellen so befüllt werden, dass alle Geschäfte sowohl gemäß den Bestimmungen der nationalen Aufsichtsbehörde als auch der des Mutterkonzerns berechnet werden können (sog. Home/Host Vorschrift).
Hoher Projektaufwand

Der gesamte Projektaufwand innerhalb der Bankengruppe war sehr hoch. Neben der Beschaffung, Transformation und dem Fermat-konformen Beladen der Daten (ETL) waren es insbesondere die technischen und fachlichen Tests, die zu hohen Kosten führten.

Bevor RapidRep zum Einsatz kam, wurde das Testen fast vollständig mit einer eigens in Excel implementierten Lösung umgesetzt. Das Team bestand aus ca. 20 Testern, die je nach Test Cluster unterschiedliche Formate in den Excel Arbeitsblättern benutzten. Auf diese Weise wurden Testdaten und erwartete Ergebnisse in Excel abgelegt und durch manuelle Schritte mit den berechneten Ergebnissen abgeglichen.

Herausforderungen

Die folgenden Faktoren belegen die hohen Anforderungen an das Testen der  Basel II Ergebnisdaten:

• Die Datenanforderungen waren hoch und konnten nur schwer erfüllt werden. Es gab häufig Probleme mit der Qualität der Daten.
• Im Team war geringes  Know-how in Basel II allgemein und in der Software Fermat vorhanden. Die Frage, ob ein Testfall korrekt war oder nicht konnten die Tester vielfach nicht richtig beantworten.
• Das Defect Management wurde nur unzureichend umgesetzt. Die Fehler wurden häufig unvollständig in Mercury TestDirector erfasst, so dass Business Analysten große Mühe hatten,  die Fehler zu reproduzieren und zu analysieren.
• Die Regelungen in Basel II waren jahrelang im Fluss, ebenso die bankinternen Richtlinien bezüglich des fortgeschrittenen Ansatzes. Das Testing unterlag großen strukturellen Änderungen.
• Der eingesetzte Rechenkern von Fermat durchlief zahlreiche Versionen und Patches.
• Die Anzahl der Testfälle war sehr hoch (mehrere tausend Testfälle).
• Ein eng gesteckter Zeitplan führte dazu, dass schnelle Ad-hoc-Lösungen Vorrang vor strukturellen Verbesserungen hatten.

Konsequenz

Lange Testzyklen und hohe Kosten

Alle Testzyklen (System-/Komponenten-/Akzeptanz-Tests) dauerten sehr lange und es waren keine Verbesserungen im Prozess zu beobachten, weder qualitativ noch zeitlich.
Die hochgradig manuell durchgeführten Testzyklen konnten aufgrund der Vielzahl und Komplexität der Tests (Asset Backed Securities, Cross Border Abgrenzungen etc.) nicht mehr bewältigt werden.

Gleichzeitig entschied die Bank aus Kostengründen das Testen nach Indien auszugliedern. Dies war ein geeigneter Zeitpunkt um sich eine neue Teststrategie zu überlegen.

Lösung

Der Schlüssel zur Lösung dieser Probleme war die Umstellung des Testprozesses mit Hilfe von RapidRep.

Folgende Schritte wurden durchgeführt:

• SQL-Experten konstruierten mit Hilfe des RapidRep Designers eine Reportdefinition, die das technische und fachliche Know-how der jeweiligen Version des Rechenkerns und der Basel II Regeln kapselten.  Dies  gelang mit einer einzigen Reportdefinition, welche alle Test-Cluster für Retail und Non-Retail (incl. Credit Risk Mitigation und ABS) abdecken konnte.
• Die Tester konzentrierten sich in der Folge darauf, Testfälle zu definieren und die Testdaten zu laden. Die aufwendige, manuelle Interpretation der Ergebnisse wurde durch RapidRep automatisiert.
• Die Tester (in der Übergangsphase waren dies Ressourcen in Europa und Indien, später dann nur noch in Indien) verwendeten diese Reportdefinition im RapidRep Runner zur Validierung der Ergebnisse. Ein Farbcode in den Excel Sheets erlaubte zudem das schnelle Erkennen von Regressionsfehlern.
• Fehlgeschlagene Testfälle wurden zusammen mit dem RapidRep Excel Report in Mercury TestDirector hochgeladen. Dieses Excel Workbook enthielt alle Informationen, die ein Business Analyst benötigte, um Fehler zu reproduzieren und Fehlerursachen erkennen zu können.

Der Erfolg

Alle Maßnahmen haben sich als ausgesprochen wirksam herausgestellt. Die Dauer eines vollständigen Testzyklus -  Laden der Daten -> Berechnung -> Validierung der Ergebnisse - hat sich in der Folge um fast die Hälfte verringert, die für die Validierung der Ergebnisse benötigte Zeit konnte auf ein Zehntel reduziert werden!

In dieser Zeitersparnis ist noch nicht berücksichtigt, dass auch das nachgelagerte Defect Management durch den Einsatz von RapidRep profitieren konnte. Analysten waren aufgrund der gesammelten Detailinformationen in den Excel Workbooks in der Lage, die Fehlerursachen schneller zu identifizieren und somit den Zyklus zur Problemlösung entscheidend zu verringern.

Die Trennung in RapidRep Designer und RapidRep Runner hat das Outsourcing der Testaktivitäten nach Indien auf ideale Weise unterstützt. Die fachlich/technische Expertise in Form der Reportdefinition blieb während der ersten Monate in Europa, während die Massentests mit dem RapidRep Runner in Indien durchgeführt wurden.