In meinem letzten Artikel habe ich beschrieben, wie BIRD und IReF das Meldewesen grundlegend verändern werden – und dass Meldewesenexperten sich dabei zu „Regulatory Data Scientists“ entwickeln. Heute mache ich diesen Begriff konkret: Was bedeutet das in der Praxis? Und warum ist Datenqualität der Dreh- und Angelpunkt dieser Transformation?
Was ist ein Regulatory Data Scientist – und warum ist das kein Buzzword?
Ein klassischer Meldewesenexperte denkt in Meldepositionen, Rechtsquellen und Validierungsregeln. Ein Data Scientist denkt in Datenstrukturen, Datenpipelines und Modellen. Ein Regulatory Data Scientist vereint beides – und genau das wird im IReF-Umfeld zur Schlüsseldisziplin.
Vorher – Meldewesenexperte: Er kennt die Meldewesenpositionen auswendig und spricht die CRR fließend für seinen Bereich. Excel ist sein bester Freund in der manuellen Analyse der meldungsrelevanten Daten. Er reagiert er auf Fehler.
Künftig – Regulatory Data Scientist: Der versteht (Daten)Modelle strukturell, insbesondere BIRD strukturell. Arbeitet mit Python, SQL und anderen (Cloud-basierten) Tools. Dieser kennt sich auch in der Arbeit mit AI aus, sie ist integraler Bestandteil seiner Arbeit. Auch ist er in der Lage, Datenqualität in der Datenpipeline zu prüfen – noch bevor sie in das Meldewesentool der Wahl geht. Dadurch ist er in der Lage, Fehler zu antizipieren.
Datenqualität: Der nicht mehr ganz so blinde Fleck im Meldewesen
Die grösste Lektion aus zehn Jahren Migrationsprojekten lautet: Die Fehler liegen nicht nur in der Meldewesensoftware selbst. Sie entstehen viel früher – in den zuliefernden Systemen, an Schnittstellen, in manuell gepflegten Stammdaten und Prozessen.
Der Regulatory Data Scientist löst sich von der reaktiven Fehlerkorrektur. Stattdessen etabliert und treibt er Datenqualität als kontinuierlichen Prozess mit an – direkt im und am Datenpfad, lange bevor die Meldung generiert wird.
Der DQ-Ansatz im IReF-Einführungsprojekt
Grundlage dieses Ansatzes: Die EZB hat signalisiert, dass IReF im BIRD-Modell abgebildet werden soll. Diese Weichenstellung ist entscheidend – denn sie bedeutet, dass die BIRD API bereits heute als Ausgangspunkt für eine strukturierte (DQ-)Vorbereitung genutzt werden kann.
Phase 1: Inventarisierung
Hierzu dient die BIRD API als Grundlage. Mittels dieser API kann die gewünschte Meldung (Framework) auf Ebene des Input Layers extrahiert, der eigene Datenhaushalt dagegen gemappt und ein Gap-Analyse Dokument als lebendiges Dokument erstellt werden.
Phase 2: Profiling mittels Python
Es gibt genügend OpenSource Bibliotheken (u.a. pandas profiling, Great Expectations), die ein automatisches DQ-Reporting ermöglichen. Damit lassen sich DQ-Scorecards je Meldebereich erstellen.
Phase 3: Monitoring
Es werden mittels den Datenpunkten Dashboards errichtet und deren Status mittels einer Ampellogik verfolgt und dokumentiert.
Phase 4: Remediation
Mittels Tickets werden die Fehler adressiert und möglichst zeitnah an der Quelle behoben.
Praxisbeispiel: DQ-App für BIRD/IReF
Genau dieser Ansatz hat mich bewogen, einen POC einer Datenqualitäts-App für BIRD/IReF zu entwickeln. Das Ziel war keine Produktionslösung – dafür gibt es ausgereifte Softwareprodukte. Ziel war eine Vorstudie und Standortbestimmung: Wo stehen wir heute? Welche Datenpunkte fehlen? Wo sind die kritischen Lücken, bevor wir in die IReF-Implementierung einsteigen?
Die Architektur des POC folgt bewusst dem BIRD-Schichtmodell:
- Input Layer: Vollständigkeitsprüfung aller geforderten Attribute
- Transformation Layer: Konsistenzprüfungen zwischen abhängigen Datenpunkten
- Output Layer: Quervalidierung gegen erwartete Meldepositionen
Das Ergebnis ist keine fertige Software – sondern ein strukturiertes Bild des eigenen Datenhaushalts. Und genau das ist der erste Schritt, den jede Bank vor 2029 gegangen sein sollte.
Welche Fähigkeiten braucht der Regulatory Data Scientist?
Niemand muss von heute auf morgen zum Vollzeit-Data-Scientist werden. Aber ein gezielter Kompetenzaufbau in 4 Bereichen macht den Unterschied:
Datenkompetenz ist das absolute Fundament – Wer DQ-Probleme nicht lesen und analysieren kann, kann sie auch nicht lösen. SQL und Profiling sind dabei die minimalsten Werkzeuge, die jeder braucht, der Datenpipelines verstehen will.
Python-Grundlagen sind der natürliche nächste Schritt – es ist das De-facto-Standardwerkzeug für Data Analytics. pandas und Great Expectations sind konkret auf DQ-Aufgaben zugeschnitten und leisten hervorragende Arbeit.
Meldewesenexpertise ist die fachliche Differenzierung und Multiplikator – das ist der Punkt, der einen Regulatory Data Scientist von einem normalen Data Scientist unterscheidet. Er kennt die Meldeprozesse, Datenflüsse, regulatorische Logik. BIRD ist die Zugabe als aktuelle Formalisierung.
KI-Grundlagen sind ebenso wichtig. Der Regulatory Data Scientist muss keine KI bauen – er muss KI nutzen können. Wer bspw. Perplexity für (regulatorische) Recherche einsetzt und Claude für die Code-Umsetzung, multipliziert seine eigene Expertise, ohne Data-Science-Studium.
Der Regulatory Data Scientist ist keine Zukunftsvision. Er ist eine Notwendigkeit – und mit gezieltem Kompetenzaufbau auch für jeden erfahrenen Meldewesenexperten erreichbar.
Fazit: Datenqualität ist keine IT-Aufgabe – sie ist eine Fachaufgabe
Die vielleicht wichtigste Erkenntnis aus meiner Arbeit: Datenqualitätsprobleme sind fast immer fachliche Probleme mit technischem Symptom. Wer im IReF-Zeitalter erfolgreich sein will, muss beides können – die regulatorische Substanz und die datentechnische Umsetzung verstehen.
Ausblick: Wer die Daten im Griff hat, kann KI ernten
Und hier schliesst sich der Kreis: Wer saubere,qualitätativ hochwertige granulare Daten (im BIRD-Format vorhält), legt gleichzeitig die Grundlage für den nächsten Entwicklungsschritt. Denn KI-Modelle sind nur so gut wie die Daten, auf denen sie trainiert werden.
Wer heute investiert – in DQ-Prozesse, in Datenpipelines, in das Verständnis des BIRD-Modells – der öffnet morgen die Tür für KI-gestützte Anomalieerkennung, automatisierte Plausibilitätsprüfungen und LLMs als Regulatory Interpreter (meine Bold Prediction 🙂 ). Datenqualität ist nicht das Ziel – sie ist die Voraussetzung.
Wie das in der Praxis aussieht – und welche KI-Werkzeuge im regulatorischen Arbeits(Umfeld) wirklich funktionieren können – das ist Thema von Teil 3.