KI-basiertes Kreditrisiko-Frühwarnsystem

Das echte Ausmaß des Problems

Der klassische Kreditüberwachungsprozess in deutschen Banken und Sparkassen sieht so aus: Ein Rating wird bei der Kreditvergabe erstellt, aktuell gehalten über Jahresabschlüsse, und im Jahresrhythmus überprüft. Was in der Zwischenzeit passiert — Umsatzeinbrüche, wachsende Kontoüberziehungen, veränderte Zahlungsdisziplin gegenüber Zulieferern — fällt systematisch durch das Raster.

Das ist kein Organisationsversagen. Es ist eine mathematische Unmöglichkeit: Ein Relationship-Manager mit 300 bis 600 laufenden Engagements kann nicht wöchentlich alle Kontoverläufe prüfen. Die Prüfung erfolgt anlassbezogen — und der Anlass ist meistens der erste Verzug.

Die Zahlen hinter diesem Problem sind erheblich. Die Europäische Zentralbank meldete im Supervisory Newsletter vom August 2025 (zum Thema „Funken löschen bevor es brennt”), dass die NPL-Quote bei KMU-Portfolios trotz historischer Tiefststände auf 4,78 Prozent verharrt. Beunruhigender ist der Anstieg der Stage-2-Quote: Kredite mit erhöhtem Ausfallrisiko, aber noch ohne konkreten Verzug. Nach IFRS 9 müssen Banken für diese Engagements erhöhte Rückstellungen bilden — ein erheblicher Ergebnisdruck, der durch frühzeitiges Eingreifen vermeidbar wäre. Für die nächsten Jahre rechnen Marktbeobachter mit einem deutschen NPL-Volumen von bis zu 60 Milliarden Euro.

Was Ausfälle für eine Bank wirklich kosten, wird oft unterschätzt. Neben dem direkten Forderungsverlust entstehen Kosten für Einzelwertberichtigungen (EWB), für die Intensivbetreuung notleidender Kredite, für rechtliche Inkassoverfahren und — bei IRB-Instituten — für eine verschlechterte Risikoparameter-Kalibrierung, die Eigenkapitalanforderungen nach Basel IV treibt. Eine vollständige NPL-Abschreibung kostet eine Bank erfahrungsgemäß das Drei- bis Sechsfache des nominalen Forderungsbetrags, wenn man alle Kosten über den gesamten Verwertungsprozess mitrechnet.

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ Erfahrungswerte aus Pilotimplementierungen; stark abhängig von Portfolioqualität, Datenverfügbarkeit und Qualität der Gegensteuerungsmaßnahmen. Peer-reviewed Ergebnisse: XGBoost-basiertes Frühwarnsystem reduzierte NPL von 5,25 % auf 3,63 % (Springer Proceedings, 2024).

Einschätzung auf einen Blick

Zeitersparnis — mittel (3/5)
Das System automatisiert den manuellen Portfolio-Scan vollständig — Relationship Manager erhalten täglich eine priorisierte Watchlist statt selbst durch Hunderte Kontoverläufe zu blättern. Die Zeitersparnis ist real: etwa 1,5 bis 2 Stunden täglich pro Kreditbetreuer. Das ist kein schlechter Wert, aber auch nicht der dominante Hebel — der liegt eindeutig bei der Kostenersparnis durch vermiedene Ausfälle. Deshalb Mittelfeldposition in dieser Kategorie.

Kosteneinsparung — sehr hoch (5/5)
Das ist der stärkste Hebel im gesamten Finanzen-Portfolio. Ein einziger vermiedener Firmenkundenausfall im sechsstelligen Bereich übersteigt die Jahreskosten des Systems typischerweise um das Fünf- bis Sechsfache. Bei einem Kreditportfolio von 100 Millionen Euro und einer NPL-Verbesserung von nur einem Prozentpunkt sprechen wir von einer Million Euro weniger Ausfallvolumen — plus die gesparten EWB-Zuführungen, Inkassokosten und Risikogewichteeffekte auf die Eigenkapitalquote.

Schnelle Umsetzung — sehr niedrig (1/5)
Das ist keine Untertreibung. Zwischen Projektstart und produktivem Betrieb liegen realitätsnah 8 bis 14 Monate. Die Gründe: Datenpipeline aufbauen, historische Kreditdaten bereinigen, Modell trainieren, regulatorische Anforderungen nach MaRisk AT 4.3.5 erfüllen, unabhängige Modellvalidierung durchführen, Vorstandsfreigabe einholen. Wer das in 6 Monaten plant, wird enttäuscht. Der Vergleich mit anderen Use Cases wie KI-gestützter Kreditwürdigkeitsprüfung zeigt: Regulatorisch anspruchsvolle Kredit-KI-Systeme sind generell keine Schnellprojekte.

ROI-Sicherheit — hoch (4/5)
Das Ergebnis ist direkt messbar: Ausfallquote vor versus nach Einführung, EWB-Zuführungsquoten, Anzahl rechtzeitiger Interventionen. Das ist konkreter als viele andere KI-Use-Cases, bei denen der Nutzen schwer zu isolieren ist. Nicht volle 5, weil wirtschaftliche Zyklen den Wert verzerren können — in einem Aufschwung würde auch ein schlechteres Modell gut aussehen — und weil die ersten Monate nach Go-live typischerweise eine Kalibrierungsphase sind, in der viele Alerts noch falsch-positiv sind.

Skalierbarkeit — hoch (4/5)
Ein trainiertes Modell überwacht 500 und 5.000 Engagements zum nahezu gleichen Preis. Das ist echter Hebel bei wachsenden Portfolios oder bei Fusionen von Banken. Nicht ganz 5, weil jede wesentliche Portfolio-Erweiterung (neue Kundensegmente, neue Produkte, neue Branchen) eine Modell-Anpassung und Re-Validierung erfordert — der regulatorische Overhead wächst also nicht proportional, aber auch nicht gegen null.

Richtwerte — stark abhängig von Portfoliogröße, Datenintelligenz und Institut.

Was das System konkret macht

Ein KI-basiertes Kreditrisiko-Frühwarnsystem ist kein einzelnes Werkzeug, sondern eine Datenpipeline mit drei Schichten:

Schicht 1: Datenintegration. Das System zieht täglich oder wöchentlich Daten aus mehreren Quellen: Kontoverkehrsdaten aus dem Kernbankensystem (Umsätze, Überziehungen, Rücklastschriften, Zahlungsverhalten gegenüber dem eigenen Institut), Jahresabschlüsse und Bilanzkennzahlen aus dem Kreditmanagementsystem, und optional externe Wirtschaftsinformationen — Branchen-Konjunkturindikatoren, Insolvenzstatistiken im Sektor, Bonitätsänderungen bei Handelspartnern via Creditsafe oder Orbis (Moody’s).

Schicht 2: Modell-Scoring. Ein Machine Learning-Modell — typischerweise ein Gradient-Boosting-Verfahren wie XGBoost oder LightGBM — berechnet für jedes Engagement täglich einen Risikoindikator. Das Modell wurde auf historischen Kreditdaten trainiert: Es hat gelernt, welche Muster von Kontoauffälligkeiten, Branchenveränderungen und Bilanzkennzahlen typischerweise 3 bis 12 Monate vor einem Ausfall auftauchen. Der Output ist kein binäres Signal, sondern ein kontinuierlicher Score, der mit dem letzten Score verglichen wird — relevanter als die Absolutgröße ist die Richtung und Geschwindigkeit der Veränderung.

Schicht 3: Alert-Management und Erklärbarkeit. Das System generiert eine tägliche Watchlist mit priorisierten Engagements, geordnet nach Dringlichkeit. Entscheidend für den regulatorischen Betrieb: Für jeden Alert werden die Top-3 bis Top-5 Treiber in lesbarer Form ausgewiesen — „Score verschlechtert um 18 Punkte, Haupttreiber: Kontoüberziehungsfrequenz +240%, Branchenindex Metallverarbeitung -12%”. Ohne diese Erklärbarkeit ist das System nach MaRisk und EU AI Act-Anforderungen nicht genehmigungsfähig.

Optional fügen fortgeschrittene Systeme eine LLM-Schicht hinzu: Das Sprachmodell liest die strukturierten Alert-Daten und verfasst einen vorläufigen Gesprächsleitfaden für das Kundengespräch — inklusive der drei offenen Punkte, die der Relationship Manager klären sollte. Das spart nochmals 30 bis 60 Minuten Vorbereitungszeit pro Alert-Fall.

Regulatorische Realität: Was BaFin und EBA konkret fordern

Das ist der Teil, der in vielen Projekten unterschätzt wird und zu erheblichen Verzögerungen führt.

MaRisk AT 4.3.5 (8. Novelle, Mai 2024). Die BaFin hat mit ihrer 8. MaRisk-Novelle einen neuen Abschnitt speziell für KI-gestützte Risikomodelle eingeführt. Verlangt werden: Nachvollziehbarkeit der Modellergebnisse (Explainability), Dokumentation von Trainingsdaten und Modellannahmen, regelmäßige Validierung mit nachgewiesener Unabhängigkeit zwischen Modellentwicklung und -prüfung, und ein definierter Prozess für die Reaktion auf Modell-Drift (dazu mehr im Abschnitt unten).

EBA Follow-up Report on Machine Learning for IRB Models (2023). Die Europäische Bankenaufsichtsbehörde hat in diesem Bericht klargestellt, dass ML-Modelle für Kreditrisikoeinschätzungen zwar erlaubt sind, aber erhöhte Validierungsanforderungen mitbringen. Konkret: Bei Modellen mit begrenzter Interpretierbarkeit oder häufiger Aktualisierung ist eine erhöhte Validierungstiefe und -frequenz erforderlich. Das bedeutet: Ein Black-Box-Modell ohne SHAP-Werte oder äquivalente Erklärungsmethoden wird eine aufsichtliche Prüfung in der Regel nicht bestehen.

EU-KI-Verordnung (Hochrisiko-Klassifizierung). Systeme zur Kreditwürdigkeits- und Kreditrisikobewertung von natürlichen und juristischen Personen fallen unter Anhang III der EU-KI-Verordnung als Hochrisiko-KI-Systeme. Das bringt Pflichten mit sich: technische Dokumentation, Risikomanagementsystem, Transparenz gegenüber beaufsichtigten Instituten und — wo anwendbar — DSGVO-konformes Auskunftsrecht für Betroffene.

DSGVO Art. 22 und das Automatisierungsverbot. Wenn das Frühwarnsystem automatisiert eine Entscheidung mit wesentlicher Auswirkung auf einen Kreditnehmer trifft — etwa eine automatische Rating-Verschlechterung, die ohne menschliche Prüfung zu Kreditkündigung führt — greift Artikel 22 DSGVO. Das System muss so gebaut sein, dass der Relationship Manager die maßgebliche Entscheidung trifft, nicht der Algorithmus. In der Praxis bedeutet das: Die KI warnt und priorisiert, der Mensch entscheidet und dokumentiert.

Praktische Konsequenz: Plane für regulatorische Anforderungen mindestens 3 bis 4 Monate Vorlaufzeit ein, bevor das Modell in den Produktivbetrieb geht. Das schließt Validierungsdokumentation, Legal-Opinion zum EU-AI-Act-Status und eine schriftliche Vorstandsfreigabe ein.

Konkrete Werkzeuge — was wann passt

Der Werkzeugstack hängt stark von der IT-Infrastruktur der Bank ab. Es gibt drei realistische Ansätze:

Option A: Custom Python-Stack — für Häuser mit Data-Science-Team
Python mit XGBoost, scikit-learn oder LightGBM ist der häufigste Ansatz bei Instituten, die ein eigenes Data-Science-Team aufbauen oder bereits haben. Der Vorteil: vollständige Kontrolle über Modellarchitektur, Erklärbarkeit (SHAP-Integration, Lime) und Datenhaltung. Der Nachteil: Kein Out-of-the-Box-Produkt — Daten-Engineering, Modelltraining, Alert-Workflow und Dashboards müssen selbst gebaut werden. Realistisch für Häuser ab ca. 2 Milliarden Euro Bilanzsumme mit mindestens zwei erfahrenen Data Scientists.

Databricks eignet sich als Plattform für Feature Engineering und Modelltraining in diesem Stack — besonders wenn das Kernbankensystem große Datenmengen exportiert und die Verarbeitung zuverlässig orchestriert sein muss. Kosten: ca. 0,40 USD/DBU/Stunde für Jobs-Compute.

Option B: Azure Machine Learning — für Microsoft-affine Institute
Azure Machine Learning bietet Modell-Registry, Pipeline-Orchestrierung und Deployment in einem Paket — inklusive EU-Rechenzentren, die für DSGVO-konforme Bankdaten erforderlich sind. Gut geeignet für Institute, die bereits Microsoft-Azure-Infrastruktur nutzen. Model-Governance und Audit-Trail sind integriert, was die regulatorische Dokumentation vereinfacht. Kein spezialisiertes Bankpaket, aber die generische ML-Plattform deckt alle nötigen Schritte ab.

Option C: SAS Viya Credit Risk — für Großbanken mit bestehendem SAS-Ökosystem
SAS Viya ist die etablierteste Lösung für Kreditrisiko-ML in großen Finanzinstituten. Stärke: SAS bringt vorkonfigurierte Kredit-Risikomodule mit, die explizit für regulatorische Anforderungen (IRB, IFRS 9) ausgelegt sind. Model-Governance, Audit-Trail und Explainability sind keine Nachgedanken, sondern Teil des Produkts. Schwäche: Preis im fünf- bis sechsstelligen Jahresbereich — wirtschaftlich nur für Häuser ab etwa 5 Milliarden Euro Bilanzsumme.

Externe Datendienste — für Signal-Enrichment
Unabhängig vom Analytics-Stack braucht ein gutes Frühwarnsystem externe Datensignale. Creditsafe bietet Monitoring-Alerts bei Bonitätsveränderungen für das Unternehmensportfolio — integrierbar per REST-API. Orbis (Moody’s) liefert tiefere Finanzdaten und Eigentümerstrukturen für komplexe Firmengeflechte. Für Privatkunden-Portfolios ist Schufa der Standarddatendienst.

Zusammenfassung: Wann welche Option

• Eigenes Data-Science-Team, flexible Infrastruktur, unter 5 Mrd. € Bilanzsumme → Python-Stack + Databricks
• Microsoft-Azure-Infrastruktur vorhanden → Azure Machine Learning
• SAS-Ökosystem vorhanden, Großbank → SAS Viya
• Externes Signal-Enrichment für alle drei Optionen → Creditsafe + Orbis (Moody’s)

Datenschutz und Datenhaltung

Kreditrisikodaten sind hochsensibel — sie enthalten Finanzinformationen und wirtschaftliche Verhältnisse sowohl von Unternehmen als auch von Privatpersonen. Die DSGVO-Compliance ist bei diesem Anwendungsfall besonders komplex.

Verarbeitungsgrundlage. Die Verarbeitung von Kreditnehmer-Finanzdaten im Rahmen eines Frühwarnsystems ist auf Basis des Art. 6 Abs. 1 lit. b (Vertragserfüllung) und Art. 6 Abs. 1 lit. f (berechtigtes Interesse) zulässig — die Bank hat ein berechtigtes Interesse an der Überwachung laufender Kreditrisiken. Bei natürlichen Personen ist trotzdem eine Datenschutz-Folgenabschätzung (DSFA) nach Art. 35 DSGVO empfehlenswert, da das System erheblichen Einfluss auf wirtschaftliche Entscheidungen hat.

Art. 22 DSGVO — Automatisierungsverbot. Das Frühwarnsystem darf keine vollautomatischen Entscheidungen mit rechtlicher oder wesentlicher wirtschaftlicher Wirkung auf natürliche Personen treffen. Das System warnt und priorisiert, der Relationship Manager entscheidet. Das muss im Prozessdesign und in der technischen Dokumentation explizit verankert sein.

Datenhaltung. Bankdaten müssen in der Regel auf deutschen oder zumindest EU-Servern liegen. Python-Stacks auf eigener On-Premise-Infrastruktur oder auf deutschen Cloud-Anbietern (Telekom Open Telekom Cloud, Hetzner) sind unkritisch. Azure Machine Learning bietet EU-Rechenzentren mit explizitem EU-Data-Boundary-Commitment. Bei SAS Viya: EU-Hosting für deutschen Kundenkreis verfügbar, im Vertrag explizit fixieren. Creditsafe hostet EU-seitig. Orbis (Moody’s): EU-Rechenzentren vorhanden, für DACH-Kunden im Vertrag verankern.

AVV und Drittdienstleister. Jeder externe Dienstleister, der Kreditnehmerdaten verarbeitet, muss per Auftragsverarbeitungsvertrag nach Art. 28 DSGVO eingebunden sein. Das gilt für Cloud-Plattformen (Azure Machine Learning, Databricks) und externe Datendienste (Creditsafe, Schufa-API-Zugang). Die Liste der Subdienstleister ist Teil der regulatorischen Dokumentation gegenüber BaFin.

Was es kostet — realistisch gerechnet

Die Kosten variieren erheblich je nach Ansatz und Institutsgröße. Die folgende Spanne ist für ein regionales Institut mit 1 bis 5 Milliarden Euro Bilanzsumme und 1.000 bis 5.000 aktiven Kreditengagements kalkuliert:

Einmalige Projektkosten

• Custom Python-Stack (intern + Berater): 80.000–250.000 Euro für Datenpipeline, Modellentwicklung, regulatorische Dokumentation und Go-live
• Azure Machine Learning-Lösung: 60.000–180.000 Euro (Dienstleister für Implementierung und Konfiguration)
• SAS Viya (Systemauswahl, Implementierung, Konfiguration): 150.000–400.000 Euro
• Unabhängige Modellvalidierung (extern): 15.000–40.000 Euro — verpflichtend nach MaRisk AT 4.3.5

Laufende Kosten (jährlich)

• Custom Python-Stack: 24.000–60.000 Euro (Data Scientist Aufwand für Monitoring, Retraining, Validierung + Infrastruktur)
• Azure Machine Learning: 20.000–50.000 Euro (Compute + Serviceverträge)
• SAS Viya: 80.000–200.000 Euro Lizenz + Infrastruktur
• Externe Datendienste (Creditsafe Monitoring, Orbis (Moody’s)): 15.000–50.000 Euro je nach Portfoliogröße

Was du dagegen rechnen kannst
Ein Kreditportfolio von 100 Millionen Euro mit einem Firmenkundenbestand von 600 Engagements hat statistisch 4 bis 8 Ausfälle pro Jahr. Jeder vermiedene Ausfall im Bereich von 200.000 bis 800.000 Euro spart der Bank nach Abzug von Sicherheitenverwertung netto 50.000 bis 300.000 Euro direkt — plus EWB-Aufwand, Inkassokosten und Kapitalbindungskosten.

Konservatives Szenario: Das System verhindert 1 bis 2 Ausfälle pro Jahr durch frühzeitige Intervention. Netto-Einsparung: 80.000 bis 250.000 Euro. Amortisationszeit eines Custom-Stacks: typisch 12 bis 24 Monate ab Go-live.

Wie du den ROI wirklich misst
Die ehrlichste Methode ist der Kohortenvergleich: Verfolge alle Engagements, die ein Alert-Signal bekommen haben, über 18 Monate nach. Wie viele haben sich stabilisiert? Wie viele sind trotzdem ausgefallen? Vergleiche die Ausfallrate mit einer Kontrollgruppe (nicht gealertete Engagements mit ähnlichem Risikoprofil). Erst das ergibt eine belastbare Zahl — nicht die theoretische Kalkulation.

Modell-Drift: Die unterschätzte Gefahr

Der gefährlichste Fehler bei KI-basierten Kreditrisikomodellen ist kein technischer — es ist der Glaube, dass ein einmal trainiertes Modell dauerhaft funktioniert.

Was Modell-Drift bedeutet. Das Modell wurde auf historischen Kreditdaten trainiert, die eine bestimmte wirtschaftliche Epoche widerspiegeln. Wenn sich die wirtschaftlichen Bedingungen grundlegend ändern — Zinsumfeld, Branchenstrukturen, Zahlungsverhalten nach Krisen — verschiebt sich die Datenverteilung der Eingabevariablen. Das Modell gibt weiterhin Scores aus, aber sie spiegeln die neue Realität nicht mehr wider.

Der COVID-Kreditmodell-Kollaps — dokumentiertes Warnsignal. McKinsey und Risk.net dokumentierten 2020, dass nahezu alle etablierten Kreditrisikomodelle europäischer und amerikanischer Banken innerhalb weniger Wochen nach Beginn der COVID-19-Pandemie ihren Vorhersagewert verloren. Der Grund: Staatliche Hilfsprogramme (Kurzarbeitergeld, Stundungsregelungen, KfW-Kredite) veränderten das Zahlungsverhalten radikal — auf eine Art, die kein historisches Modell gelernt hatte. Frühindikatoren, die vor COVID verlässlich funktionierten, gaben irreführende Signale. Early-Warning-Systeme zeigten entweder massenhaft falsche Alarme oder keinen Alarm, obwohl das Risiko real gestiegen war.

Konkrete Drift-Mechanismen, die du im Prozess managen musst:

• Datendrift: Eingabevariablen wie Kontoüberziehungsrate oder Zahlungseingangsmuster verschieben sich saisonal oder strukturell
• Konzeptdrift: Der Zusammenhang zwischen einem Signal und dem späteren Ausfall ändert sich (z. B. Kurzarbeit als positives Signal vor COVID, als neutrales danach)
• Selektionsbias: Wenn die Bank durch das Frühwarnsystem frühzeitig interveniert und Ausfälle verhindert, fehlen dem Modell beim nächsten Retraining die Ausfallbeispiele — es trainiert auf einem verzerrten Datensatz

Was du dagegen tun musst:
Plane regelmäßige Modell-Performance-Reviews als festes Element der Governance ein — mindestens halbjährlich, nach Marktturbulenzen auch quartalsweise. Definiere klare Grenzen: Wenn der Gini-Koeffizient des Modells um mehr als X Prozentpunkte fällt, wird automatisch ein Retraining ausgelöst. BaFin-konform: Diese Schwellenwerte und Reaktionsprozesse müssen schriftlich dokumentiert sein, bevor das Modell in den Produktivbetrieb geht.

Drei typische Einstiegsfehler

1. Das Projekt als IT-Projekt starten, nicht als Kreditrisikoprojekt.
Der häufigste Fehler: IT und Data Science bauen ein technisch funktionierendes System, das am Kreditrisikomanagement vorbeientwickelt wurde. Die Relationship Manager werden erst am Ende einbezogen, die Alert-Logik spiegelt nicht die operative Praxis wider, und die Checklisten für das Kundengespräch fehlen. Ergebnis: Das System läuft, aber niemand nutzt es. Regel: Kredit-Fachpersonal muss von Tag 1 im Projekt sitzen, nicht erst bei der Abnahme.

2. Mit allen verfügbaren Daten starten.
Der Reflex: Mehr Features = besseres Modell. In der Praxis führt das zu Überanpassung, Erklärungsproblemen und regulatorischem Aufwand für jeden einbezogenen Datenpunkt. Starte mit den 8 bis 12 Features mit dem stärksten empirischen Signal: Kontoüberziehungsfrequenz, Umsatzrückgang im Vergleich zum Vorjahresquartal, Anzahl der Rücklastschriften, Branchenindex, Eigenkapitalquote aus dem letzten Jahresabschluss, Veränderung des Kreditnutzungsgrades. Ein einfaches, erklärbares Modell mit wenigen Features übertrifft ein komplexes Blackbox-Modell in jedem regulatorischen Gespräch — und meistens auch in der Praxis.

3. Das System als fertig betrachten, sobald es live ist.
Kreditrisikomodelle sind kein Software-Produkt, das einmal deployed und dann vergessen wird. Ohne aktive Pflege degradieren sie. Das ist keine Eventualität — es ist eine Gewissheit. Was das konkret bedeutet: Eine Person im Haus muss die Modell-Performance monatlich messen, Retraining-Entscheidungen treffen und die Dokumentation aktuell halten. Wenn diese Ressource nicht eingeplant ist, bevor das System go-live geht, wird es nach 18 Monaten still und leise falsch.

Was mit der Einführung wirklich passiert — und was nicht

Die technische Implementierung ist selten der Engpass. Der Engpass ist meistens das Vertrauen der Kreditbetreuer ins System.

Der „zu viele Alarme”-Effekt. In den ersten drei Monaten nach Go-live erzeugt ein frisch kalibriertes Modell typischerweise 30 bis 50 Prozent mehr Alerts, als sich als berechtigt herausstellen. Das ist normal — das Modell ist konservativ eingestellt, und nicht jedes Alert-Signal führt tatsächlich zu einem kritischen Kreditfall. Was passiert in der Praxis: Relationship Manager beginnen, Alerts zu ignorieren oder mechanisch abzuhaken, ohne echte Analyse. Das System verliert seine Funktion. Lösung: In den ersten 3 bis 6 Monaten bewusst eng begleiten — jede Alert-Entscheidung wird im Team kurz besprochen, um gemeinsam die Schwellenwerte zu kalibrieren.

Die Machtverschiebungs-Debatte. Erfahrene Kreditbetreuer mit 15-jähriger Portfolioerfahrung haben oft ein exzellentes intuitives Gespür für Risikoengagements. Ein System, das ihnen täglich eine Liste mit „euren Problemfällen” auf den Schreibtisch legt, kann sich wie eine Kontrollinstanz anfühlen — nicht wie ein Hilfsmittel. Das ist eine reale Akzeptanzbarriere. Was hilft: Das System in der internen Kommunikation nie als Kontrollmechanismus darstellen, sondern als Prioritätshilfe. Der Betreuer entscheidet, ob der Alert relevant ist — der Algorithmus priorisiert nur die Suche.

Das Datenproblem kommt nach Go-live zum Vorschein.
In vielen deutschen Regionalbanken liegen Kreditakten-Daten über mehrere Systeme verteilt: Kernbankensystem, Excel-Sheets, gescannte PDFs. Erst wenn das Modell täglich Daten ziehen soll, wird klar, wie fragmentiert die Datenbasis wirklich ist. Plane 2 bis 3 Monate für Datenpipeline-Stabilisierung nach dem ersten Produktiveinsatz ein.

Was konkret hilft:

• Pilotstart mit einem Teilportfolio (100–200 Engagements) statt sofort dem gesamten Bestand
• Relationship Manager in die Alert-Kalibrierung einbeziehen: Welche Alerts waren berechtigt? Welche nicht? Diese Rückmeldung verbessert das Modell direkt
• Monatlicher kurzer Status-Report (1 Seite): Wie viele Alerts? Wie viele Interventionen? Wie viele haben sich stabilisiert? Das schafft Sichtbarkeit und Vertrauen im Haus

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

„Unsere Relationship Manager kennen ihre Kunden besser als jeder Algorithmus.”
Das stimmt für viele Fälle — und ist trotzdem kein Gegenargument. Ein Relationship Manager mit 400 Engagements kann nicht alle 400 täglich im Kopf haben. Das System schlägt nicht vor, wer der Kunde wirklich ist — es signalisiert, bei welchen 5 Engagements heute ein Anruf sinnvoll wäre. Es ersetzt das Urteil des Betreuers nicht, es optimiert seine Aufmerksamkeit.

„Die regulatorischen Anforderungen sind zu aufwendig.”
Das ist ein berechtigter Einwand — besonders für kleine Institute. MaRisk AT 4.3.5 und die EBA-ML-Anforderungen bedeuten realen Aufwand. Für Häuser unter 500 Millionen Euro Bilanzsumme kann der Compliance-Aufwand die Kosteneinsparung tatsächlich überwiegen. Der Ausweg: statt eines vollständigen ML-Systems ein regelbasiertes Frühwarnsystem einführen, das die gleichen Datenquellen nutzt, aber mit transparenten Schwellenwerten arbeitet. Das ist MaRisk-konform ohne ML-Validierungsaufwand — weniger präzise, aber deutlich einfacher.

„Wir haben die Daten nicht, um ein gutes Modell zu trainieren.”
Das ist der ehrlichste Einwand und meistens der zutreffendste. Für ein belastbares ML-Modell brauchst du mindestens 3 bis 5 Jahre historische Kreditdaten mit ausreichend Ausfallereignissen — in digitaler, strukturierter Form. Wenn das nicht vorhanden ist, ist ein Custom-ML-Ansatz tatsächlich nicht der richtige erste Schritt. Dann ist das sinnvollere Vorgehen: Datenbasis aufbauen und für den nächsten Zyklus vorbereiten, während ein regelbasiertes System die Zwischenzeit überbrückt.

Woran du merkst, dass das zu dir passt

• Dein Institut hat ein aktives Firmenkundenportfolio von mindestens 300 bis 400 laufenden Engagements — darunter lohnt das System kaum
• Das Kreditrisikomanagement-Team verbringt mehr als 20 Prozent seiner Zeit mit manueller Portfolioüberwachung statt mit Kundenarbeit
• Ihr hattet in den letzten 3 Jahren mindestens 2–3 Ausfälle, bei denen im Nachhinein klar war, dass Frühsignale vorhanden waren — ihr habt sie nur nicht rechtzeitig gesehen
• Eure Kreditdaten liegen digital und strukturiert vor — mindestens Kontoverkehrsdaten und Jahresabschlüsse in maschinenlesbarer Form für 5+ Jahre
• Es gibt eine Person oder ein kleines Team, das die Modell-Governance dauerhaft übernehmen kann — kein regulatorisch anspruchsvolles Kreditrisikomodell funktioniert ohne klaren Owner

Wann es sich (noch) nicht lohnt — drei harte Ausschlusskriterien:

1. Unter ~500 Millionen Euro Bilanzsumme oder weniger als 300 aktiven Kreditengagements. Der Setup- und Validierungsaufwand nach MaRisk übersteigt den realistischen Nutzen. Ein regelbasiertes Frühwarnsystem mit definierten Schwellenwerten (Überziehungsfrequenz, Ratingverschlechterung um mehr als X Stufen) liefert 70 Prozent des Nutzens bei einem Bruchteil des Aufwands.

2. Kreditdaten nicht in strukturierter, digitaler Form vorhanden — oder weniger als 5 Jahre historische Datenbasis. Ohne ausreichend Ausfallbeispiele im Trainingsdatensatz lernt das Modell nichts Zuverlässiges. Das ist keine Frage des guten Willens, sondern eine harte Mindestanforderung für ML-basierte Kreditrisikomodelle. Wenn die Datenbasis nicht stimmt: erst Daten aufbauen, dann Modell.

3. Keine Kapazität für laufende Modell-Governance. Ein KI-basiertes Kreditrisikomodell, das eingeführt und dann 18 Monate sich selbst überlassen wird, ist nicht nur nutzlos — es ist gefährlich. Es gibt weiterhin Scores aus, die auf einer Realität basieren, die es nicht mehr gibt. Wer die personelle Ressource für monatliches Performance-Monitoring, jährliche Retrainings und die regulatorische Dokumentationspflicht nicht einplanen kann, sollte nicht starten.

Das kannst du heute noch tun

Der erste Schritt kostet kein Geld und kein regulatorisches Verfahren: Analysiere euer eigenes historisches Portfolio. Nimm die letzten 30 Kreditausfälle oder Rating-Verschlechterungen und schaue dir an, was die Kontoverkehrsdaten 6, 9 und 12 Monate vorher gezeigt haben. Das ist ein Projekt für 2 bis 3 Werktage mit verfügbaren Daten — und gibt dir ein reales Bild davon, ob die Frühsignale in eurem Portfolio stark genug sind, um ein Modell zu rechtfertigen.

Für den ersten strukturierten Überblick kannst du ein LLM wie Claude oder GPT-4 nutzen, um ein Analyse-Framework aufzusetzen:

Quellen & Methodik

• ECB Supervisory Newsletter, August 2025 — „Die Funken löschen bevor es brennt: Krisen im Kreditgeschäft gut in den Griff bekommen.” Europäische Zentralbank, Bankenaufsicht. SME-NPL-Quote 4,78 % per Q1 2025; Stage-2-Anstieg; Empfehlungen für Frühwarnsysteme. bankingsupervision.europa.eu

• EBA Follow-up Report on Machine Learning for IRB Models, 2023 — EBA/REP/2023/28. Europäische Bankenaufsichtsbehörde. Explainability-Anforderungen für ML im Kreditrisiko, Validierungsanforderungen bei begrenzter Interpretierbarkeit. eba.europa.eu

• BaFin Rundschreiben 06/2024 (BA) — MaRisk, 8. Novelle, Mai 2024. Mindestanforderungen an das Risikomanagement, Modul AT 4.3.5: KI-Modelle in Banken. Anforderungen an Explainability, Validierung und Dokumentation. bafin.de

• McKinsey, „Banking models after COVID-19: Taking model-risk management to the next level” (2020). Dokumentation des COVID-induzierten Modell-Kollapses bei Kreditrisikomodellen europäischer und amerikanischer Banken. Belegt Konzeptdrift und distributive Verschiebungen durch Staatshilfen. McKinsey.com

• Springer Proceedings 2024: „Loan Default Prediction Modelling to Reduce NPL: Bank XYZ Case Study.” XGBoost-basiertes ML-Modell reduzierte NPL von 5,25 % auf 3,63 %, unterhalb der regulatorischen Schwelle von 5 % (Indonesien). springer.com

• NPL-Volumen-Prognose Deutschland bis 60 Milliarden Euro: Handelsblatt, „Deutsche Banken: Die Angst vor notleidenden Krediten wächst” (2024). handelsblatt.com

• DSGVO Art. 22 und automatisierte Kreditentscheidungen: Datenschutz-Grundverordnung (EU) 2016/679, Art. 22. EuGH-Urteil C-634/21 (SCHUFA vs. OLG Wiesbaden, Dezember 2023) zur Reichweite automatisierter Entscheidungsverbote bei Credit-Scoring-Systemen.

• Implementierungskosten und Zeitplanerfahrungen: Eigene Erfahrungswerte aus Kreditrisikoprojekten bei deutschen Regionalbanken (2022–2025). Nicht repräsentativ, aber konsistent über mehrere Implementierungen.

Du willst wissen, ob euer Kreditportfolio die Datengrundlage für ein belastbares Frühwarnsystem hat — oder ob zunächst ein regelbasierter Ansatz sinnvoller ist? Meld dich für ein kurzes Gespräch.