Risk-Taxonomie und KRIs als Data Contracts

Risk-Berichte scheitern selten an fehlenden Dashboards. Sie scheitern, wenn „Operational Risk“ in einer Region ein anderes Grain meint als in einer anderen — und KRIs ohne Version und Owner in BI-Tools neu erfunden werden.

Dieser Teil macht Taxonomie und KRIs zu Data Contracts. Einstieg: Governance in Risk.

Vorher: Legal Hold vs. Analytics-Retention. Weiter: Customer Service Identität & Zweck.

In einem Satz: Kein zertifizierter Key Risk Indicator (KRI) ohne Grain, Version, Owner und nachweisbare Aggregation.

Entscheidung

Jede materielle Key Risk Indicator (KRI)-Familie erhält vor Zertifizierung im Reporting:

1. Taxonomie-Knoten mit stabiler ID und Parent-Beziehung;
2. Key Risk Indicator (KRI)-Contract: Definition, Population, Grain, Formel, Frequenz, Schwellen;
3. Data Owner (Risk Business) und Steward für Pflege;
4. Version und Änderungsnotiz; Consumer sehen die Version;
5. Aggregationsregeln und Ausnahmeweg bei Threshold-Breach.

Catalog beschreibt die Metrik; der Contract regelt Freigabe und Drift.

Workflow

1. Taxonomie schneiden

Der Risk Owner legt wenige stabile Level fest — tiefe, unklare Hierarchien verlieren Mapping. Der Steward erfasst regionale Labels auf gemeinsame Knoten. Ohne Mapping meint „Operational Risk“ in zwei Regionen zwei Welten, und Board-Packs addieren Unvergleichbares.

2. Key Risk Indicator (KRI)-Grain fixieren

Event, Loss, Control Failure oder Exposure — ein Grain pro Key Risk Indicator (KRI). Mischungen gehören in abgeleitete Produkte mit eigenem Contract. Der Owner entscheidet das Grain; der Steward schreibt es in den Contract. Ein Key Risk Indicator (KRI) ohne Grain und Population ist ein Name auf einer Kachel.

3. Berechnung und Quelle binden

Der Custodian implementiert die freigegebene Formel, Quelle und Validierung; Tool-lokale Neuberechnung ist Abweichung, kein Feature. Der Contract listet Berechnungsreferenz (Semantic/Metrics-ID oder SQL-Hash) und letzten Dual-Run-Parity-Check vs. Finance. Eine Dashboard-Kachel ohne diesen Contract ist kein governer Key Risk Indicator (KRI).

4. Schwellen und Eskalation

Breach erzeugt ein Ticket an Steward und Owner — nicht nur eine rote Kachel. Schwellen leben im Contract, nicht allein in einem BI-Tool. Ausnahme braucht Freigeber und Ablauf. Wer Schwellen nur im Dashboard pflegt, kann Drift weder erklären noch zurücknehmen.

5. Evidenz für Aufsicht

Der Steward speichert Snapshot von Version, Population und Berechnung zum Stichtag — reproduzierbar ohne Live-Dashboard. Audit erhält Versionssnapshot plus Breach-Historie. Catalog-Zertifizierung ohne Versionsvertrag ist Auffindbarkeit, keine Freigabe. Technical Owner entscheidet fachliche Risk-Semantik nicht.

Handoffs

Anti-Patterns

• Key Risk Indicator (Risikokennzahl)-Namen ohne fachliche Ebene und Grundgesamtheit
• Regionale Taxonomien ohne Mapping
• Schwellen nur in einem BI-Tool pflegen
• Catalog-Zertifizierung ohne Versionsvertrag
• Technical verantwortliche Person entscheidet fachliche Risk-Semantik

Umsetzung im Alltag

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 — Extended Domain Landscapes
• Lernpfad — Extended Domain Landscapes

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. Fünf Top-KRIs mit Grain, Formel und Owner dokumentieren.
2. Eine Taxonomie-Differenz zwischen zwei Regionen auflösen oder als Mapping erfassen.
3. Versionierung und Consumer-Hinweis für eine Key Risk Indicator (KRI) aktivieren.
4. Einen Breach-Ausnahmeweg testen und Durchlaufzeit messen.