Risk-Taxonomie und KRIs als Data Contracts

Begriffe vor dem Lesen

• Eine betriebliche Vereinbarung hält fest, wer entscheidet, welche fachliche Einheit betrachtet wird, welche Regel technisch wirkt und wo der Nachweis liegt.
• Die fachliche Zählebene beschreibt, was genau gezählt oder beurteilt wird, etwa ein Ticket, ein Vorfall, eine Person oder ein Vertrag.
• Ein Nachweis macht eine Entscheidung, Prüfung, Freigabe oder Ausnahme später nachvollziehbar.
• Der fachlich Verantwortliche entscheidet Zweck und Bedeutung; der technische Betreiber setzt die beschlossene Regel in Systemen um.

Risikoberichte scheitern selten an fehlenden Dashboards. Sie scheitern, wenn „operatives Risiko“ in einer Region Vorfälle und in einer anderen einzelne Tickets zählt, während Risikokennzahlen ohne Version und fachliche Verantwortung in BI-Werkzeugen neu gebaut werden.

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

Merksatz: Kein zertifizierter Key Risk Indicator (KRI) ohne fachliche Zählebene, 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, fachliche Zählebene, 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. Zählebene der Risikokennzahl festlegen

Ereignis, Verlust, fehlgeschlagene Kontrolle oder Risikoposition: Jede Risikokennzahl zählt genau eine dieser fachlichen Einheiten. Kombinationen sind abgeleitete Kennzahlen und brauchen eine eigene Vereinbarung. Die fachlich verantwortliche Person entscheidet, was gezählt wird; der Steward dokumentiert Grundgesamtheit und Berechnung. Ohne diese Angaben ist eine Risikokennzahl nur 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.

Übergaben

Typische Fehlmuster

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

Umsetzung im Alltag

1. Für fünf wichtige Risikokennzahlen fachliche Einheit, Grundgesamtheit, Formel und verantwortliche Person 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.