+150 XP

Banken · Model Risk erkennen, bevor daraus ein Loss Event wird

Eine mittelgroße US-Bank betrieb ein Collections-Modell, das acht Monate lang unbemerkt nicht mehr funktionierte. Zunächst fiel es niemandem auf. Das Modell scorte weiter überfällige Konten und sortierte sie für die Ansprache, aber die Welt darunter hatte sich verändert: eine Verschiebung im Kundenmix nach einer Portfolioübernahme, ein neues Hardship-Programm, eine Änderung darin, wie Callcenter-Agents Ergebnisse dokumentierten. Die Prognosen des Modells entfernten sich von der Realität, die Collectors verfolgten die falschen Konten, die Recovery Rates sanken, und als jemand endlich den Model Output mit den tatsächlichen Roll Rates abglich, hatte die Bank einen messbaren, vermeidbaren Verlust verbucht. Ein Lehrbuchfall für realisiertes Model Risk, nicht weil das Modell schlecht gebaut war, sondern weil nach dem Launch niemand hingeschaut hat.

In dieser Lektion geht es darum, diesen Drift zu erkennen, bevor er in Ihren Zahlen oder im Brief eines Prüfers auftaucht.

Was „Model Risk" tatsächlich bedeutet

Model Risk ist das Risiko finanzieller Verluste oder falscher Entscheidungen, verursacht durch ein Modell, das falsch ist, falsch eingesetzt wird oder schlecht verstanden ist. In den USA ist der Referenzrahmen die SR 11-7 Guidance on Model Risk Management der Federal Reserve und des OCC (2011), auch 2026 noch der operative Standard für Banken. Sie definiert Model Risk als aus zwei Quellen entstehend:

  • Fundamentale Fehler: Das Modell ist konzeptionell falsch oder auf schlechten Daten aufgebaut.
  • Misuse: Das Modell wird außerhalb der Bedingungen eingesetzt, für die es validiert wurde.

Silent Drift, wie im Collections-Fall, ist meist das Zweite. Das Modell war beim Launch nicht falsch. Es wurde falsch, als sich sein Umfeld änderte und niemand die Passung erneut prüfte.

In Europa liegen die entsprechenden Erwartungen im EZB-Leitfaden zu internen Modellen und, breiter gefasst, im EU AI Act (in Kraft seit 2024, gestaffelte Pflichten bis 2026-2027), der KI-Systeme zur Kreditwürdigkeitsprüfung und zum Credit Scoring als „hochriskant" einstuft und damit verpflichtende Anforderungen an Risikomanagement, Data Governance und menschliche Aufsicht auslöst.

Die drei Risikofamilien, die Sie beobachten sollten

1. Data Drift. Die statistischen Eigenschaften der eingehenden Daten ändern sich. Beispiel: Eine Bank übernimmt das Kreditbuch eines Fintechs; die neuen Kreditnehmer haben dünnere Kreditakten, das Modell sieht also Inputs, auf denen es nie trainiert wurde.

2. Concept Drift. Die Beziehung zwischen Inputs und Ergebnissen ändert sich, selbst wenn die Input-Daten stabil aussehen. Beispiel: Ein Hardship-Programm startet, also erholen sich Kreditnehmer, die nach der alten Logik des Modells „high risk" aussehen, nun schneller, weil sie Zahlungserleichterungen erhalten haben. Gleiche Inputs, anderes Ergebnis.

3. Feedback-Loop-Risiko. Die Entscheidungen des Modells verändern künftige Daten. Beispiel: Ein Collections-Modell priorisiert bestimmte Konten herunter, diese Konten erhalten weniger Aufmerksamkeit, sie entwickeln sich schlechter, und das Modell „lernt", dass sie von Anfang an high risk waren, was ein selbsterfüllendes Muster verstärkt. Besonders gefährlich in Underwriting- und Collections-Modellen, die beeinflussen, wer kontaktiert, genehmigt oder mit Erleichterungen bedacht wird.

Leading Indicators: Was Sie überwachen sollten, bevor Verluste auftauchen

Die achtmonatige Lücke im obigen Fall entstand, weil die Bank *Ergebnisse* überwachte (Charge-offs, Recovery Rates), aber nicht das *Modellverhalten*. Ergebnisse laufen Monate nach. Verhaltenssignale bewegen sich schneller. Verfolgen Sie diese:

  • Population Stability Index (PSI): misst, wie stark sich die Verteilung der Modell-Inputs (oder Scores) gegenüber der Trainings-Baseline verschoben hat. Ein PSI über etwa 0,25 ist eine branchenübliche Schwelle für „signifikante Verschiebung" (Schätzung, variiert je nach institutseigener Policy).
  • Verschiebung der Score-Verteilung: Landen plötzlich mehr Konten als üblich im obersten oder untersten Dezil?
  • Override Rate: Wie oft überstimmen menschliche Agents das Modell? Eine steigende Override Rate ist ein Frühindikator dafür, dass die Mitarbeiter ihm nicht mehr vertrauen.
  • Champion-Challenger-Abstand: Betreiben Sie ein einfacheres Benchmark-Modell parallel; wenn der Abstand zum Produktionsmodell größer wird, hat sich etwas verändert.
  • Vollständigkeit der Input-Daten: fehlende Felder, Null-Raten oder neue kategoriale Werte (etwa ein neuer Produktcode für Kredite), die sich in den Feed einschleichen.

Ein einfacher Drift-Check, durchgerechnet

PSI vergleicht den Prozentanteil der Konten in jedem Score-Bucket heute gegenüber dem Zeitpunkt des Trainings.

PSI = Σ (Actual% - Expected%) × ln(Actual% / Expected%)

Angenommen, der Score-Bucket „low risk" enthielt beim Modelltraining 40 % der Konten und enthält jetzt 25 %:

Bucket contribution = (0.25 - 0.40) × ln(0.25 / 0.40)
                     = (-0.15) × ln(0.625)
                     = (-0.15) × (-0.47)
                     = 0.0705

Summieren Sie das über alle Buckets. Überschreitet die Summe die Schwelle Ihres Instituts (üblicherweise 0,1 für „watch" und 0,25 für „act", als Schätzwerte), ist das ein Auslöser für eine Überprüfung, unabhängig davon, ob schon Verluste aufgetreten sind.

python
import numpy as np

def psi(expected, actual):
    return np.sum((actual - expected) * np.log(actual / expected))

expected = np.array([0.40, 0.35, 0.25])  # Trainingsverteilung
actual   = np.array([0.25, 0.40, 0.35])  # aktuelle Verteilung
print(round(psi(expected, actual), 3))

Governance-Leitplanken vor dem Deployment

Model Risk Management (MRM) nach SR 11-7 ruht auf drei Säulen, und jede lässt sich auf einen konkreten Check vor dem Deployment abbilden:

  1. Entwicklung und Dokumentation: Gibt es eine Model Card oder eine vergleichbare Aufzeichnung zu Verwendungszweck, Datenquellen und bekannten Grenzen? Hätte die Dokumentation des Collections-Modells vermerkt „nicht validiert für Populationen in Hardship-Programmen", wäre der Drift am Tag des Programmstarts aufgefallen.
  1. Unabhängige Validierung: Ein von den Modellentwicklern getrenntes Team muss das Modell vor und periodisch nach dem Launch testen. Nach den aufsichtlichen Erwartungen für US-Banken ist das nicht optional, und unter dem EU AI Act erfordern Hochrisikosysteme dokumentierte Konformitätsbewertungen vor dem Inverkehrbringen.
  1. Laufendes Monitoring: Vorab vereinbarte Trigger (wie die PSI-Schwellen oben), die eine Überprüfung erzwingen, nicht nur einen jährlichen Check-in. Die Monitoring-Frequenz sollte dazu passen, wie schnell sich die zugrunde liegende Population ändern kann: monatlich oder sogar wöchentlich für Collections- und Fraud-Modelle, quartalsweise für träger laufende Modelle wie langfristige Kreditrisiko-Ratings.

Eine praktische Checkliste vor dem Launch:

  • Definierter Verwendungszweck und explizite „out of scope"-Bedingungen
  • Baseline-Datenverteilung erfasst und gespeichert für künftige PSI-Vergleiche
  • Champion-Challenger-Modell läuft parallel
  • Override- und Eskalationsprozess für Frontline-Mitarbeiter dokumentiert
  • Namentlich benannter Model Owner, verantwortlich für das Monitoring nach dem Launch (nicht nur das Build-Team)

Wissenscheck

1. Was war im Fall des Collections-Modells die grundlegende Ursache des Loss Events?

2. Wie lässt sich im SR-11-7-Rahmen „Misuse" als Quelle von Model Risk am besten von einem „fundamentalen Fehler" unterscheiden?

3. Ein Kreditrisikomodell einer Bank hat bei der Validierung vor zwei Jahren gut abgeschnitten. Seitdem hat die Bank ein neues Kreditportfolio mit anderen Kreditnehmermerkmalen übernommen, das Modell wurde aber nicht neu validiert. Was veranschaulicht dieses Szenario vor allem?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE richtigen Antworten dazu, warum das Versagen des Collections-Modells acht Monate lang unentdeckt blieb.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE richtigen Antworten zu wirksamen Praktiken, um Model Risk zu erkennen, bevor es zu einem Loss Event führt.

Wählen Sie alle richtigen Antworten aus.

Warum das immer wieder passiert

Banken sind gut darin, Modelle vor dem Launch zu validieren, und vergleichsweise schwach darin, sie danach zu beobachten. Ein Fed-Outlook von 2023 und Branchenumfragen (siehe die Supervisory Guidance Library der Fed) nennen immer wieder „unzureichendes laufendes Monitoring" als die häufigste MRM-Lücke, die Prüfer finden. Das Muster ist strukturell: Entwicklungsbudgets sind sichtbar und finanziert, Monitoring-Budgets nicht.

Der Collections-Fall spiegelt genau das. Das Modell hat die Validierung bestanden. Danach hat es niemand verantwortet. Die Bank erfuhr davon über ein quartalsweises Loss Review, das langsamstmögliche Signal, statt über ein wöchentliches PSI-Dashboard, das schnellste.

🎬 [VIDEO: "Model Risk Management Explained" - https://www.youtube.com/results?search_query=model+risk+management+explained+banking - ein Durchgang durch Model-Risk-Governance-Konzepte im Stil von SR 11-7 für Praktiker im Bankwesen]

Key Takeaways

  • Model Risk ist nicht nur „das Modell war falsch gebaut". Die meisten echten Verluste entstehen durch Misuse oder Drift nach dem Launch, wenn sich die Welt ändert, das Modell aber nicht.
  • Beobachten Sie Verhalten, nicht nur Ergebnisse. PSI, Override Rates und Champion-Challenger-Abstände bewegen sich Monate früher als Charge-offs oder Recoveries den Schaden zeigen.
  • Governance-Frameworks existieren und sind konkret: SR 11-7 in den USA, die Hochrisiko-Einstufung für Credit Scoring im EU AI Act in Europa. Nutzen Sie ihre drei Säulen (Entwicklung, Validierung, Monitoring) als Ihre Checkliste.
  • Jedes produktive Modell braucht einen namentlich benannten Owner und eine vorab vereinbarte Monitoring-Frequenz, passend dazu, wie schnell sich seine Population verschieben kann: wöchentlich für Collections und Fraud, langsamer für strukturelle Kreditrisikomodelle.
  • Die Dokumentation von Verwendungszweck und „out of scope"-Bedingungen ist Ihre günstigste Versicherung. Sie macht aus einem stillen Fehler einen offensichtlichen, sobald sich die Bedingungen ändern.

Verwandte Artikel

Aktuelle Blogartikel, die auf dieser Lektion aufbauen.