Banken · 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 startklar. Das Data-Science-Team ist zuversichtlich. Aber wenn niemand einen Input bis zu seinem 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 dieses Validierungsgespräch. Sie lernen die Regeln, die Prüfer anwenden, die Kontrollen, die sie einfordern, und warum data lineage der Punkt ist, an dem die meisten Modelle scheitern.

Warum Banken Modelle überhaupt steuern

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

Wenn ein Modell falsch liegt, sind echtes Geld und echte Menschen betroffen. Ein verzerrtes Scoring-Modell kann Kredite unfair ablehnen. Ein schwaches AML-Modell kann kriminelle Aktivität übersehen. Regulierer nennen diese Exponierung model risk: das Verlustrisiko aus Entscheidungen, die auf fehlerhaften oder falsch eingesetzten Modellen beruhen.

Das zentrale US-Regelwerk ist SR 11-7, eine Guidance, die Federal Reserve und 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 anspruchsvoll. Es ruht auf drei Ideen.

1. Effective challenge

Jemand, der unabhängig von den Modellentwicklern 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 (MRM)-Funktion getrennt vom Data-Science-Team ein. Die Entwickler bauen. MRM stellt infrage.

2. Validierung über den Lebenszyklus

Validierung ist kein einmaliges Gate. SR 11-7 verlangt eine Prüfung bei der Entwicklung, vor dem Deployment und laufend. Ein Scoring-Modell, das 2024 funktionierte, kann sich verschlechtern, wenn sich das Kundenverhalten verschiebt. Dieser Verfall heißt model drift, und die Überwachung darauf ist Pflicht.

3. Governance, Policy und Kontrollen

Vorstand und Senior Management tragen die Verantwortung für model risk. Es muss ein model inventory geben (ein vollständiges Register jedes eingesetzten Modells), dokumentierte Policies und klare Rollen. Ein Prüfer fragt zuerst nach dem Inventar. Ein fehlendes Modell ist schon für sich ein Governance-Versagen.

Im Validierungsgespräch

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

Konzeptionelle Solidität. Ist das Modell schlüssig? Wenn ein Kreditmodell die Postleitzahl als Variable nutzt, wird jemand fragen, ob das ein Proxy für Ethnie ist, was Fair-Lending-Bedenken auslöst.

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 das, was es behauptet? Validatoren backtesten Prognosen gegen reale Ergebnisse.

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

Data lineageData lineageData Lineage zeigt, wie Daten sich durch Systeme bewegen und dabei transformiert werden, von der Quelle bis zur Nutzung: woher sie kommen, was sie verändert hat und wohin sie gehen.Vollständige Definition ansehen →: die entscheidende Kontrolle

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 zur Nutzung im Modell. Denken Sie an einen Belegnachweis für jede Zahl.

Warum Prüfer darauf beharren:

• Wenn Sie eine Variable nicht zurückverfolgen kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →ö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 zerstört.

Ein konkretes Beispiel. Ein Feature „debt-to-income ratio“ sieht einfach aus. Aber das Einkommen kommt möglicherweise aus einem System, die Verschuldung aus einem anderen, und die Quote wird in einem dritten mit Rundungsregeln berechnet, die von der Quelle abweichen. Jeder Sprung ist eine Stelle, an der sich Fehler und Regeländerungen verstecken.

Moderne Banken verfolgen lineage mit Metadaten-Tools und Versionskontrolle. So sieht in etwa aus, was ein lineage-Datensatz erfasst:

feature: debt_to_income_ratio
source_income: core_banking.customer_income   # verified monthly
source_debt: credit_bureau.total_obligations  # refreshed at pull
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 begrenzen

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 ausgeben: 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 anhand geschützter Merkmale. Selbst wenn ein Modell Ethnie nie sieht, kann eine korrelierte Variable zu disparate impact führen, einem Ergebnis, das eine geschützte Gruppe benachteiligt. Validatoren führen Fairness-Tests durch, um das zu erkennen.

In der EU und in Großbritannien ergänzt die General Data Protection Regulation (GDPR) die Zweckbindung (Daten, die zu einem Zweck erhoben wurden, dürfen nicht frei weiterverwendet werden), das Recht auf Erklärung bei automatisierten Entscheidungen und strenge Consent-Regeln.

Die praktische Konsequenz: Datenschutz ist kein rechtlicher Nachgedanke, der am Ende angeschraubt wird. Es 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 Prinzipien von SR 11-7 und wie Banken Modelle vor dem Deployment validieren]

Explainability und das Black-Box-Problem

Prüfer sind bei komplexen Machine-Learning-Modellen vorsichtig, weil sie 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 Dokumentationslatte. Banken nutzen Werkzeuge wie SHAP values (eine Methode, die eine Prognose den einzelnen Inputs zuordnet), um einzelne Entscheidungen zu erklären. Wird ein Kunde abgelehnt, muss die Bank trotzdem ehrliche adverse action reasons erzeugen.

Die Daumenregel im Raum: Wenn Sie es nicht erklären können, können Sie es in einer regulierten Entscheidung nicht einsetzen.

Laufende Überwachung nach dem Launch

Die Genehmigung ist nicht die Ziellinie. Sobald ein Modell live ist, richtet MRM eine kontinuierliche Überwachung ein.

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

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

Override-Tracking erfasst, wie oft Menschen das Modell überstimmen. Häufige Overrides deuten darauf hin, dass dem Modell nicht vertraut wird oder es nicht zweckmäßig ist.

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

Was Prüfer wirklich 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 Einhaltung von Datenschutz- und Fair-Lending-Vorgaben.
• Explainability, die ausreicht, um jede Entscheidung zu begründen.
• Laufende Überwachung mit definierten Eskalations-Triggern.

Fehlt eines, wartet das Deployment. Deshalb konnte das Data-Science-Team in unserer Eingangsszene nicht allein auf Zuversicht starten.

Key Takeaways

• Model risk wird gesteuert, nicht unterstellt. SR 11-7 verlangt unabhängige effective challenge, Validierung über den Lebenszyklus und Verantwortung auf Vorstandsebene über ein model inventory.
• Data lineage ist die Kontrolle, die zuerst versagt. Wenn Sie eine Variable nicht zu ihrer Quelle zurückverfolgen und nicht belegen können, wie sie transformiert wurde, geht das Modell nicht live.
• Datenschutz ist eine Design-Restriktion. FCRA, Fair-Lending-Regeln und GDPRGDPREU-Verordnung zur Erhebung, Speicherung und Nutzung personenbezogener Daten, mit Bußgeldern, die am weltweiten Umsatz bemessen werden.Vollständige Definition ansehen → begrenzen, welche Daten ein Modell nutzen darf, und verlangen ehrliche adverse action reasons und Fairness-Tests.
• In regulierten Entscheidungen schlägt Explainability die reine Genauigkeit. Ein Modell, das Sie nicht erklären können, darf nicht eingesetzt werden, egal wie gut es prognostiziert.
• Validierung geht nach dem Launch weiter. Überwachen Sie drift mit Metriken wie PSI, verfolgen Sie Overrides und eskalieren Sie, wenn Schwellenwerte gerissen werden.