Datenverträge für Modellrisiko

Ein stabiler Modellscore ist noch kein Datenvertrag. Model-Risk-Governance scheitert, wenn Training, Scoring und Monitoring verschiedene Snapshots und Feature-Definitionen nutzen — und niemand den Bruch sieht, weil der Score weiter „grün“ bleibt. Dieselbe Kennzahl darf Meldeinput und Modelloutput sein; ohne getrennte Verträge vermischt Risk die Scoring-Population mit der Aufsichtsdefinition.

Dieser Teil definiert den Mindestvertrag für Model-Risk-Daten — auf dem Report Pack aus Teil 2 und vor dem DORA-Mapping.

Vorher: Qualität regulatorischer Reports steuern. Weiter: DORA-Anforderungen auf ICT-Controls mappen.

Ansatz

Jedes materielle Modell erhält vor produktivem Scoring:

1. eine Modell-ID im Inventory plus einen Feature-Vertrag (Semantik, Grain, erlaubte Transformation);
2. getrennte Verträge für Training, Scoring und Monitoring — nicht einen Snapshot für alle drei Zwecke;
3. eine Population und einen Zeitbezug, die ein Validator in einem Satz erklären kann;
4. einen Feature-Freeze und eine Freigabe für Breaking Changes durch den Model Risk Owner;
5. eine Drift-Schwelle, die den Lauf stoppt — nicht nur ein Dashboard-Signal.

Kein Feature wird umdefiniert, ohne Revalidierung. Der Warehouse-Admin liefert Jobs; er akzeptiert das Modellrisiko nicht.

Feature-Vertrags-Workflow

1. Modell und Zweck trennen

Der Model Risk Owner beschließt, welches Modell diese Serie zuerst bindet und wofür der Lauf gilt: Training, Validierung, Scoring oder Monitoring. Derselbe Score-Name für vier Zwecke ist kein Vertrag.

2. Feature-Semantik einfrieren

Jedes materielle Feature braucht eine Definition, eine Quelle und eine erlaubte Transformation. Ein umbenanntes Feld im Mart ist kein Freeze.

3. Population und Snapshot festlegen

Wer gehört in den Lauf, welcher Stichtag gilt, welches Grain? Scoring darf die Trainingspopulation nicht still erweitern oder einen anderen Snapshot ziehen.

4. Training gegen Scoring binden

Der Contract nennt, welcher Snapshot Scoring speist gegenüber Training. Weicht die Population ab, stoppt der Lauf oder braucht eine befristete Exception.

5. Monitoring und Drift

Drift ist ein prüfbares Signal an der Input-Grenze — nicht ein Kommentar im Model Card. Die Schwelle, die den Lauf stoppt, gehört dem Owner, nicht dem Dashboard-Autor.

6. Breaking Changes freigeben

Feature-Umbauten, neue Quellen und Zweckwechsel erzeugen eine Vertragsversion und einen Revalidierungs-Trigger. Still nachziehen zerstört die Nachvollziehbarkeit — und vermischt den Score mit der Meldezahl aus Qualität regulatorischer Reports.

Handoffs

Anti-Patterns

• Training-, Scoring- und Monitoring-Snapshot unter einem Label führen
• Feature-Definition still im Auswertungstabelle ändern und den Score weiterlaufen lassen
• Modellscore und Aufsichtsdefinition als dieselbe Kennzahl berichten
• Drift nur visualisieren, ohne Schwelle, die den Lauf stoppt
• Warehouse-Admin als Model verantwortliche Person im Risk-Bereich einsetzen

Erster Umsetzungsschnitt

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Banking & Insurance Landscape
• Lernpfad — Banking & Insurance Landscape

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Ein Modell wählen, das eine materielle Entscheidung oder eine Meldezahl speist, und Training- vs. Scoring-Snapshot nebeneinanderlegen.
2. Fünf Features einfrieren: Semantik, Quelle, Population, Zeitbezug.
3. Einen Contract-Check scharf schalten, der Scoring stoppt, wenn die Population vom Training abweicht.
4. Einen Breaking-Change-Weg mit Owner, Revalidierung und Ablaufdatum an einem realen Feature-Umbau testen.