+150 XP

Risikomodelle unter regulatorischer Aufsicht steuern

# Risikomodelle unter regulatorischer Aufsicht steuern

Ein Prüfer schiebt eine einzige Frage über den Tisch: „Zeigen Sie mir, woher diese Variable kommt.“ Das neue Credit-Scoring-Modell der Bank ist bereit für den Start. Das Data-Science-Team ist zuversichtlich. Aber wenn niemand einen einzigen Input bis zum Quellsystem zurückverfolgen kann, geht das Modell nicht live. So sieht die Steuerung von Risikomodellen in einer regulierten Bank aus.

Diese Lektion setzt Sie in genau diesen Validierungsreview. Sie lernen die Regeln, die Prüfer anwenden, die Kontrollen, die sie verlangen, und warum Data Lineage der Punkt ist, an dem die meisten Modelle scheitern.

Warum Banken Modelle überhaupt governen

Ein Modell im Bankwesen ist jede quantitative Methode, die Input-Daten in eine Entscheidung oder Schätzung verwandelt. Ein Credit-Scoring-Modell prognostiziert Ausfallrisiko. Ein Anti-Money-Laundering-Modell (AML) markiert verdächtige Transaktionen. Ein Stresstest-Modell schätzt Verluste in einer Rezession.

Wenn ein Modell falsch ist, sind echtes Geld und echte Menschen betroffen. Ein verzerrtes Scoring-Modell kann Kredite unfair ablehnen. Ein schwaches AML-Modell kann kriminelle Aktivitäten übersehen. Regulierer nennen diese Exposition Modellrisiko: das Verlustrisiko aus Entscheidungen, die auf fehlerhaften oder falsch eingesetzten Modellen basieren.

Das zentrale US-Regelwerk ist SR 11-7, eine Guidance, die die Federal Reserve und das Office of the Comptroller of the Currency (OCC) 2011 gemeinsam veröffentlicht haben. Sie bleibt 2026 der Referenzstandard. Die Primärquelle finden Sie hier: SR 11-7 Guidance on Model Risk Management.

Die drei Säulen von SR 11-7

SR 11-7 ist kurz, aber fordernd. Es ruht auf drei Ideen.

1. Effective Challenge

Jemand, der von den Modellentwicklern unabhängig ist, muss das Modell kritisch prüfen. Das nennt man Effective Challenge. Der Prüfer braucht die Kompetenz, die Mathematik zu verstehen, den Einfluss, Änderungen durchzusetzen, und die Unabhängigkeit, Nein zu sagen.

In der Praxis richtet eine Bank eine Model-Risk-Management-Funktion (MRM) ein, getrennt vom Data-Science-Team. Die Entwickler bauen. MRM challenged.

2. Validierung über den gesamten Lifecycle

Validierung ist kein einmaliges Gate. SR 11-7 verlangt Prüfung in der Entwicklung, vor dem Deployment und laufend. Ein Scoring-Modell, das 2024 funktionierte, kann sich verschlechtern, wenn sich Kundenverhalten verschiebt. Dieser Verfall heißt Model Drift, und das Monitoring darauf ist Pflicht.

3. Governance, Policy und Kontrollen

Vorstand und Senior Management tragen die Verantwortung für Modellrisiko. Es muss ein Model Inventory geben (ein vollständiges Register jedes im Einsatz befindlichen Modells), dokumentierte Policies und klare Rollen. Ein Prüfer wird zuerst nach dem Inventory fragen. Ein fehlendes Modell ist für sich schon ein Governance-Versagen.

Im Validierungsreview

Stellen Sie sich den Raum vor. Anwesend sind der Modellentwickler, ein MRM-Validator, ein Data-Governance-Lead und oft ein Compliance Officer. Sie arbeiten eine Checkliste durch.

Konzeptionelle Solidität. Ergibt das Modell Sinn? Wenn ein Kreditmodell die Postleitzahl als Variable nutzt, wird jemand fragen, ob das ein Proxy für Ethnie ist, was Fair-Lending-Bedenken aufwerfen würde.

Datenqualität. Sind die Trainingsdaten korrekt, vollständig und repräsentativ? Ein Modell, das nur auf genehmigten Kreditnehmern trainiert wurde, leidet unter Survivorship Bias: Es hat nie gesehen, wie sich abgelehnte Antragsteller entwickelt hätten.

Outcomes-Analyse. Prognostiziert das Modell tatsächlich, was es behauptet? Validatoren backtesten Prognosen gegen reale Ergebnisse.

Implementierungstests. Entspricht der deployte Code dem genehmigten Modell? Eine Formel, die im Notebook funktioniert, kann in der Produktion brechen.

Data Lineage: die Kontrolle, an der alles hängt

Zurück zur Frage des Prüfers: „Zeigen Sie mir, woher diese Variable kommt.“

Data Lineage ist der dokumentierte Weg eines Datenelements von seinem Ursprung über jede Transformation bis zu seiner Verwendung im Modell. Betrachten Sie es als Belegnachweis für jede Zahl.

Warum Prüfer darauf fixiert sind:

  • Wenn Sie eine Variable nicht zurückverfolgen können, können Sie ihre Korrektheit nicht belegen.
  • Sie können nicht bestätigen, dass Sie sie verwenden dürfen.
  • Sie können das Modell nicht reproduzieren, was die Auditierbarkeit bricht.

Ein konkretes Beispiel. Ein Feature „Debt-to-Income Ratio“ sieht einfach aus. Aber das Einkommen kommt vielleicht aus einem System, die Verschuldung aus einem anderen, und die Ratio wird in einem dritten berechnet, mit Rundungsregeln, die von der Quelle abweichen. Jeder Hop ist eine Stelle, an der Fehler und Regeländerungen sich verstecken.

Moderne Banken tracken Lineage mit Metadaten-Tools und Versionskontrolle. So sieht in etwa aus, was ein Lineage-Record erfasst:

yaml
feature: debt_to_income_ratio
source_income: core_banking.customer_income   # monatlich verifiziert
source_debt: credit_bureau.total_obligations  # beim Abruf aktualisiert
transformation: debt / income
null_handling: exclude_if_income_missing
owner: retail_credit_risk
consent_basis: loan_application_terms
last_validated: 2026-01-15

Beachten Sie die Zeile consent_basis. Hier treffen Lineage und Datenschutz aufeinander.

Datenschutzregeln, die die Daten einschränken

Ein Modell darf nur Daten nutzen, die die Bank für diesen Zweck rechtlich nutzen darf.

In den USA regelt der Fair Credit Reporting Act (FCRA), wie Kreditdaten verwendet werden, und verlangt, dass Verbraucher erfahren können, warum sie abgelehnt wurden. Deshalb müssen Kreditgeber Adverse Action Reasons liefern: konkrete Faktoren hinter einer Ablehnung. Ein Modell, das seine wichtigsten Gründe nicht erklären kann, verstößt gegen das Gesetz, egal wie genau es ist.

Fair-Lending-Gesetze (der Equal Credit Opportunity Act) verbieten Diskriminierung aufgrund geschützter Merkmale. Selbst wenn ein Modell Ethnie nie sieht, kann eine korrelierte Variable Disparate Impact erzeugen, ein Ergebnis, das eine geschützte Gruppe benachteiligt. Validatoren führen Fairness-Tests durch, um das aufzudecken.

In der EU und UK ergänzt die Datenschutz-Grundverordnung (DSGVO) die Zweckbindung (für einen Zweck erhobene Daten dürfen nicht frei weiterverwendet werden), das Recht auf Erklärung bei automatisierten Entscheidungen und strenge Consent-Regeln.

Die praktische Konsequenz: Datenschutz ist kein juristischer Nachgedanke, der am Ende angeschraubt wird. Er ist eine Design-Restriktion, die bestimmt, welche Features ein Modell überhaupt enthalten darf.

🎬 [VIDEO: "Model Risk Management Explained" - youtube.com - ein klarer Überblick über die SR-11-7-Prinzipien und wie Banken Modelle vor dem Deployment validieren]

Explainability und das Black-Box-Problem

Prüfer sind bei komplexen Machine-Learning-Modellen vorsichtig, weil diese schwer zu interpretieren sein können. Eine einfache logistische Regression (ein statistisches Modell, das jeden Input gewichtet) zeigt genau, wie jede Variable den Score beeinflusst. Ein Deep Neural Network möglicherweise nicht.

Das verbietet komplexe Modelle nicht. Es hebt die Dokumentationshürde. Banken nutzen Werkzeuge wie SHAP Values (eine Methode, die eine Prognose auf die einzelnen Inputs zurechnet), um einzelne Entscheidungen zu erklären. Wird ein Kunde abgelehnt, muss die Bank dennoch ehrliche Adverse Action Reasons erzeugen.

Die Daumenregel im Raum: Was Sie nicht erklären können, können Sie in einer regulierten Entscheidung nicht deployen.

Wissenscheck

1. Was definiert „Modellrisiko“ im Kontext von SR 11-7 am besten?

2. Warum verlangt „Effective Challenge“, dass der Prüfer neben Kompetenz auch Unabhängigkeit hat?

3. Eine Bank trennt ihre Model-Risk-Management-Funktion (MRM) vom Data-Science-Team. Was ist der Hauptzweck dieser organisatorischen Trennung?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE richtigen Antworten. Was davon gilt als „Modell“ nach der in der Lektion gegebenen Bankdefinition?

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE richtigen Antworten. Warum wird Data Lineage als der Punkt beschrieben, an dem die meisten Modelle die Validierung nicht bestehen?

Wählen Sie alle richtigen Antworten aus.

Laufendes Monitoring nach dem Launch

Die Genehmigung ist nicht die Ziellinie. Sobald ein Modell live ist, richtet MRM kontinuierliches Monitoring ein.

Performance-Monitoring beobachtet die Genauigkeit über die Zeit. Wenn die Qualität der Ausfallprognose nachlässt, muss das Modell möglicherweise rekalibriert werden.

Population Stability prüft, ob die eingehenden Antragsteller noch der Trainingspopulation entsprechen. Eine gängige Metrik ist der Population Stability Index (PSI), der anzeigt, wann sich die Input-Verteilung so weit verschoben hat, dass es kritisch wird.

Override-Tracking erfasst, wie oft Menschen das Modell überstimmen. Häufige Overrides deuten darauf hin, dass dem Modell nicht vertraut wird oder es für den Zweck nicht geeignet ist.

Wenn ein Modell seine Schwellenwerte reißt, gibt die Governance-Policy die Eskalation vor: rekalibrieren, revalidieren oder stilllegen.

Was Prüfer tatsächlich sehen wollen

Auf den Punkt gebracht muss eine Bank nachweisen:

  • Ein vollständiges Model Inventory mit Ownern.
  • Unabhängige Validierung mit echter Effective Challenge.
  • End-to-End Data Lineage für jeden Modell-Input.
  • Dokumentierte Compliance mit Datenschutz und Fair Lending.
  • Explainability, die ausreicht, um jede Entscheidung zu begründen.
  • Laufendes Monitoring mit definierten Eskalationsauslösern.

Fehlt eines, wartet das Deployment. Deshalb konnte das Data-Science-Team aus unserer Eingangsszene nicht allein auf Zuversicht hin launchen.

Key Takeaways

  • Modellrisiko wird gesteuert, nicht unterstellt. SR 11-7 verlangt unabhängige Effective Challenge, Validierung über den Lifecycle und Verantwortung auf Vorstandsebene über ein Model Inventory.
  • Data Lineage ist die Kontrolle, die zuerst versagt. Wenn Sie eine Variable nicht zur Quelle zurückverfolgen und belegen können, wie sie transformiert wurde, geht das Modell nicht live.
  • Datenschutz ist eine Design-Restriktion. FCRA, Fair-Lending-Regeln und DSGVO begrenzen, welche Daten ein Modell nutzen darf, und verlangen ehrliche Adverse Action Reasons sowie Fairness-Tests.
  • In regulierten Entscheidungen schlägt Explainability die reine Genauigkeit. Ein Modell, das Sie nicht erklären können, lässt sich nicht deployen, egal wie gut es prognostiziert.
  • Validierung geht nach dem Launch weiter. Überwachen Sie Drift mit Metriken wie PSI, tracken Sie Overrides und eskalieren Sie, wenn Schwellenwerte gerissen werden.