Worum es geht und warum es jetzt zählt
In Risk-Abteilungen deutscher und österreichischer Banken läuft seit etwa 18 Monaten eine stille Verschiebung. ML-Modelle für Kreditrisiko, Fraud-Detection und Stress-Testing werden zunehmend nicht mehr ausschließlich auf historischen Echtdaten trainiert, sondern auf synthetisch generierten Datensätzen. Die Argumente liegen auf der Hand: DSGVO-Restriktionen fallen weg, Tail-Events lassen sich künstlich erzeugen, Modell-Updates werden schneller.
Das Problem: Die Aufsicht hat zu dieser Praxis bisher keine klar kodifizierte Position. Die BaFin verweist auf MaRisk AT 4.3.4 zur Modellvalidierung. Die EZB prüft im Rahmen von TRIM (Targeted Review of Internal Models) die Repräsentativität der Trainingsbasis. Was passiert, wenn diese Trainingsbasis zu 60 oder 80 Prozent synthetisch ist? Die Antwort ist nicht „verboten“. Sie ist „erklären Sie es uns“. Und genau dort scheitern aktuell die meisten Institute.
Dieser Artikel beschreibt, was DACH-Banken konkret vorbereiten müssen, bevor das erste synthetisch trainierte ML-Modell in einem ICAAP-Bericht oder einer SREP-Prüfung auftaucht.
Warum DACH-Banken synthetische Trainingsdaten überhaupt brauchen
Der wichtigste Treiber ist nicht DSGVO. Es ist Datenmangel bei Tail-Events.
Ein Kreditrisikomodell, das makroökonomische Stresspfade abbilden soll, hat ein strukturelles Problem: schwere Krisen sind selten. Die Datenbasis für 2008, 2011 und 2020 ist verfügbar, aber sie deckt drei sehr unterschiedliche Schockmuster ab. Ein ML-Modell, das auf drei Beobachtungen mit jeweils mehreren tausend Features trainiert wird, lernt im Wesentlichen Rauschen. Klassische statistische Modelle kommen damit zurecht, weil ihre Parameteranzahl klein ist. Moderne ML-Architekturen brauchen Tausende bis Millionen Beobachtungen.
Dazu kommt der zweite Treiber: DSGVO Artikel 5 und die Zweckbindung. Echtkundendaten dürfen für Modelltraining nur unter strengen Anonymisierungs- und Pseudonymisierungsauflagen verwendet werden. Wer ein Modell auf 50 Millionen historischen Transaktionen trainieren will, baut entweder eine aufwendige Anonymisierungspipeline mit Differential-Privacy-Garantien, oder er generiert synthetisch.
Der dritte Treiber ist regulatorischer Druck zu häufigeren Modell-Updates. Die EBA-Guidelines zu Modellvalidierung erwarten regelmäßige Re-Kalibrierung. Realdaten wachsen aber linear mit der Zeit. Synthetische Daten lassen sich on-demand erzeugen.
In der Praxis sieht die Aufteilung in DACH-Instituten meist so aus: vollsynthetische Datensätze nur für Pre-Training oder Augmentation, teilsynthetische Datensätze (Realdaten plus generierte Tail-Events) für die eigentliche Modellkalibrierung, reine Realdaten für die finale Validierung. Diese Hybrid-Architektur ist aufsichtsrechtlich am besten verteidigbar.
Generierungsverfahren im Bankkontext: GAN, VAE und statistische Simulation
Drei Methodenfamilien dominieren.
GAN-basierte Ansätze (Generative Adversarial Networks) sind die populärste Wahl für Zeitreihen-Finanzdaten. Sie können komplexe Abhängigkeitsstrukturen zwischen Variablen lernen. Ein typisches Beispiel: ein Großbank-Risikomodellierer trainiert ein TimeGAN auf historischen Spread-Bewegungen, um synthetische Stresspfade für illiquide Assets zu erzeugen. Das funktioniert technisch gut. Das aufsichtsrechtliche Problem: GANs neigen zu Mode Collapse und Overfitting auf den Seed-Datensatz. Wer einer BaFin-Prüfung erklären muss, warum ein GAN trainiert auf 200 historischen Krisenmonaten „repräsentative“ Stresspfade erzeugt, hat eine schwere Argumentationslast.
Variational Autoencoders (VAE) werden zunehmend für Kreditportfolios eingesetzt. Der Vorteil: die latente Repräsentation lässt sich teilweise interpretieren. Ein VAE auf einem Mittelstands-Kreditportfolio kann latente Risikofaktoren wie Branchenexposure, Größenklasse, regionale Konzentration extrahieren und in der Generierung kontrolliert variieren. Das Risiko: wenn die latente Struktur die echte Risikohierarchie zerstört, generiert das Modell statistisch korrekte, aber ökonomisch unsinnige Portfolios.
Statistische Bootstrapping- und Copula-Methoden sind die regulatorisch am besten erklärbare Alternative. Eine Gaussian Copula oder eine t-Copula auf einem Kreditausfallportfolio ist seit zwanzig Jahren in der Aktuarsliteratur etabliert. Die Aufsicht versteht das Verfahren. Die Repräsentativitätsdiskussion lässt sich auf klassische statistische Tests stützen. Der Preis: weniger Flexibilität, weniger Realismus bei komplexen Abhängigkeitsstrukturen.
Die Faustregel aus meiner Sicht: Wer in der MaRisk-Welt argumentieren muss, beginnt mit Copula. Wer ein Forschungsbudget hat und ein zweites Validierungsteam, kann GAN oder VAE einsetzen. Der Dokumentationsaufwand ist nicht doppelt so hoch, sondern eher fünffach.
Das DSGVO-Problem ist gelöst, das Modellvalidierungsproblem beginnt
Die verbreitete Erzählung lautet: synthetische Daten umgehen DSGVO, also haben wir einen Compliance-Win. Das stimmt für den Datenschutz. Für die Modell-Compliance gilt das Gegenteil.
Drei Problemfelder treten auf.
Erstens: Distribution Shift. Wenn die synthetischen Daten reale Stressmuster nicht korrekt abbilden, lernt das Modell ein verzerrtes Risiko. Ein Beispiel: ein GAN, das auf Vor-Corona-Daten trainiert wurde, generiert Stresspfade, die Liquiditätsschocks im Anleihemarkt unterschätzen, weil dieses Muster im Trainingsset nur schwach vorkommt. Das Modell sieht in der Validierung gut aus. In der nächsten realen Krise versagt es.
Zweitens: Black-Box-Validierung. Wie prüft ein Modellvalidierer, ob ein auf synthetischen Daten trainiertes Modell echte Risiken erkennt? Die Standardantwort ist Out-of-Sample-Test auf echten Daten. Aber wenn echte Daten der knappe Faktor sind, ist das Validierungs-Sample notwendig klein. Statistische Power-Probleme entstehen.
Drittens: das Erklärbarkeits-Paradox. Mehr Datenmenge durch Synthese sollte zu robusteren Modellen führen. Gegenüber Prüfern ist das Modell aber schwerer zu erklären, weil die Trainingsbasis nicht mehr eindeutig auf historische Realität rückführbar ist. Ein Prüfer der BaFin fragt: „Zeigen Sie mir den Datensatz, auf dem dieses Modell trainiert wurde, und erklären Sie mir, warum er repräsentativ für unser Portfolio ist.“ Bei synthetischen Daten beginnt die Antwort mit: „Wir haben einen Seed-Datensatz von X Beobachtungen, und unser Generator hat daraus Y Beobachtungen erzeugt, deren Verteilungseigenschaften wir wie folgt validiert haben...“ Das ist keine Killer-Frage. Es ist eine Verteidigungslast.
Was die BaFin bei synthetisch trainierten ML-Modellen konkret erwartet
Die aufsichtsrechtliche Landschaft ist nicht leer, sie ist nur fragmentiert.
MaRisk AT 4.3.4 verlangt grundsätzlich, dass Modelle angemessen validiert sind und ihre Annahmen, Datenbasis und Grenzen dokumentiert sind. Das gilt unverändert für ML-Modelle und unverändert für synthetisch trainierte Modelle. Der Punkt: „Datenbasis“ umfasst dann auch die Generierungsmethodik der synthetischen Daten.
EZB TRIM prüft bei internen Modellen die Repräsentativität der Trainingsbasis als zentrales Kriterium. TRIM-Findings zu synthetisch trainierten Modellen sind öffentlich nicht dokumentiert, aber die EZB-Position in informellen Industriegesprächen ist konsistent: synthetische Daten sind nicht verboten, aber der Repräsentativitätsnachweis muss formal stärker sein als bei reinen Realdaten.
Lineage-Dokumentation ist hier der Schlüsselbegriff. Die Aufsicht erwartet zunehmend, dass für jedes Trainings-Sample nachvollziehbar ist: Stammt es aus realer Beobachtung oder aus Generierung? Welche Methodik? Welcher Seed-Datensatz? Welche Validierungstests wurden durchgeführt? Diese Metadaten sind kein Nice-to-have, sie sind Mindeststandard.
Aktuelle BaFin-Konsultationen zu KI/ML-Modellrisiko zeigen die Richtung. Die BaFin hat in 2024 mehrfach betont, dass sie für ML-Modelle keine separate Aufsichtspraxis schaffen will, sondern bestehende Anforderungen anwendet. Übersetzt heißt das: wer ein synthetisch trainiertes Modell einsetzt, bekommt keine Sondererlaubnis, aber auch kein Sonderverbot. Er muss die normale Modellvalidierungs-Latte schaffen.
Abgrenzung Stress-Testing- versus Kreditrisikomodelle: Stress-Testing-Modelle haben tendenziell eine niedrigere Prüfintensität als IRBA-Kreditrisikomodelle. Wer synthetische Daten erstmals einsetzt, beginnt aus pragmatischen Gründen oft bei Stress-Testing. Das ist regulatorisch klüger, weil die Prüfungstoleranz höher ist.
Stress-Testing mit synthetischen Daten: Chancen und Fallstricke
Im Stress-Testing liefern synthetische Daten echten Mehrwert. Genau hier liegt aber auch ein regulatorischer Stolperdraht.
Die Chance: makroökonomische Schock-Szenarien lassen sich systematisch generieren. Ein Institut kann synthetisch Zinsschocks, Spread-Ausweitungen, Liquiditätskrisen in Kombinationen erzeugen, die historisch nie aufgetreten sind, aber plausibel wären. Das ist genau das, was ICAAP-Verantwortliche brauchen.
Die EBA-Stress-Test-Anforderungen verlangen historisch kalibrierte Szenarien für die EU-weiten Tests. Hausinterne Stress-Tests dürfen darüber hinausgehen, müssen aber ihre Plausibilität nachweisen. Hier kommt die Back-Testing-Pflicht ins Spiel: Institute müssen zeigen, dass ihre synthetisch generierten Stresspfade konsistent sind mit beobachtbaren Marktstressen. Konkret heißt das: jeder generierte Pfad sollte sich gegen mindestens ein historisches Analog vergleichen lassen.
Ein typisches Praxisbeispiel im DACH-Mittelbankenkontext: ein Institut nutzt synthetische Kreditausfall-Kaskaden für ICAAP. Die Methodik: ein VAE wird auf historischen Ausfallkorrelationen aus 2008 und 2011 trainiert. Der Generator erzeugt 10.000 synthetische Pfade. Die Validierung vergleicht die Verteilungsmomente der synthetischen Pfade mit historischen. Die Lineage-Dokumentation umfasst Seed-Daten, Hyperparameter des VAE, Validierungstests, Out-of-Sample-Performance. Diese Dokumentation umfasst typischerweise 40 bis 80 Seiten pro Modell. Wer das nicht hat, hat das Modell nicht.
Lineage-Dokumentation als strategischer Vorteil
Mein Eindruck aus Gesprächen mit Risk-Verantwortlichen in DACH: Lineage-Dokumentation wird noch als Compliance-Last gesehen. Das ist kurzfristig richtig. Mittelfristig ist sie ein strategischer Vorteil.
Eine vollständige Datengenerierungs-Lineage muss enthalten:
- Seed-Daten: Quelle, Zeitraum, Filterungen, Pseudonymisierungsschritte
- Methodik: Verfahren (GAN, VAE, Copula), Hyperparameter, Trainingsdauer, Konvergenzkriterien
- Validierungsschritte: statistische Tests auf Verteilungsähnlichkeit, ökonomische Plausibilitätsprüfungen, Out-of-Sample-Vergleiche
- Versionierung: jede Datensatz-Version mit eindeutigem Hash, Erstellungszeitpunkt, verantwortlicher Modellierer
Manuelle Audit-Trails in Excel sind dafür nicht ausreichend. Wer ernsthaft synthetische Daten einsetzt, braucht eine MLOps-Pipeline mit automatisierter Lineage-Erfassung. Tools wie MLflow, Weights and Biases oder spezialisierte Data-Lineage-Plattformen sind hier Standard. Bankspezifisch heißt das oft: Eigenentwicklung auf Basis dieser Komponenten, weil out-of-the-box keine Lösung die regulatorische Tiefe abdeckt.
Der Hebel: Wer Lineage automatisiert, verkürzt Modellzulassungsverfahren. Ein typischer interner Modellfreigabe-Prozess in einer mittleren DACH-Bank dauert 6 bis 12 Monate. Mit sauberer Lineage lässt sich das auf 3 bis 6 Monate reduzieren, weil Validatoren und Prüfer schneller Sicherheit gewinnen.
Verbindung zum EU AI Act: Anhang IV verlangt technische Dokumentation für Hochrisiko-KI-Systeme. Kreditbewertungssysteme sind explizit Hochrisiko. Wer Lineage-Dokumentation heute aufbaut, erfüllt damit gleichzeitig Anforderungen aus MaRisk und AI Act. Das ist der Compliance-Doppelnutzen.
Handlungsempfehlungen für Risk-Manager und Modellvalidierer
Für drei Rollen unterschiedliche Schritte.
Für Modellentwickler im Risk-Bereich: Bevor Sie das erste synthetisch trainierte Modell starten, erstellen Sie eine Checkliste mit Mindestanforderungen. Mindestens enthalten: Seed-Datensatz mit dokumentierter Repräsentativität, gewähltes Generierungsverfahren mit Begründung, drei statistische Verteilungstests gegen Realdaten, ökonomische Plausibilitätsprüfung durch einen unabhängigen Reviewer, Versionierung jedes Datensatzes. Ohne diese fünf Punkte beginnen Sie das Projekt nicht.
Für Modellvalidierer und Risk-Governance: Klären Sie die Verantwortungsstruktur. Wer im Institut verantwortet die Qualitätssicherung synthetischer Trainingsdaten? In den meisten DACH-Banken ist diese Rolle nicht definiert. Faustregel: die Modellvalidierungs-Einheit (zweite Verteidigungslinie) sollte die Methodik der Datengenerierung prüfen, nicht die Modellentwicklung selbst. Trennung der Verantwortlichkeiten ist hier nicht akademisch, sie ist aufsichtsrechtlich relevant.
Für Vorstand und Aufsichtsdialog: Wenn Sie synthetische Datenansätze einsetzen oder einsetzen werden, kommunizieren Sie das proaktiv mit der Aufsicht. Die schlechteste Variante ist, dass die BaFin in einer Routineprüfung entdeckt, dass ein internes Modell zu 70 Prozent auf GAN-Output trainiert wurde, ohne dass das vorher dokumentiert war. Die beste Variante ist, dass Sie im jährlichen Aufsichtsgespräch das Thema von sich aus auf die Agenda setzen. Das kostet kurzfristig Erklärungsarbeit. Es spart mittelfristig Findings.
Nächster Schritt für Einsteiger-Institute: Beginnen Sie mit einem klar abgegrenzten Pilotprojekt. Empfohlener Scope: ein Stress-Testing-Modell, nicht ein regulatorisches IRBA-Modell. Empfohlene Methodik: Copula-basiert, nicht GAN. Empfohlener Zeitrahmen: 6 Monate für Pilot, 12 Monate bis zur ersten produktiven Nutzung. Wer schneller will, scheitert an der Dokumentation.
Mein Rat zum Schluss
Synthetische Trainingsdaten sind kein Hype. Sie sind die einzige skalierbare Antwort auf das strukturelle Datenproblem moderner Bankrisiko-Modellierung. Die Frage ist nicht, ob DACH-Banken sie einsetzen, sondern wann und wie kontrolliert.
Die aufsichtsrechtliche Position der BaFin und EZB ist nicht restriktiv, sondern erklärungsbedürftig. Wer Lineage, Validierung und Repräsentativitätsnachweis sauber aufbaut, kann synthetische Daten heute schon einsetzen. Wer das ohne Dokumentation tut, baut Modellrisiko und Prüfungsrisiko gleichzeitig auf.
Mein Tipp: Beginnen Sie nicht mit dem ambitioniertesten Use-Case. Beginnen Sie mit dem dokumentationsfreundlichsten. Stress-Testing vor Kreditrisiko, Copula vor GAN, Pilot vor Skalierung. In 18 Monaten, wenn die nächste TRIM-Welle kommt, werden die Institute mit sauberer Lineage einen messbaren Wettbewerbsvorteil haben. Die anderen werden Findings abarbeiten.