Governance für Insurance Claims & Underwriting

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-Grain

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 Ebene 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 Ebene 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, Grain und die Freigabe einer Kennzahlenänderung. Actuarial erbt nicht die bewegte OLTP-Wahrheit.

Data Steward

Underwriting Operations oder Claims Operations triagiert Grain-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 Grain (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

Symptom: Die Schadenbearbeitung bildet eine Rückstellung für einen einzelnen Deckungsbaustein. Die Versicherungsmathematik liest die Schadenquote aus dem Data Warehouse. Im Policensystem wurde der Vertrag durch einen Nachtrag geändert. Die Underwriting-Entscheidung zur Annahme des Risikos ist nur ein Häkchen ohne gespeicherten Entscheidungsstand.

Typischer Fehlstart: Claims-Dashboard kaufen und Katalog-Tag setzen, ohne Coverage-Version, ohne Entscheidungs-ID und ohne Cut-off für den aktuariellen Feed.

Vereinbarung: Richtlinie- und Coverage-Version am Schadenstag, Underwriting-Entscheidungs-ID mit Nachweis und Retention, Reserve-Historie getrennt vom Stage, Feed-Vereinbarung mit Cut-off und Mapping. CUO oder Claims verantwortliche Person kann denselben Analytics-Ask ablehnen.

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 Claims verantwortliche Person machen, weil die UI es hergibt

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
• Functions Hub — Banking & Insurance

Lege Tag 1–20 als ersten Slice in den Plan. Spätere Wochen 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 Ebene 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 Ebene 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 Ebene — Endorsements binden
• Finance-Landschaft
• KPI-Definition, Verantwortung und Versionierung

Ein Policensatz im PAS ist noch kein Vertrag. Coverage-Governance scheitert, wenn Policy, Coverage-Line und Endorsement vermischt werden und „aktueller Stand“ Historie überschreibt. Spätere Claims- und UW-Fragen haben nichts zum Joinen.

Dieser Teil definiert Grain und Versionierung für Policy/Coverage — Basis für UW-Evidence und Claims.

Vorher: Governance für Insurance Claims & Underwriting. Weiter: Underwriting-Decision-Evidence.

z im PAS ist noch kein Vertrag. Coverage-Governance scheitert, wenn Policy, Coverage-Line und Endorsement vermischt werden und „aktueller Stand“ Historie überschreibt. Spätere Claims- und UW-Fragen haben nichts zum Joinen.

Lösung: Jede materielle Police erhält vor Analytics und Claims-Anbindung eine Policy-ID und Coverage-ID mit klarem Grain, einen Version-/Endorsement-Contract mit Wirksamkeit und Vorgänger, einen Status-Contract, einen Data Owner für Produkt-/Coverage-Semantik plus Steward für Triage und eine autoritative Quelle für den wirksamen Stand.

In einem Satz: Kein Claim-Join und kein UW-Link ohne referenzierbare Coverage-Version.

Entscheidung

Jede materielle Police erhält vor Analytics und Claims-Anbindung:

1. eine Policy-ID und Coverage-ID mit klarem Grain (Header vs. Line);
2. einen Version-/Endorsement-Contract (wirksam ab/bis, Änderungsgrund, Vorgängerversion);
3. einen Status-Contract (Quote, bound, in force, cancelled, expired);
4. einen Data Owner für Produkt-/Coverage-Semantik und einen Steward für Triage;
5. eine autoritative Quelle für den wirksamen Stand (PAS vs. Warehouse).

Kein Claim-Join und kein UW-Decision-Link ohne referenzierbare Coverage-Version.

Policy-Grain-Workflow

1. Grain schneiden

Der Product-/UW-Owner legt fest, was Policy, Coverage, Insured Object und Endorsement sind. Bundles und Rider bekommen eigene Regeln, keine Betreffzeilen-Sonderfälle. Der Steward schreibt Grain und Statusmodell so, dass Claims und Actuarial darauf joinen können. Wird Grain vermischt, referenziert ein Claim eine Policenummer und trifft die falsche Coverage-Line.

2. Endorsements historisieren

Jede materielle Änderung erzeugt eine Version mit Effective Date, Änderungsgrund und Vorgänger — sie überschreibt den Stand nicht still. Der Custodian setzt die Versionierungsregel im PAS um; der Steward prüft, dass Analytics nicht nur den aktuellen Stand liest. Ohne Historie lässt sich nach einem Endorsement nicht sagen, welcher Deckungsumfang am Schadenstag galt.

3. Status und Wirksamkeit

„In force“ und „gebucht im Ledger“ bleiben getrennt — Finance folgt eigener Semantik (Finance-Landschaft). Der Owner benennt die autoritative Quelle für den wirksamen Stand (PAS vs. Warehouse). Wer Status und Buchung vermischt, erzeugt In-force-Zahlen, die weder Claims noch Actuarial reproduzieren können.

4. Controls

Blockierend: Coverage ohne Policy, Endorsement ohne Effective Date, Analytics liest nur aktuellen Stand ohne Version. Der Custodian setzt die Validierungen um; Ausnahmen trägt der Owner mit Ablauf. Warnende Controls überall und blockierende nirgends erzeugen Schatten-Coverage in Tabellen.

5. Catalog vs. Contract

Der Catalog beschreibt Tabellen und macht sie auffindbar. Der Contract entscheidet, welcher Stand Production lesen darf und wer Semantik ändert. Breaking Changes releast der Product Owner an Engineering — der Custodian ändert Coverage-Semantik nicht allein. Catalog-Glossary als Versionskontrolle ist kein Vertrag.

Handoffs

Anti-Patterns

• Nur aktuellen Coverage-Stand speichern
• Endorsement als Freitext ohne Version
• Richtlinie- und Claim-fachliche Ebene vermischen
• Catalog-Business-Glossary als Versionskontrolle
• technischer Betreiber ändert Coverage-Semantik ohne verantwortliche Person

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. Grain für ein Kernprodukt (Policy/Coverage/Endorsement) schriftlich fixieren.
2. Zehn Endorsements auf Version und Effective Date prüfen.
3. Autoritative Quelle für „in force“ benennen.
4. Einen Claim-Join auf Coverage-Version testen.

Ein „Accept“-Flag im UW-System ist noch kein Vertrag. Underwriting-Governance scheitert, wenn Entscheidung, Begründung, Referral und Modellinput nicht historisiert und aufbewahrt werden. Spätere Audit-, Klage- und Pricing-Fragen haben nichts zum Reproduzieren.

Dieser Teil bindet Decision Evidence an Policy-Grain. Abgrenzung zu gruppenweitem Model Risk: Banking Model Risk.

Vorher: Policy- und Coverage-Grain. Weiter: Claims-Lifecycle-Contracts.

zum Reproduzieren.

Lösung: Jede materielle Underwriting-Entscheidung erhält vor Bind und Reporting eine Decision-ID an Quote- oder Coverage-Version, einen Outcome-Contract mit Begründungscode, aufbewahrbare Evidence-Artefakte mit Retention-Regel, einen Data Owner für UW-Politik plus Steward für Triage und einen Authority-Weg für Overrides mit Limit und Ablauf.

In einem Satz: Kein Bind ohne nachziehbare Decision-Kette, Evidence und Retention.

Entscheidung

Jede materielle Underwriting-Entscheidung erhält vor Bind und Reporting:

1. eine Decision-ID verknüpft mit Quote/Policy-/Coverage-Version;
2. einen Outcome-Contract (accept, decline, refer, conditional) inkl. Begründungscode;
3. Evidence-Artefakte (Dokumente, Auskünfte, Modellscore-Snapshot) mit Retention-Regel;
4. einen Data Owner für UW-Politik und einen Steward für Triage;
5. einen Ausnahme-/Authority-Weg (wer override darf, Limit, Ablauf).

Kein Bind ohne nachziehbare Decision-Kette.

UW-Evidence-Workflow

1. Entscheidung schneiden

Eine Decision ist ein Ereignis, nicht nur der aktuelle Policestatus. Mehrere Entscheidungen pro Quote bleiben sichtbar — Referral, Conditional, Accept. Der UW-Owner standardisiert Outcome-Codes; der Steward hängt die Decision-ID an die Coverage-Version aus Teil 2. Fehlt das Ereignis-Grain, überschreibt der letzte Status die Kette und Audit hat nichts zum Reproduzieren.

2. Evidenz binden

Prüfbare Artefakte statt Häkchen: Dokumente, Auskünfte, Modellscore-Snapshot inklusive Inputs — nicht nur der finale Score. Der Steward führt die Evidence-Liste; Product Owner und Model Ops einigen sich auf den Snapshot-Contract. Ein Score ohne Input-Snapshot erklärt später weder Pricing-Drift noch eine Klage.

3. Retention

Der Owner setzt Aufbewahrungsfrist und Legal Hold. Records/Legal bestätigt den Pfad; der Custodian setzt Speicherort und Zugriff um — und entscheidet die Retention-Politik nicht. Evidence nur auf einem Laptop zählt als nicht aufbewahrt. Wird Retention übersprungen, ist die Decision-ID nach Fristende eine leere Referenz.

4. Controls

Blockierend: Accept ohne Decision-ID, Override ohne Authority, Evidence gelöscht vor Frist. Warnend: lange Referral-Verweildauer. Der Custodian setzt Pflichtfelder und Snapshot im UW-System; Authority-Limits setzt der Owner, nicht der Admin. Overrides, die die Originalentscheidung überschreiben, zerstören die Kette.

5. Handoff

Claims und Actuarial lesen Decision-Kontext nur über den Contract — keine stillen Nebenkopien. Der Steward liefert den Decision-Link für Coverage; Consumer joinen, sie kopieren nicht. Ohne Handoff-Contract entstehen parallele „UW-Wahrheiten“ in Workbooks, die Teil 4 und 5 nicht mehr abgleichen können.

Handoffs

Anti-Patterns

• Override überschreibt Originalentscheidung
• Nachweis nur lokal auf dem Laptop
• Score ohne Input-Snapshot
• Catalog-Beschreibung als Retention-Richtlinie
• technischer Betreiber setzt Authority-Limits fachlich fest

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. Decision-ID und Outcome-Codes für ein Produkt standardisieren.
2. Retention-Frist und Speicherort für Evidence dokumentieren.
3. Override-Pfad mit Authority und Ablauf testen.
4. Zehn gebundene Quotes auf vollständige Evidence-Kette prüfen.

Ein Claim-Status im Claims-System ist noch kein Vertrag. Claims-Governance scheitert, wenn Stage, Reserve und Payment vermischt werden und Historie fehlt. Spätere aktuarielle und Finance-Fragen haben nichts zum Joinen.

Dieser Teil definiert Stage-, Reserve- und Payment-Contracts — mit Abgrenzung zu Finance Close und Basis in Policy-Grain.

Vorher: Underwriting-Decision-Evidence. Weiter: Aktuarieller Metric-Handoff.

zum Joinen.

Lösung: Jeder materielle Schaden erhält vor Reporting und aktuariellem Feed eine Claim-ID mit klarem Grain, einen Stage-Contract mit Evidenz, einen Reserve-Contract mit Typ, Betrag und Autor, eine joinbare Payment-/Recovery-Historie sowie Data Owner und Steward plus Ausnahmeweg für Reserve-Overrides — getrennt von der Finance-Buchung.

In einem Satz: Kein Stage-Wechsel und keine Reserveänderung ohne Contract-Evidenz.

Entscheidung

Jeder materielle Schaden erhält vor Reporting und aktuariellem Feed:

1. eine Claim-ID mit Grain (Claim / Feature / Exposure klar);
2. einen Stage-Contract (Bedeutung, Evidenz, erlaubte Vorgänger);
3. einen Reserve-Contract (Typ, Betrag, Währung, Änderungsgrund, Autor);
4. eine Payment-/Recovery-Historie joinbar zur Reserve;
5. einen Data Owner und Steward plus Ausnahmeweg für Reserve-Overrides.

Kein Stage-Wechsel und keine Reserveänderung ohne Contract-Evidenz.

Claims-Lifecycle-Workflow

1. Grain und Policy-Link

Der Claims-Owner legt fest, ob Grain Claim, Feature oder Exposure ist. Der Steward bindet den Claim an die Coverage-Version aus Teil 2 — nicht an eine Policenummer im Freitext. Der Custodian setzt den Join im Claims-System. Ohne Version-Link trifft ein Schaden die falsche Deckung und Teil 3 hat keinen Decision-Kontext.

2. Stages und Evidenz

FNOL, investigate, reserve set, payment, recover, close — je Gate eine fachliche Bedeutung und ein prüfbares Artefakt. Der Owner gibt den Stage-Contract frei; der Steward pflegt Evidenzliste und erlaubte Vorgänger. Häkchen ohne Artefakt zählen nicht. Stage „closed“ ist nicht dasselbe wie „bezahlt“ — wer beides gleichsetzt, zerstört Payment- und Reserve-Semantik.

3. Reserven versionieren

Jede Reserveänderung trägt Typ, Betrag, Währung, Grund und Autor und wird historisiert. Überschreiben zerstört Triangle-Analysen. Case vs. IBNR nicht unter einem Label mischen, wenn Semantik divergiert. Der Owner bleibt für Reserve-Politik accountable; Authority für Overrides trägt Freigeber und Ablauf. Still überschriebene Reserven machen Teil 5 unvergleichbar.

4. Payments und Recoveries

Zahlungen tragen Payment-ID, Empfänger, Bezug zur Reserve und Status. Der Steward übergibt Finance den Payment-/Ledger-Handoff; die Buchung folgt eigenem Contract (Finance-Landschaft). Recoveries sind eigene Ereignisse, keine negativen Kommentare. Ein Payment ohne Claim oder ohne Reserve-Link ist ein blockierender Fehler, kein „später zuordnen“.

5. Controls und Custodian

Blockierend: Payment ohne Claim, Close ohne Reserve-Stand, Analytics ohne Historie. Der Custodian betreibt Systemcontrols und Historisierung; der Owner entscheidet Reserve-Authority nicht an den Admin ab. Catalog-Claim-Entity als Lifecycle-Contract reicht nicht — ohne Historie hat Actuarial keinen triangle-fähigen Feed.

Handoffs

Anti-Patterns

• Reserve still überschreiben
• Stage „closed“ mit „bezahlt“ gleichsetzen
• IBNR und Case Reserve ohne Flag
• Catalog-Claim-Entity als Lifecycle-Vereinbarung
• technischer Betreiber entscheidet Reserve-Authority

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. Stage-Contract für fünf kritische Gates mit Evidenz festlegen.
2. Reserve-Historie für ein Portfolio verifizieren.
3. Payment→Reserve→Claim Join end-to-end prüfen.
4. Finance- und Actuarial-Handoff-Felder mit Ownern abstimmen.

Ein Reserve-Export ist noch kein aktuarieller Vertrag. Metric-Handoffs scheitern, wenn Loss Ratio, Ultimate oder Triangle-Input still umgeschnitten werden, während Dashboards denselben Namen behalten. Spätere Pricing- und Solvency-Fragen haben nichts zum Vergleichen.

Dieser Teil bindet den Handoff von Claims-Lifecycle und Policy-Feeds an Actuarial — verwandt zu KPI-Definition und abgegrenzt von Banking Model Risk.

Vorher: Claims-Lifecycle-Contracts. Serie startet bei Governance für Insurance Claims & Underwriting.

zum Vergleichen.

Lösung: Jeder materielle aktuarielle Feed erhält vor Production-Metriken eine Feed- und Metric-ID mit Zweck und Grain, einen Cut-off- und Snapshot-Contract, eine Mapping-Tabelle von operativen Feldern auf aktuarielle Semantik, einen Data Owner (Actuarial/Product) plus Steward für Triage und einen Change-Prozess, der Redefinition versioniert und Consumer benachrichtigt.

In einem Satz: Keine Production-Kennzahl ohne versionierten Handoff-Contract, Cut-off und Mapping.

Entscheidung

Jeder materielle aktuarielle Feed erhält vor Production-Metriken:

1. eine Feed- und Metric-ID mit Zweck und Grain (Accident/Report/Policy Year klar);
2. einen Cut-off- und Snapshot-Contract (as-of, Währung, Population);
3. eine Mapping-Tabelle operativer Felder → aktuarielle Semantik (keine stillen Alias);
4. einen Data Owner (Actuarial/Product) und Steward für Triage;
5. einen Change-Prozess, der Redefinition versioniert und Consumer benachrichtigt.

Keine Kennzahl darf denselben Namen behalten, wenn Grain oder Methode bricht.

Actuarial-Handoff-Workflow

1. Consumer und Zweck

Der Actuarial Owner benennt die Entscheidung: Pricing, Reserving oder Experience Study. Ohne Zweck gibt es keinen „Standard-Export“. Der Steward nimmt den Zweck in Feed- und Metric-ID auf. Ein Feed für alle Zwecke erzeugt stille Doppelbedeutungen, die Finance und Risk später nicht mehr trennen.

2. Snapshot statt Live-Join

Actuarial liest freigegebene as-of-Stände — Cut-off, Währung, Population — nicht die sich bewegende Claims-OLTP-Wahrheit. Der Custodian betreibt den Snapshot-Job; der Steward vergleicht einmal Live gegen Snapshot, bevor der Feed zertifiziert. Live-Claims-Tabellen als Triangle-Quelle machen Ultimate und Loss Ratio unvergleichbar zwischen zwei Läufen.

3. Semantik mappein

„Paid“ operativ vs. aktuariell, Partial Payments, Recoveries: der Steward dokumentiert die Mapping-Tabelle, der Product Owner releast Änderungen. Mapping nur in einem Analysten-Notebook ist kein Contract. Wird Mapping übersprungen, behält die Kennzahl den Namen und wechselt das Grain.

4. Controls

Blockierend: Metric ohne Version, Feed ohne Cut-off, Umbenennung ohne Change-Record. Catalog-Update oder Tag „actuarial approved“ allein ist kein Handoff. Der Custodian setzt Snapshot und Access um; aktuarielle Semantik entscheidet der Owner, nicht die Platform. Consumer sehen die Version — sonst merken sie die Redefinition erst im Board.

5. Dual use verhindern

Finance- und Regulatory-Kennzahlen brauchen eigene Contracts — siehe Banking- und Finance-Serien — keine stillen Doppelbedeutungen unter demselben KPI-Namen. Der Owner grenzt parallele Kennzahlen schriftlich ab. Wer Loss Ratio intern und für Solvency gleich nennt, obwohl Grain bricht, hat den Handoff umgangen.

Handoffs

Anti-Patterns

• Denselben KPI-Namen bei geändertem fachliche Ebene behalten
• Live-Claims-Tabellen als Triangle-Quelle
• Mapping nur in einem Analysten-Notebook
• Catalog-Tag „actuarial approved“ ohne Vereinbarung
• technischer Betreiber entscheidet aktuarielle 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. Drei Kernmetriken auf Metric-ID, Grain und Cut-off dokumentieren.
2. Ein as-of-Snapshot für ein Portfolio erzeugen und mit Live vergleichen.
3. Mapping Paid/Reserve/Recovery schriftlich freigeben.
4. Change-Request für eine Umdefinition mit Versionstest fahren.

Weiterlesen

• Banking- und Insurance-Landschaft
• Metrics Foundations