Wann sollte eine Bank die Automati­sierung des Regulatory Reportings mit einem Entwicklungs­partner bauen, statt Reporting-Software zu kaufen?

Was umfasst die Automatisierung des Regulatory Reportings?

Vier Schritte, die sich getrennt kaufen oder bauen lassen:

1. Erfassen: Daten aus Kernbanksystem, Hauptbuch, Risiko-, Treasury- und Kundensystemen holen.
2. Transformieren und validieren: Daten auf die Vorlagen der Aufsicht abbilden, Validierungsregeln und Abstimmungen ausführen.
3. Prüfen und freigeben: Abweichungen erklären, festhalten, wer was genehmigt hat.
4. Einreichen und archivieren: die Meldung im vorgeschriebenen Format erzeugen, die Nachweise aufbewahren.

Reporting-Software deckt meist die Schritte 2 und 4 gut ab. Das meiste Projektrisiko liegt in den Schritten 1 und 3.

Welche regulatorischen Anker sind in der Schweiz, in Deutschland und in den USA relevant?

Jede Quelle unten ist eine Primär- oder offizielle Seite. Prüfen Sie die aktuelle Fassung, bevor Sie ein Projekt planen.

• Basler Ausschuss, BCBS 239. Das BIS-Papier "Principles for effective risk data aggregation and risk reporting" wurde am 9. Januar 2013 veröffentlicht. Es behandelt die Fähigkeit von Banken, Risikodaten zu aggregieren und über Risiken zu berichten. Laut BIS stärkt die Umsetzung das Risikomanagement der Banken, insbesondere der global systemrelevanten Banken (G-SIBs). Wie Ihre Aufsicht den Standard auf andere Banken anwendet, ist eine Frage für Ihre Compliance-Funktion.
• Schweiz, FINMA. Das FINMA-Rundschreiben 2023/1 "Operationelle Risiken und Resilienz – Banken" ist seit dem 1. Januar 2024 in Kraft und enthält das IKT-Risikomanagement sowie ein Kapitel zu kritischen Daten. Der Abschnitt zu kritischen Daten erwartet, dass Vertraulichkeit, Integrität und Verfügbarkeit über den gesamten Lebenszyklus der Daten sichergestellt sind. Das Rundschreiben schreibt keine Reporting-Software vor. Wo KI im Prozess eingesetzt wird, ist die FINMA-Aufsichtsmitteilung 08/2024 (18. Dezember 2024) Aufsichtspraxis zu Governance und Risikomanagement bei KI, kein Gesetz.
• EU und Deutschland, EBA und BaFin. Banken in der EU melden Aufsichtsdaten nach einem gemeinsamen EBA-Rahmenwerk. Die EBA-Seite zu den Reporting-Frameworks nennt Version 4.2 (veröffentlicht im vierten Quartal 2025, modulspezifische Anwendung ab Dezember 2025) sowie die Versionen 4.3 und 4.4 als für das dritte Quartal 2026 geplant, mit modulspezifischer Anwendung ab Dezember 2026 (4.4 als vorläufig gekennzeichnet; Stand der Seite am 21. Oktober 2026). Die technischen Versionen ändern sich mehrmals im Jahr; das ist das Hauptargument für ein gepflegtes Produkt bei Standardmeldungen. Die nationalen Einreichungswege unterscheiden sich je nach Land; klären Sie sie mit Ihrer nationalen Aufsicht (in Deutschland mit der BaFin).
• USA. US-Banken reichen vierteljährlich Call Reports bei ihrer Bundesaufsicht ein; die Call-Reports-Seite der FDIC nennt die aktuellen Formulare und Anleitungen (FFIEC 031, 041 und 051), und jede Bank klärt Formular und Frist mit ihrer Aufsicht. Wo ein Drittanbieter den Prozess unterstützt, gilt der Interagency Guidance on Third-Party Relationships: Risk Management (Federal Reserve SR 23-4, FDIC und OCC, 7. Juni 2023).
• KI-spezifisch. Ein KI-Agent im Reporting-Prozess kann je nach Einsatz unter den EU AI Act (KI-Verordnung) fallen; siehe EU AI Act compliant AI agents for banks (EN).

Wann schlägt die Eigenentwicklung eine Reporting-SaaS?

Zum Vergleichen wischen →

Faustregel: Je mehr Ihr Problem die Vorlage ist, desto eher sollten Sie kaufen. Je mehr Ihr Problem die Daten sind, die sie speisen, desto eher sollten Sie bauen. Dieselbe Logik gilt für den übrigen Compliance-Stack; siehe Custom or off-the-shelf compliance software (EN).

Wo passen KI-Agenten, und wo nicht?

KI-Agenten schaffen Nutzen rund um die Meldungs-Engine, nicht innerhalb der gemeldeten Zahlen.

• Datenherkunft (Data Lineage). Ein Agent kann eine gemeldete Zahl über die Transformationen bis zu den Quelltabellen zurückverfolgen und diese Karte aktuell halten, wenn sich Systeme ändern. Das unterstützt die Anforderungen an die Daten-Governance hinter BCBS 239.
• Abstimmungen. Ein Agent kann gemeldete Werte mit dem Hauptbuch abgleichen, Abweichungen markieren und eine Erklärung für den Prüfer entwerfen.
• Kommentierung. Ein Agent kann Abweichungskommentare aus den zugrunde liegenden Daten entwerfen. Der Prüfer ergänzt und verantwortet den Text.
• Menschliche Freigabe (Human-in-the-loop). Jede Zahl und jeder Kommentar hat vor der Einreichung einen namentlich benannten Genehmiger. Der Agent reicht nie ein. Legen Sie fest, welche Änderungen einen zweiten Genehmiger brauchen.
• Audit-Trail. Protokollieren Sie Eingaben, Transformationsschritte, Modell- und Prompt-Versionen, die Ausgabe des Agenten, die Änderungen des Prüfers und die Genehmigung, damit sich die Meldung später rekonstruieren lässt. Siehe what a KYC AI audit trail should log (EN); dieselben Protokollierungsprinzipien gelten.

Nicht für Agenten geeignet: die endgültige aufsichtsrechtliche Zahl intransparent zu berechnen. Halten Sie Berechnungen deterministisch und testbar; nutzen Sie den Agenten, um sie zu erklären und zu prüfen.

Was sollten Sie prüfen, bevor Sie entscheiden?

1. Welche Meldungen sind pro Jurisdiktion im Umfang, und welche sind Standardvorlagen?
2. Wie viele Quellsysteme speisen sie, und wie einheitlich sind die Datendefinitionen?
3. Wer verantwortet jedes Taxonomie- oder Formular-Update, und wie wird eine Änderung vor der Einreichung getestet?
4. Können Sie heute jede gemeldete Zahl auf Quelldaten zurückführen? Wie lange dauert das?
5. Welche Schritte sind manuelle Abstimmungen oder Excel, und wie sieht deren Fehlerhistorie aus?
6. Welche Teile sind IKT-Drittdienstleistungen im Sinne von DORA (für EU-Institute), und sind Exit-Rechte vereinbart?
7. Wo liegen die Daten, und wer hat Zugriff? (Claude and Swiss data residency, EN)
8. Wer gibt frei, und welche Nachweise verlangt die Revision?
9. Wer betreibt und pflegt die Lösung nach dem Go-live?

Halten Sie die Antworten schriftlich fest, bevor Sie Offerten einholen; sie legen den Umfang fest, von dem jede Schätzung abhängt.

Wie unterstützt S-PRO Sie?

S-PRO ist ein internationales Schweizer Unternehmen mit Sitz in Zürich (gegründet 2014, 250+ Ingenieure, nach ISO 27001 und ISO 27701 zertifiziert; R&D-Zentren in Zürich und Łódź). Beim Regulatory Reporting arbeitet S-PRO an den Schichten rund um eine Reporting-Engine: Integrationen mit Kern- und Risikosystemen, Services für Datenherkunft und Abstimmung, KI-Agenten für Abstimmungsnotizen und Kommentare mit menschlicher Freigabe sowie die Komponenten für Nachweise und Audit-Trail. Wir arbeiten auf Code und Infrastruktur im Eigentum des Kunden. Siehe AI agent development (EN), Banking software development (EN) und Security and compliance for financial institutions (EN). S-PRO ist zertifizierter Partner im Claude Partner Network. S-PRO erhebt im Namen seiner Kunden keinen Anspruch auf aufsichtsrechtliche Genehmigung oder Zertifizierung.

Um eine Meldung oder eine Abstimmung als erstes Projekt einzugrenzen, sprechen Sie mit unserem Team. Kontakt: S-PRO, Löwenstrasse 45, 8001 Zürich, +41 41 539 15 83.

Quellen

• BIS, Principles for effective risk data aggregation and risk reporting (BCBS 239), 9. Januar 2013
• FINMA-Rundschreiben 2023/1, Operationelle Risiken und Resilienz – Banken
• FINMA-Aufsichtsmitteilung 08/2024 zu Governance und Risikomanagement beim Einsatz von KI
• EBA, Reporting frameworks
• FDIC, Call Reports
• Federal Reserve SR 23-4, Interagency Guidance on Third-Party Relationships: Risk Management, 7. Juni 2023