Risikomanagement für Modelle im Jahr 2026: Ein Leitfaden für Banker zur überarbeiteten Interagency-Richtlinie

Was hat sich in der MRM-Richtlinie vom April 2026 geändert

Am 17. April 2026 haben die Federal Reserve, die FDIC und die OCC SR 11-7, OCC 2011-12, FIL-22-2017 und zugehörige BSA/AML-Ausgaben aufgehoben und durch einen expliziter risikobasierten, prinzipiengetriebenen Rahmen für das Management von Modellrisiken ersetzt.

Dies ist keine geringfügige technische Aktualisierung. Sie spiegelt eine breitere Sichtweise wider, dass Modelle zentral für die Entscheidungsfindung von Banken sind und dass Modellrisiken mit der gleichen Ernsthaftigkeit wie Kredit- oder Marktrisiken gesteuert werden müssen.

Für Praktiker innerhalb einer Bank bedeutet dies konkrete Erwartungen: Bestände werden nach Wesentlichkeit gestuft, Kontrollen werden verhältnismäßig angewendet und unser Lebenszyklus ist durchgängig nachvollziehbar.

Bei einem traditionellen Stack bedeutet diese Antwort zwei bis drei Quartale Sprintarbeit: Migration von Beständen, Überarbeitung von Validierungsvorlagen, neue Überwachungspipelines, Aktualisierung der Dokumentation, Onboarding von Anbietermodellen und parallele Arbeitsströme für GenAI und agentenbasierte Systeme, die von Aufsichtsbehörden nach dem Prinzip als relevant erachtet werden. Jeder Arbeitsstrang ist ein Projekt, ein Änderungsantrag und ein Audit-Risiko.

Die eigentliche Frage ist nicht: "Wie bauen wir die Konformität mit dieser Richtlinie auf?" Es ist: "Welche Plattformentscheidung macht die nächste Richtlinienänderung – und die darauf folgende – zu einer Konfigurationsübung statt zu einem Programm?"

Was der neue MRM-Rahmen tatsächlich verlangt

Die Überarbeitung von 2026 ist weniger eine Neufassung von Kontrollen als eine Neu-Segmentierung, wie wir sie anwenden. Fünf Änderungen sind für Praktiker wichtig:

1. Risikobasierte Anpassung — Jedes Modell muss in einer Stufe sitzen, die das inhärente Risiko, die Exposition und den Zweck widerspiegelt. Stufe-1-wesentliche Modelle unterliegen einer vollständigen Lebenszyklus-Überwachung; niedrigere Stufen erhalten verhältnismäßige, leichtere Kontrollen – aber nur, wenn wir die Einstufung selbst nachweisen können.
2. Lebenszyklus-Denken — Entwicklung, Validierung, Bereitstellung, Überwachung und Stilllegung sind eine gesteuerte Kette. Aufsichtsbehörden erwarten eine Nachverfolgbarkeit über jedes Glied, nicht Momentaufnahmen an Übergabepunkten.
3. Effektive Anfechtung — Challenger-Modelle, Ergebnisanalysen, Benchmarking und Sensitivitätstests müssen versioniert und reproduzierbar sein – keine einmaligen Memos.
4. Kontinuierliche Überwachung — Leistungsdrift, Daten-Drift und Stabilität müssen kontinuierlich verfolgt werden, wobei Schwellenwerte an die Wesentlichkeit angepasst werden.
5. Prinzipien gelten auch für KI — GenAI und agentenbasierte Systeme sind formell nicht ausgeschlossen, erben aber die Prinzipien. Aufsichtsbehörden und interne Prüfer wenden die MRM-Erwartungen bereits analog auf LLM-basierte Underwriting-Assistenten, AML-Triage-Agenten und kundenorientierte Copiloten an.

Der gemeinsame Nenner: Nachweise müssen als Nebenprodukt der Modellerstellung erbracht werden, nicht nachträglich rekonstruiert werden. Das ist ein Plattformproblem, kein Richtlinienproblem.

Unser Ansatz

Wir nehmen die regulatorische Absicht als gegeben hin. Anstatt die Richtlinie zu diskutieren, konzentrieren wir uns auf das daraus resultierende Betriebsmodell:

• Wie können Banken Risikostufung, Verhältnismäßigkeit und effektive Anfechtung systemisch und nicht manuell gestalten?
• Wie können Nachweise guter Governance automatisch aus der täglichen Modellarbeit generiert werden?
• Welche Plattformentscheidung macht die nächste Richtlinienaktualisierung von einem mehrmonatigen Programm zu einer Konfigurationsänderung?

Der Rest dieses Artikels skizziert eine Referenzarchitektur auf Databricks – entwickelt, um diese Anforderungen auf einem einzigen, gesteuerten Substrat zu erfüllen, da diese Anforderungen in der Praxis nicht zuverlässig aus einer Sammlung von Einzellösungen zusammengesetzt werden können, ohne die Fragmentierung wiederzubeleben, die MRM beseitigen soll.

Wir ordnen die überarbeiteten MRM-Erwartungen konkreten Databricks-Funktionen zu, damit Banken sehen können, wie sie diese Prinzipien auf dem Lakehouse operationalisieren können.

Die Databricks Referenzarchitektur für MRM

Die folgende Architektur macht "eine Abstammungsgraph" mehr als nur ein Slogan. Jede Lebenszyklusphase wird zu einem gesteuerten Objekt in Unity Catalog. Dieselben Grundelemente dienen klassischen ML und GenAI, sodass das MRM-Team ein Framework und nicht zwei verwaltet.

Vier Ebenen, ein Substrat

Architektonischer Anker

Die Governance-Ebene ist nichts, was am Ende angefügt wird – sie ist das, in das jede andere Ebene schreibt. Deshalb wird eine Stufenänderung zu einer Metadatenaktualisierung statt zu einer Migration, und deshalb erhält ein Prüfer eine einzige Antwort aus einem einzigen System.

Zuordnung des ML-Lebenszyklus zu MRM-Nachweisen

Jede Lebenszyklusphase erzeugt eine spezifische Art von Nachweis, die die neue Richtlinie erwartet. Die Databricks-Architektur wandelt diesen Nachweis in ein strukturiertes Nebenprodukt der normalen Arbeit um – nicht in einen separaten Compliance-Durchlauf am Ende.

Jede einzelne Funktion kann aus Punktwerkzeugen zusammengesetzt werden. Der architektonische Punkt ist, dass sie auf Databricks ein einziger Abstammungsgraph sind. Der Prüfer stellte die Frage: „Welche Daten haben dieses Modell trainiert, wer hat es validiert, wie hat es sich verändert und welche Produktionsentscheidungen haben es verwendet?“ ist eine einzige Traversierung – keine abteilungsübergreifende Beweiserhebungsübung.

Wichtige Governance-Muster

5.1 Wesentlichkeitsstufung als Metadaten, nicht als Migration

Jedes Modell im Registrierungssystem verfügt über strukturierte Tags: Wesentlichkeitsstufe, Geschäftsbereich, Leitlinienversion, zugewiesener Prüfer, letztes Validierungsdatum. Diese Tags sind keine Dekoration – sie werden von Zugriffsrichtlinien, Überwachungsschwellenwerten und dem MRM-Dashboard auf Portfolioebene gelesen.

Wenn Vorgesetzte die Wesentlichkeitsdefinitionen verfeinern – oder wenn interne Richtlinien dies tun – ändert sich die Stufe. In dieser Architektur ist eine Stufenänderung eine Tag-Aktualisierung, die in wenigen Minuten angewendet wird und in jeder nachgelagerten Kontrolle sichtbar ist. Es gibt keine Re-Plattformierung, keine Pipeline-Neufassung, keine Neufassung der Dokumentation.

5.2 Verhältnismäßigkeit durch ABAC erzwungen

Verhältnismäßigkeit ist das zentrale Prinzip der Leitlinien und historisch am schwierigsten nachzuweisen. Auf Databricks wird sie zu einer attributbasierten Zugriffsregel, die an das Stufentag gebunden ist.

In der Praxis sieht dies wie einfache ABAC-Richtlinien für Unity Catalog-Objekte aus. Zum Beispiel:

• Stufe-1-wesentliche Modelle: Die Beförderung in die Produktion erfordert die Genehmigung der unabhängigen MRM-Prüfergruppe. Doppelte Kontrolle wird erzwungen, nicht gefördert.

• Stufe-2-Standardmodelle: Teamleiter plus Prüfer können befördern. Leichtere Aufsicht, immer noch prüfbar.

• Stufe-3-Modelle mit geringer Wesentlichkeit: Der Modellbesitzer kann innerhalb seines eigenen Arbeitsbereichs befördern; Überwachungsschwellenwerte sind lockerer; Dokumentationsanforderungen sind reduziert.

Die Bank benötigt kein Richtliniendokument, das erklärt, wie Verhältnismäßigkeit funktioniert. Die Zugriffssteuerungs-Protokolle erklären es für jedes Modell, für jede Beförderung, solange das Prüfungsaufbewahrungsfenster läuft.

In der Praxis lässt sich dies direkt in die ABAC-Richtlinienlogik für Unity Catalog-Objekte übersetzen:

WENN model.tier = 'Tier1'

DANN erforderliche_genehmigerrolle IN ('MRM_Validator', 'Model_Risk_Committee')

UND erforderliche_doppelte_kontrolle = WAHR

Dasselbe Stufentag kann auch strengere Überwachungsschwellenwerte und kürzere Validierungszyklen steuern, ohne benutzerdefinierten Code pro Modell. Die Bank benötigt kein separates Richtliniendokument, um die Verhältnismäßigkeit zu erklären; Zugriffssteuerungs-Protokolle und Konfiguration demonstrieren sie, Modell für Modell, Beförderung für Beförderung.

5.3 Der MRM-Katalog als Informationsarchitektur

Eine saubere Kataloghierarchie ist die am meisten unterschätzte Governance-Entscheidung. Ein praktikables Muster trennt Inventar und Nachweise von den Modellen selbst:

• Inventarkatalog – enthält Modelldaten, Prüfer-Genehmigungen, Inventar-Overlays, Prüfer-Warteschlangentabellen.

Wichtige Tabellen in diesem Katalog folgen einem einfachen Muster:

• models.inventory – eine Zeile pro Modellversion, mit Feldern wie Stufe, Besitzer, Leitlinienversion, Verwendungszweck und abhängigen Prozessen.

• models.validation_log – eine Zeile pro Validierungsereignis, indiziert nach model_version_id, mit validator_id, validation_scope, gefundenen Problemen und Restrisikobewertung.

• Klassischer ML-Katalog – Schemata pro Geschäftsbereich für Kredit-, AML-, Betrugs-, Kapitalmodelle.

• GenAI-Katalog – LLM-Endpunkte und Agenten, registriert als erstklassige Modelle mit Tool-Registrierungen.

• Überwachungskatalog – Drift-, Leistungs- und Fairness-Metrik-Tabellen, die von Lakehouse Monitoring generiert werden.

• Nachweiskatalog – Challenger-Läufe, Validierungsartefakte, Modellkarten, archivierte außer Betrieb genommene Modelle.

Diese Trennung ermöglicht es der MRM-Führung, Lesezugriff auf Nachweise und Überwachung zu gewähren, ohne die zugrunde liegenden Trainingsdaten preiszugeben – ein häufiger Stolperstein bei der Prüfungsvorbereitung.

Klassisches ML und GenAI unter einem Framework

Banken betreiben beides gleichzeitig: ein PD-Modell, das von jahrzehntelanger MRM-Praxis gesteuert wird, und einen LLM-basierten AML-Triage-Assistenten, für den noch niemand eine Steuerung gefunden hat. Der traditionelle Instinkt ist, ein zweites Framework für den zweiten Modelltyp zu bauen. Das verdoppelt die Kosten, verdoppelt die Prüfungsfläche und garantiert Divergenz.

Auf Databricks teilen klassisches ML und GenAI dieselbe Registrierung, dieselben Lebenszyklusphasen und dasselbe Nachweismuster – mit schichtspezifischen Funktionen, wo der Modelltyp sie erfordert.

Wenn Vorgesetzte MRM-Prinzipien auf GenAI anwenden – was sie bereits tun –, richten wir kein zweites Framework ein. Wir wenden das erste an.

Drei Wahlbereiche, eine Plattform

Data Scientists & Model Developers – Geschwindigkeit ohne Kompromisse

• Arbeiten Sie in einer gesteuerten Notebook-Umgebung, in der Tracking, Abstammung und Feature-Registrierung automatisch erfolgen – keine Compliance-Checklisten, die am Ende hinzugefügt werden.

• Iterieren Sie schnell mit AutoML und Agent Bricks über Baselines und agentische Muster; jede Iteration wird protokolliert und ist reproduzierbar.

• Liefern Sie schneller, da Beförderung, Überwachung und Dokumentation in denselben Workflow integriert sind – nicht an ein separates Team übergeben.

MRM & unabhängige Prüfer – Überprüfung mit vollem Kontext

• Lesezugriff auf die exakten Trainingsdaten, Feature-Versionen und den Code, der das Modell erzeugt hat – keine Datenkopien, keine Veralterung.

• Challenger- und Benchmark-Läufe versioniert neben dem Champion; Sensitivitätsanalysen auf Abruf reproduzierbar.

• Die Genehmigung ist selbst ein erstklassiges Artefakt im Registrierungssystem, das an die Modellversion gebunden ist – kein Memo, das an einen E-Mail-Thread angehängt ist.

• Databricks Apps bieten einen strukturierten Überprüfungsworkflow: Warteschlange, Kommentare, Genehmigung, Eskalation – alles prüfbar.

Risk & Compliance Leadership – nachweisbare Aufsicht im Portfolio-Maßstab

• Ein Dashboard über das Inventar: Stufenverteilung, Validierungsstatus, Überwachungszustand, offene Probleme – keine fünf zusammengefügten GRC-Exporte.

• Stufe und Eigentümerschaft werden durch ABAC-Richtlinien durchgesetzt. Proportionalität ist kein Richtliniendokument; es ist eine Zugangsregel mit einem Audit-Protokoll.

• Drittanbieter- und GenAI-Modelle werden auf die gleiche Weise registriert wie interne Modelle. Abdeckungslücken sind sichtbar, bevor ein Prüfer sie findet.

Der Prüfer RFI, End-to-End

Betrachten Sie eine repräsentative Frage aus einer aufsichtsrechtlichen Überprüfung: "Zeigen Sie uns die Validierungsnachweise, die Produktionsleistung und die Drift-Historie für das Kredit-PD-Modell in den letzten zwölf Monaten, aufgeschlüsselt nach Geschäftsbereich."

Auf einem fragmentierten Stack ist dies eine zweiwöchige Beweiserhebungsübung über die Registrierung, den Data Lake, das BI-Tool und das GRC-System – jedes mit seinem eigenen Identitätsmodell und seiner eigenen Datenaktualität. Auf der Databricks-Referenzarchitektur:

• Die Validierungsnachweise befinden sich im Inventarkatalog und sind an die Modellversion gebunden.

• Produktionsleistung und Drift-Historie befinden sich im Überwachungskatalog und werden kontinuierlich von Lakehouse Monitoring geschrieben.

• Der Geschäftsbereich ist ein Tag am Modell und eine Slicing-Dimension am Monitor.

• Genie space über den MRM-Katalog beantwortet die Frage in natürlicher Sprache, wobei zeilenbasierte Zugriffsfilter sicherstellen, dass der Prüfer nur sieht, wozu er berechtigt ist.

Die Bearbeitungszeit verschiebt sich von Wochen auf Stunden. Wichtiger ist, dass die Nachweise dieselben sind, die das MRM-Team der Bank selbst verwendet – es gibt also keine Diskrepanz zwischen dem, was die Bank intern berichtet, und dem, was sie dem Prüfer zeigt.

Warum Databricks – Die Fünf Gründe des Bankers

1. Richtlinienänderungen werden zu Metadatenänderungen – Wenn sich Materialitätsdefinitionen, Stufenschwellenwerte oder Validatorrollen ändern, werden Tags und Zugriffsrichtlinien im Unity Catalog aktualisiert. Kein Re-Plattforming, keine Pipeline-Neuschreibungen, keine Dokumentationsaktualisierungen.
2. Eine Audit-Spur, nicht sieben – Daten, Features, Modelle, Überwachung und Dokumentation befinden sich auf einem Substrat. Prüferfragen werden in einem System end-to-end verfolgt – nicht über ein Warehouse, einen Feature Store, eine Registrierung, ein BI-Tool und eine GRC-Plattform.
3. Proportionalität ist durchsetzbar – Tier-1-Modelle erhalten strenge Kontrollen, Tier-3-Modelle leichte – beides wird durch dieselben ABAC-Richtlinien durchgesetzt. Proportionalität wird zu einer verteidigungsfähigen, prüfbaren Tatsache.
4. GenAI ist kein paralleles Universum – Klassische Kredit-, AML-, Betrugs-, LLM-Endpunkte und agentische Systeme teilen sich eine Registrierung mit demselben Bewertungs-, Überwachungs- und Dokumentations-Harness. Abdeckungslücken sind sichtbar, nicht in einem zweiten Toolchain versteckt.
5. Kapazität zum Proben vor dem Binden – Schnelle Prototypen bedeuten, dass ein neues Kontrollmuster in Wochen an einem Tier-1-Modell getestet, mit MRM verfeinert und dann skaliert werden kann. Die regulatorische Reaktion wird zu iterativem Engineering – so wie die Bank bereits alles andere betreibt.

Risikomanagement nach links verschieben

Die Leitlinien von 2026 verlangen von Banken, nach links zu verschieben ("shift left"), d. h. Risikokontrollen ganz an den Anfang des Modelllebenszyklus zu verlagern. Durch die Verwendung von Spark Declarative Pipelines (SDP) wird Governance zu einem automatisierten Teil des Datenflusses, anstatt zu einer manuellen Hürde. Anstatt Modelle nach ihrer Erstellung zu prüfen, verwendet SDP integrierte Qualitätserwartungen, um nicht konforme Daten oder instabile Features zu blockieren, bevor sie die Model Registry erreichen. Dies stellt sicher, dass jedes Asset in der Medallion Architektur nach Design konform ist, wobei eine vollständige Audit-Spur als natürliches Nebenprodukt der Entwicklung generiert wird. Durch die Automatisierung der "effektiven Anfechtung" durch diese Pipelines können MRM-Teams weniger Zeit mit manueller Datenerfassung und mehr Zeit mit der übergeordneten Aufsicht verbringen.

Das Kapazitätsargument

Jede regulatorische Reaktion greift auf einen begrenzten Pool von MRM-Analysten, Modelldevlopern und Validatoren zurück. Wie diese Kapazität eingesetzt wird, ist der Unterschied zwischen einer Plattform, die hilft, und einer, die bremst. Drei strukturelle Vorteile ergeben sich aus einem einheitlichen Substrat:

• Kapazität wird nicht mehr durch Integration verbraucht – Auf einem fragmentierten Stack wird knappe MRM-Kapazität für Integrationsarbeiten verbraucht – Abgleich von Inventaren über Tools hinweg, Neuerstellung der Überwachung, Neudokumentation dessen, was die Tools bereits wissen.
• Menschen konzentrieren sich auf Urteilsvermögen, nicht auf Klempnerarbeiten – Auf einer einheitlichen Plattform wird Kapazität für die Arbeit frei, die nur Menschen leisten können: Urteilsvermögen über Materialität, effektive Anfechtung des Modelldesigns, Gespräch mit Prüfern.
• Governance wird zum Nebenprodukt, nicht zum Projekt – Lineage, Dokumentation, Überwachung und Zugriffskontrolle werden als Nebenprodukt der Art und Weise erstellt, wie Modelle erstellt und bereitgestellt werden – nicht als separater Compliance-Pass am Ende.

Das strukturelle Argument für Databricks ist nicht, dass es diese Leitlinienänderung schneller bewältigt – obwohl es das tut –, sondern dass es die nächste und die darauf folgende von einem Programm zu einer Konfiguration macht.

Organisatorischer Werttreiber

Eine bemerkenswerte Einschränkung der KI-Roadmap einer Bank ist nicht nur Rechenleistung oder Daten – es ist die menschliche Kapazität von Model Risk Teams und dem Center of Excellence (CoE). Da die aktuellen Leitlinien die Definition von "modellähnlichen" Systemen auf GenAI und agentische Workflows erweitern, wird das Volumen der Validierungsanfragen den Personalbestand qualifizierter Praktiker übersteigen.

Automatisierungsschicht "Erster Durchgang"

Anstatt dass jeder LLM-Prototyp eine maßgeschneiderte manuelle Überprüfung erfordert, ermöglicht Databricks dem CoE, die Standards der Bank in eine erste Automatisierungsschicht zu kodifizieren.

• Self-Service-Triage – Entwickler verwenden standardisierte MLflow-Evaluierungsrezepte (Toxizität, Bodenständigkeit, PII-Leckage), die automatisch ausgeführt werden. Ein Modell, das den ersten Durchgang nicht besteht, gelangt nie auf den Schreibtisch des CoE.
• Standardisierte Nachweise – Da die Plattform ein gemeinsames Lineage- und Dokumentationsschema erzwingt, verbringt das CoE keine Wochen mit der Bereinigung von Nachweisen. Sie verbringen Stunden mit der Überprüfung.

Das praktische Problem ist bekannt: Eine Geschäftseinheit möchte einen LLM-Assistenten in vier Wochen ausliefern, während das CoE eine sechsmonatige Rückstand hat.

Databricks löst dies, indem es dem CoE ermöglicht, die Ausführung zu delegieren und gleichzeitig die Kontrolle zu behalten. Das CoE stellt das Automatisierungs-Harness bereit – die Überwachung, Modellkarten und Metriken, die die Aufsicht wiederholbar machen. Das Geschäft bewegt sich mit GenAI-Geschwindigkeit. Die Leitlinien von 2026 werden von einem Engpass zu einem Leitplanken umgewandelt.

Das Fazit

Die Leitlinien vom April 2026 sind nicht die letzte aufsichtsrechtliche Verschiebung, die wir in diesem Zyklus sehen werden. Agentic AI-Prinzipien, die Aufsicht über Drittanbietermodelle und die Klimarisikomodellierung sind alle in Bewegung. Die Frage ist, ob unsere Plattform jede dieser Änderungen in ein dreivierteljähriges Projekt oder einen vierwöchigen Prototyp verwandelt. Diese Entscheidung wird einmal getroffen.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag