Governance in Banking und Insurance

Was diese Landschaft besonders macht

Banken und Versicherungen verbinden operative Bestände mit Risikomodellen und wiederkehrenden Meldungen. Eine Korrektur kann einen bereits erklärten Berichtsstand verändern. Deshalb zählen nachvollziehbare Herkunft, Versionsbezug und die Trennung von Berechnung, Prüfung und Veröffentlichung besonders. Diese Serie behandelt den gemeinsamen Kontrollkontext; Schaden und Underwriting haben eine eigene Vertiefung.

• Einen früheren Berichtsstand trotz späterer Korrektur reproduzieren können.
• Modellversion, Eingangsdaten und fachliche Übersteuerung zusammenhalten.
• Kontrollbefund mit betroffener Kennzahl und Bearbeitung verbinden.

Welche Werkzeuge zu welcher Aufgabe passen

Ausgangspunkt sind die Aufgabe und die vorhandenen Systeme. Die Beispiele zeigen geeignete Einsatzgebiete; vor einer Auswahl müssen Datenzugriff, Funktionsumfang und laufender Betriebsaufwand im eigenen Bestand geprüft werden.

Die folgenden Kapitel vertiefen die einzelnen Grenzen und Problemfelder:

• Qualität regulatorischer Reports steuern
• Datenverträge für Modellrisiko
• DORA-Anforderungen auf ICT-Kontrollen mappen
• Incident Evidence im Betrieb

Begriffe vor dem Lesen

• Governance — Gemeinsame Regeln, Rollen und Nachweise, damit Daten verantwortbar genutzt werden.
• Owner — Fachlich verantwortliche Person oder Rolle, die Zweck, Bedeutung und Freigabe klärt.
• Custodian — Technische Rolle, die Plattform, Zugriff, Betrieb oder Umsetzung betreut.
• Evidence — Prüfbarer Nachweis, der für Audit, Kontrolle, Aufsicht oder interne Freigabe verständlich bleibt.

Einstieg

Banken und Versicherungen arbeiten mit Daten, die direkt in Aufsicht, Risiko, Kapital, Kundenvertrauen und Betrieb hineinwirken. Eine Zahl im Meldebericht ist nicht einfach ein Reportwert. Ein Modellscore ist nicht einfach ein Machine-Learning-Ergebnis. Eine IT-Störung ist nicht einfach ein Ticket.

Governance muss hier strenger sein, weil Entscheidungen später belegbar sein müssen: Welche Quelle galt? Welcher Stichtag wurde genutzt? Wer hat freigegeben? Welche Kontrolle war wirksam? Welche Meldung ging wann an wen?

Wenn du nur fünf Minuten hast

1. Starte mit einem prüfbaren Objekt: Meldezahl, Modell, ICT-Kontrolle oder Incident.
2. Kläre Quelle, Stichtag, führende Definition, Owner, Kontrolle und Nachweisort.
3. Behandle Aufsicht, Risiko, Finance, ICT und Security als verbundene, aber getrennte Verantwortungen.
4. Mache Pack-Versionen, Freigaben, Locks und Korrekturen nachvollziehbar.
5. Prüfe Tool- und Cloud-Entscheidungen erst nach Daten-, Kontroll- und Nachweisanforderung.

Begriffe vor dem Lesen

• Aufsicht — Behörde oder Regulator, der Nachweise, Meldungen, Risiken und Kontrollen prüfen kann.
• Meldebericht — formelle Meldung an Aufsicht oder Regulator, zum Beispiel zu Kapital, Risiko oder Solvenz.
• DORA — EU-Verordnung zur digitalen operativen Resilienz im Finanzsektor; sie betrifft Informations- und Kommunikationstechnologie, Dienstleister, Störungen und Kontrollen.
• ICT / IKT — Informations- und Kommunikationstechnologie: Systeme, Plattformen, Netze, Dienste und Betrieb.
• Meldepaket — versionierte Zusammenstellung aus Formular, Stichtag, Quelle, Abgleich, Freigabe und Nachweis.
• Modellrisiko — Risiko, dass ein Modell falsche, ungeprüfte oder falsch genutzte Ergebnisse erzeugt.
• Incident — Störung oder Sicherheitsereignis mit Zeitlinie, Bewertung, Eindämmung und möglicher Meldepflicht.

Einfaches Schaubild

Warum diese Branche anders ist

Banking und Insurance haben höhere Anforderungen als viele andere Branchen:

• Meldezahlen müssen reproduzierbar sein.
• Modelle können Kredit-, Risiko-, Pricing- oder Kapitalentscheidungen beeinflussen.
• DORA verlangt nachvollziehbare ICT-Kontrollen und belastbare Incident-Prozesse.
• Kundendaten, Verträge, Zahlungen und Schadenfälle sind besonders sensibel.
• SaaS-Tools, Outsourcing und Cloud-Nutzung brauchen strengere Prüfung.
• On-Prem, private Cloud, souveräne Cloud oder Plattformen wie Cloudera können sinnvoller sein als frei aktivierte Standard-SaaS.

Das Ziel ist nicht, jede Bank und jede Versicherung gleich zu machen. Das Ziel ist, je Institution eine belastbare Hausordnung zu bauen: Fachbereiche behalten Ownership, technische Teams setzen kontrolliert um, Risiko, Compliance, Datenschutz, Security und Audit können prüfen.

Was diese Serie klärt

Diese Serie ist ein Brancheneinstieg. Sie zeigt vier typische Stellen, an denen Governance belastbar werden muss:

• Qualität regulatorischer Reports steuern
• Datenverträge für Modellrisiko
• DORA-Anforderungen auf ICT-Kontrollen mappen
• Incident Evidence im Betrieb

Claims, Policen und Underwriting haben eigene Betriebslogik und gehören nicht in diese Einstiegsserie: Insurance Claims & Underwriting.

Typische Governance-Fragen

• Welche Quelle ist für eine Meldezahl verbindlich?
• Welcher Stichtag gilt für Bericht, Modell und Abgleich?
• Wer darf eine Kennzahl schließen oder korrigieren?
• Wann darf ein Modelloutput als Meldeinput genutzt werden?
• Welche ICT-Kontrolle gilt für welchen kritischen Service?
• Welche Störung startet eine Meldefrist?
• Welche Nachweise müssen unverändert auffindbar bleiben?

Diese Fragen sind keine Bürokratie. Sie verhindern, dass Risk, Finance, IT und Reporting jeweils eine plausible, aber andere Wahrheit vertreten.

Mini-Fall

Die Aufsicht fragt nach der Quelle einer Kennzahl im Meldebericht. Risk verweist auf ein Risikomodell, Finance auf eine Auswertungstabelle, IT auf einen Export aus dem Kundensystem. Alle drei Zahlen sind erklärbar, aber sie zeigen nicht denselben Stichtag und nicht dieselbe fachliche Abgrenzung.

Das Problem ist nicht das Dashboard. Das Problem ist die fehlende gemeinsame Kette: Formular, Stichtag, führende Quelle, Abgleich, Freigabe und Nachweis müssen zusammengehören.

Rollen-Mapping

• Data Owner: verantwortet fachliche Bedeutung, Nutzung, Risiko und Freigabe. In dieser Branche kann das je Thema Regulatory Reporting, Risk, CISO, Finance oder Fachbereich sein.
• Data Steward: pflegt Definitionen, Abgleiche, Pack-IDs, Qualitätsregeln und Nachweise.
• Data Product Owner: priorisiert Meldepaket, Modelldaten, Kontrollmapping oder Incident-Index als nutzbare Datenprodukte.
• Data Architect: achtet auf Datenwege, Modellgrenzen, Schnittstellen, Plattformpfade und Änderbarkeit.
• Data Custodian: setzt Zugriff, Jobs, Sperren, Logs und technische Kontrollen um.
• Data Consumer: nutzt Meldeberichte, Modelle, Dashboards oder Nachweise und meldet Lücken sichtbar zurück.

Kritische Übergaben

Anti-Patterns

• Meldezahl ohne gemeinsame Pack-Version freigeben.
• Modellscore und Aufsichtsdefinition unter demselben Namen führen.
• DORA-Mapping nur als Namensliste ohne Service, Test und Nachweis pflegen.
• Incident nur als geschlossenes Ticket behandeln.
• Warehouse-Admin oder Tool-Admin zum fachlichen Owner machen.
• Korrekturen nach Freigabe still im Spreadsheet ändern.

Erster Umsetzungsschnitt

Starte klein, aber an einem echten Fall.

1. Wähle eine Meldezahl, ein Modell, eine ICT-Kontrolle oder einen Incident, der fachlich wichtig ist.
2. Benenne Quelle, Stichtag, Owner, Steward, Custodian und Nachweisort.
3. Prüfe, ob die technische Umsetzung zur fachlichen Freigabe passt.
4. Dokumentiere offene Lücken als Entscheidung, nicht als Kommentar im Chat.
5. Nutze den Arbeitsplan für Termine und Verantwortliche.

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

Produkte und Entscheidungen

Diese Fachbereichsseite arbeitet mit geschnittenen Produkten statt mit einem Sammeltool. Die wichtigsten Entscheidungsobjekte sind:

• Meldepaket: Zweck, Owner, Grenze, Version und Nachweis müssen erkennbar sein.
• Modelldatenvertrag: Zweck, Owner, Grenze, Version und Nachweis müssen erkennbar sein.
• ICT-Kontrollmapping: Zweck, Owner, Grenze, Version und Nachweis müssen erkennbar sein.
• Incident-Evidence: Zweck, Owner, Grenze, Version und Nachweis müssen erkennbar sein.

Die Leitfrage lautet immer: Welche Entscheidung wird dadurch belastbarer, und welcher Nachweis bleibt nach der Umsetzung sichtbar?

In der Serie weiterlesen

• Qualität regulatorischer Reports steuern