Governance für Insurance Claims & Underwriting — getrennt von Banking-Landscape

Was diese Landschaft besonders macht

Versicherungsdaten wechseln zwischen Police, Deckung, Risikobeurteilung und Schadenfall. Eine neue Vertragsversion kann zum Schadenzeitpunkt andere Bedingungen haben als heute. Reserve, Zahlung und Schadenabschluss sind ebenfalls unterschiedliche Größen. Modell- und Sachentscheidungen benötigen einen nachvollziehbaren damaligen Datenstand.

• Deckung und Vertragsversion zum Ereigniszeitpunkt rekonstruieren.
• Reserve, Zahlung und Wiedereröffnung getrennt auswerten.
• Modellvorschlag und menschliche Entscheidung unterscheidbar halten.

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:

• Detailebene von Police und Deckung — Vertragsänderungen nachvollziehen
• Underwriting-Decision-Evidence — Entscheidung und Retention
• Claims-Lifecycle-Contracts — Stages, Reserves, Payments
• Aktuarieller Metric-Handoff — ohne stille Redefinition

Wenn du nur fünf Minuten hast

1. Starte mit Policy/Coverage-Version, Underwriting Decision, Claim Stage, Reserve oder Actuarial Handoff.
2. Trenne Policy Header, Coverage Line, Endorsement und aktuellen PAS-Stand.
3. Mache Underwriting-Entscheidungen als Evidence sichtbar, nicht nur als Accept-Flag.
4. Trenne Claim Stage, Reserve, Payment und Recovery.
5. Übergib an Actuarial nur mit Cut-off, Population, Bezugs- und Detailebene und Mapping.

Typische Fragen sind:

• Welche Richtlinie-Version und welche Coverage-Line sind autoritativ, nachdem ein Endorsement wirksam wurde?
• Welche Evidenz trägt eine Underwriting-Entscheidung — Referral, Begründung, Modellinput?
• Wann wechselt ein Claim den Stage, und welche Reserve darf Analytics lesen?
• Welcher Cut-off und welches fachliche Zählebene gehen an Actuarial?
• Wer darf Coverage, Override oder Loss Ratio umschneiden — und wer darf ablehnen?

Wenn Policy-Version, Decision-ID und Reserve-Historie denselben Identifier nicht teilen, setzt Claims eine Reserve, Actuarial liest eine andere Loss Ratio, und das PAS zeigt den „aktuellen Stand“. Das Problem ist nicht das Dashboard. Es ist der fehlende Vertrag zwischen Coverage, Entscheidung, Schaden und Nachweis.

Gute Claims- und Underwriting-Governance macht operative Produktwahrheit ausführbar — Coverage-Version, Entscheidungsnachweis und Reserve am selben Identifier, nicht am neuesten Meldepack.

Die Serie Governance für Insurance Claims & Underwriting gibt dir den Einstieg und den roten Faden für die folgenden Teile. Sie ist die operative Nachbarschaft zur Banking-/Insurance-Landschaft, nicht deren Fortsetzung.

Ausgangslage

Claims setzt eine Case-Reserve auf eine Coverage-Line. Zwei Wochen später liest Actuarial die Loss Ratio aus dem Warehouse — dieselbe Policenummer, anderer Stand: das PAS hat per Endorsement Deckung geändert, und die Underwriting-Entscheidung zum Bind liegt nur als Accept-Flag ohne Snapshot. Regulatory Reporting will denselben Claim als Critical Data Element im Meldepack. Teams kaufen dann ein Claims-Dashboard oder taggen den Katalog — und der nächste Triangle-Feed mischt Case-Reserve und IBNR.

Was diese Serie klärt

• Orientierung: Richtlinie-fachliche Zählebene, Underwriting-Nachweis, Claims-Lifecycle, aktuarieller Handoff — getrennt von DORA und Meldepack (diese Seite)
• Vertiefung: Richtlinie- und Coverage-fachliche Zählebene — Endorsements binden
• Vertiefung: Underwriting-Decision-Nachweis — Entscheidung und Retention
• Vertiefung: Claims-Lifecycle-Vereinbarungen — Stages, Reserves, Payments
• Abschluss: Aktuarieller Metric-Handoff — ohne stille Redefinition

Begriffe vor dem Lesen

• Richtlinie / Coverage / Endorsement — fachliche Zählebene der Deckung: Header, Line und wirksame Änderung mit Datum; „aktueller Stand“ im Policensystem ist keine Historie.
• Underwriting Decision Nachweis — Entscheidungs-ID mit Outcome (accept, decline, refer, conditional), Begründung, Modellinput-Snapshot und Retention; ein Accept-Flag allein ist keine Entscheidung.
• Claims Lifecycle — Stage, Reserve und Payment sind drei Verträge. FNOL, Investigate, Reserve-Set, Payment, Recovery und Close brauchen Historie; Stage ist nicht die Reserve.
• Actuarial Metric Handoff — freigegebener Feed mit Cut-off, Grundgesamtheit und fachliche Zählebene (Accident-, Report- oder Richtlinie-Year) plus Mapping; Loss Ratio darf den Namen nicht behalten, wenn die Methode bricht.
• Policensystem — Richtlinie Administration System, operative Quelle für Richtlinie und Coverage. Der Policensystem-Admin ist technischer Betreiber, nicht CUO.
• CUO / verantwortliche Person für Schadenprozesse / Actuary — Chief Underwriting Officer trägt Deckungspolitik; verantwortliche Person für Schadenprozesse (Head of Claims) trägt Stage- und Reserve-Politik; Appointed Actuary oder Head of Actuarial trägt den Feed-Vertrag.

Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt Policenummern, System- und Toolnamen durch eure PAS-, Claims-, Catalog- und Prozessquellen.

Fachlicher Zusammenhang: Verantwortung klärt, wer die Aussage entscheidet; Kennzahlen-Governance beschreibt ihre Bedeutung; Datenqualität prüft die benötigte Datengrundlage. Das Governance-Konzept verbindet diese Aufgaben zu einem gemeinsamen Arbeitsweg.

Entscheidung: Policy-Bezugs- und Detailebene, Underwriting-Decision-Evidence, Claims-Lifecycle und aktuariellen Metric-Handoff als Produkte mit Owner führen. CUO und Claims Owner entscheiden Semantik und Ablehnung; der Actuary trägt den Feed-Vertrag; PAS- und Claims-Admin setzen um.

Merksatz: Coverage-Version, Entscheidungsnachweis und Reserve-Historie binden, bevor das nächste Claims-Reporting oder der nächste Triangle-Feed die operative Wahrheit entscheidet.

Erster Umsetzungsschnitt

1. Policy/Coverage-Version, Underwriting Decision, Claim Stage oder Actuarial Feed auswählen.
2. Policy Header, Coverage Line, Endorsement und PAS-Stand trennen.
3. Underwriting-Entscheidung mit Snapshot und Begründung dokumentieren.
4. Claim Stage, Reserve, Payment und Recovery historisieren.
5. Actuarial Handoff mit Cut-off, Population und Mapping übergeben.

Produkte und Entscheidungen

Insurance braucht nicht „eine Claims-Plattform“, sondern geschnittene Produkte. DORA-Services und Aufsichtsformulare gehören in die Banking-/Insurance-Landschaft.

Policy- und Coverage-Bezugs- und Detailebene

Dieses Produkt beschreibt:

• Richtlinie-ID und Coverage-ID; Header versus Line; Endorsement mit wirksam ab/bis; Status (Quote, bound, in force, cancelled, expired); autoritative Quelle (Policensystem versus Warehouse); Review-Datum.

Entscheidungen:

• Welche Version gilt, wenn Policensystem und Warehouse widersprechen?; Wann erzeugt ein Endorsement eine neue Coverage-Version statt eines stillen Overwrites?; Wer darf Deckungsumfang ändern — CUO oder Produkt, nicht der Policensystem-Admin?

Underwriting-Decision-Evidence

Die Underwriting-Entscheidung ist ein Ereignis, nicht der aktuelle Policestatus.

Sie benötigt:

• Entscheidungs-ID verknüpft mit Quote- oder Coverage-Version; Outcome-Vereinbarung; Begründungscode; Nachweis-Artefakte (Dokumente, Auskünfte, Modellscore-Snapshot); Retention und Legal Hold; Ausnahme- und Authority-Weg.

Entscheidungen:

• Was zählt als bindfähige Entscheidung — Accept-Flag oder nachziehbare Kette?; Wer darf referieren oder overriden, mit welchem Limit und Ablauf?; Welche Modellinputs müssen gesnapshottet werden, bevor Bind und Reporting laufen?

Claims-Lifecycle

Stage, Reserve und Payment sind nicht derselbe Satz.

Es benötigt:

• Claim-ID mit fachlicher Ebene (Claim, Feature, Exposure); Link auf die Coverage-Version, nicht nur die Policenummer im Freitext; Stage-Vereinbarung mit erlaubten Vorgängern; Reserve-Vereinbarung (Typ, Betrag, Währung, Änderungsgrund, Autor); Payment- und Recovery-Historie.

Entscheidungen:

• Welches fachliche Zählebene trägt die Schadenaussage?; Wann darf Analytics welche Reserve lesen?; Wer gibt Reserve-Overrides frei, und wie bleibt Case versus IBNR getrennt?

Aktuarieller Metric-Handoff

Actuarial erbt nicht die bewegte Claims-OLTP-Wahrheit. Der Feed braucht einen eigenen Vertrag.

Entscheidungen:

• Welcher Zweck gilt — Pricing, Reserving oder Experience Study?; Welcher Cut-off, welches fachliche Zählebene und welche Grundgesamtheit speisen die Kennzahl?; Wer darf Loss Ratio, Ultimate oder Triangle-Input umlabeln, und welcher Change benachrichtigt Nutzer?

Wo Governance hängt

Zwischen Policy-Header und Coverage-Line

Ein Policensatz im PAS ist noch kein Vertrag. Ohne Endorsement-Historie joinen Claim und Underwriting auf den falschen Stand.

Zwischen Accept-Flag und Decision Evidence

Ein Accept ohne Decision-ID, Begründung und Modell-Snapshot ist Theater. Audit, Klage und Pricing haben nichts zum Reproduzieren.

Zwischen Claim-Stage und Reserve

„In Bearbeitung“ ist keine Reserve. Wer Stage und Betrag in einem Feld mischt, zerstört Triangle und Payment-Anschluss.

Zwischen Claims-Feed und aktuarieller Kennzahl

Ein Reserve-Export ohne Cut-off und Mapping ist kein Handoff. Dieselbe Überschrift „Loss Ratio“ mit gebrochener Methode ist eine stille Redefinition.

Zwischen PAS-/Claims-Admin und CUO / Claims Owner

Wer im System Status oder Gruppe setzen kann, entscheidet damit nicht Deckungspolitik, Reserve-Politik oder Feed-Semantik.

Zwischen dieser Serie und dem Meldepack

Regulatory Report Pack, DORA und gruppenweites Model Risk sind die Banking-Karte. Claims-Operating hierher zu ziehen oder Meldezahlen hier zu schneiden vermischt zwei Betriebsgrenzen.

Rollen-Mapping

Data Owner (Underwriting)

CUO, Head of Underwriting oder benannter Product Owner ist accountable für Coverage-Semantik, Bind-Politik, Referral- und Override-Authority. Der Owner entscheidet nicht die Warehouse-Modellierung.

Data Owner (Claims)

Head of Claims oder Claims Director ist accountable für Stage-Modell, Reserve-Politik, Payment-Anschluss und den Fraud- oder SIU-Pfad. Claims erbt nicht still die Finance-Buchung.

Data Owner (Actuarial)

Appointed Actuary oder Head of Actuarial ist accountable für Feed-Zweck, Cut-off, Bezugs- und Detailebene und die Freigabe einer Kennzahlenänderung. Actuarial erbt nicht die bewegte OLTP-Wahrheit.

Data Steward

Underwriting Operations oder Claims Operations triagiert Bezugs- und Detailebene-Konflikte, Evidence-Lücken und Feed-Wünsche, pflegt Identifier-Listen und eskaliert widersprüchliche PAS- und Claims-Stände.

Data Product Owner

Priorisiert Policy-Produkt, Decision-Evidence und Claims-Lifecycle. Nutzen und Lieferbarkeit — nicht die Zeichnungspolitik und nicht die Reserve-Höhe.

Data Architect

Schützt Bezugs- und Detailebene (Policy ≠ Coverage ≠ Claim ≠ Reserve ≠ Triangle), Lineage zum Endorsement und Breaking Changes an PAS-, Claims- und Actuarial-Schnittstellen.

Data Custodian

PAS-Admin, Claims-System-Admin und Plattform setzen Versionierung, Pflichtfelder, Job-Pausen und Snapshots um. Konfigurationsmacht ist keine fachliche Autorität.

Data Consumer

Pricing, Reserving, Finance, SIU, Regulatory Reporting (nur über die Banking-Serie), Analytics (nur mit Zweck). Abweichungen laufen über denselben Intake — keine stillen Spreadsheet-Triangles.

Hilfskarte — wen zuerst fragen

Das Rollen-Mapping sagt, wer entscheidet. Die Hilfskarte sagt, wen man zuerst fragt, damit die Entscheidung nicht leer ist. Hüte: Wer hilft wem an der Quelle.

Zum Owner nur bei Definitions- oder Risiko-Streit. Schema- und Join-Fragen bleiben bei Expert oder Custodian. Achtundvierzig Stunden Antwort — nicht stilles Slack.

Mini-Fall

Alltagssituation: Die Schadenbearbeitung bildet eine Rückstellung für einen einzelnen Deckungsbaustein. Die Versicherungsmathematik nutzt eine Schadenquote aus dem Data Warehouse. Im Policensystem wurde der Vertrag durch einen Nachtrag geändert, und die Underwriting-Entscheidung zur Annahme des Risikos ist nur als Häkchen gespeichert.

Was schiefläuft: Schaden, Deckung, Nachtrag und aktuarieller Feed beziehen sich auf unterschiedliche Zeitstände. Ohne gespeicherte Entscheidungs-ID und gültige Coverage-Version kann niemand erklären, welche Vertragslage für welche Kennzahl galt.

Vereinbarung: Police und Deckung bekommen eine Version am Schadenstag. Die Underwriting-Entscheidung wird mit ID, Nachweis und Aufbewahrung gespeichert. Reserve-Historie, Bearbeitungsstatus und aktuarieller Feed bleiben getrennt und werden über Cut-off und Mapping zusammengeführt.

Kritische Übergaben

Anti-Patterns

• Banking-Meldepack oder DORA-Service als Ersatz für Richtlinie- und Claims-Verträge nutzen
• Endorsement überschreibt Historie, Analytics liest nur den aktuellen Policensystem-Stand
• Accept-Flag ohne Entscheidungs-ID, Begründung und Modell-Snapshot als Bind behandeln
• Claim-Stage still mit Reserve oder Payment gleichsetzen
• Loss Ratio oder Triangle-Input umlabeln, ohne Feed-Version und Nutzer-Hinweis
• Policensystem- oder Claims-Admin zum CUO oder verantwortliche Person für Schadenprozesse machen, weil die UI es hergibt

Umsetzung im Alltag

Wähle einen begrenzten betrieblichen Fall, an dem sich die beschriebene Entscheidung und ihre Umsetzung gemeinsam prüfen lassen.

• Arbeitsplan — Extended Domain Landscapes
• Lernpfad — Extended Domain Landscapes
• Functions Hub — Banking & Insurance

Lege Tag 1–20 als ersten Slice in den Plan. Spätere Arbeiten bleiben in derselben Instanz. Erster Kontakt für Hüte: Wer hilft wem an der Quelle.

Schritt 1: Rahmen und Entscheidung klären

Einen jüngsten Schaden wählen, der auf eine geänderte Coverage zeigt. Policy-ID, Endorsement, Decision-ID, Reserve-Stand und bestehenden Actuarial-Export aufnehmen. Vier Produkte schneiden. CUO, Claims Owner und Actuary benennen. Die Abgrenzung zum Meldepack in einem Absatz festhalten.

Schritt 2: Control und Nachweis umsetzen

Coverage-Version für ein Produkt produktiv schalten. Eine Underwriting-Entscheidung mit Snapshot und Retention führen. Reserve-Historie an einem Claim erzwingen. Negativtest: Analytics darf nicht nur den aktuellen PAS-Stand ohne Version lesen.

Schritt 3: Testen und Ausnahmen sichtbar machen

Coverage-Version und Decision-ID am Schadenstag rekonstruieren. Einen aktuariellen Feed mit Cut-off und Mapping freigeben. Eine stille Loss-Ratio-Umlabelung ablehnen und den Change versionieren.

Schritt 4: Messen und begrenzt ausrollen

Aufwand und Lücken messen. Nur bestandene Muster (Coverage-Version, Decision Evidence, Reserve-Historie, Feed-Contract) auf eine zweite Produktlinie übertragen.

Exit-Kriterien

• Richtlinie- und Coverage-fachliche Zählebene nennen Version, Endorsement und autoritative Quelle.
• CUO, Claims Owner und Actuary sind benannt; Policensystem-/Claims-Admin ist technischer Betreiber.
• Underwriting-Entscheidung hat Entscheidungs-ID, Nachweis und Retention.
• Claim trägt Stage-, Reserve- und Payment-Vertrag, joinbar auf die Coverage-Version.
• Aktuarieller Feed hat Cut-off, fachliche Zählebene und Mapping; stille Redefinition ist ein Change.
• Die Abgrenzung zur Banking-/Insurance-Landschaft ist schriftlich; Meldepack und DORA liegen dort.

Weiterlesen

• Governance in Banking und Insurance — DORA, Meldepack, Model Risk; nicht diese Karte
• Richtlinie- und Coverage-fachliche Zählebene — Endorsements binden
• Finance-Landschaft
• KPI-Definition, Verantwortung und Versionierung

In der Serie weiterlesen

• Detailebene von Police und Deckung — Vertragsänderungen nachvollziehen