+150 XP

Die Datenlandschaft der Versicherung end to end abbilden

# Die Datenlandschaft der Versicherung end to end abbilden

Ein einzelner Kfz-Schaden kann elf verschiedene Systeme durchlaufen, bevor eine Zahlung angewiesen wird: das Policenverwaltungssystem, ein Telematik-Feed vom Smartphone des Fahrers, die Kalkulationsplattform einer Werkstatt, eine API für Polizeiberichte, eine Abfrage bei einer Kreditauskunftei und die Vertragsdatei eines Rückversicherers, unter anderem. Keines dieser Systeme wurde dafür gebaut, mit den anderen zu sprechen. Ihre Aufgabe, wenn Sie mit diesen Daten Entscheidungen treffen müssen, besteht darin zu wissen, welches System die Wahrheit sagt.

Diese Lektion geht die Daten end to end durch: wo sie entstehen, wie sie konsolidiert werden und welche Metriken Ihnen sagen, ob Sie ihnen vertrauen können.

Die zentralen Datenquellen

Das Warehouse jedes Versicherers ist aus einer Handvoll wiederkehrender Quellentypen aufgebaut. Wenn Sie diese kennen, können Sie das Datenarchitektur-Diagramm jedes Versicherers lesen.

Policenverwaltungssysteme (PAS). Das System of Record für das, was verkauft wurde: Deckungssummen, Prämien, Nachträge, Wirksamkeitsdaten. Beispiele für Anbieter: Guidewire, Duck Creek, Sapiens. Das ist üblicherweise der „Golden Record“ (die einzige maßgebliche Version eines Datenfelds, die genutzt wird, wenn mehrere Systeme sich widersprechen) für Policenbedingungen.

Schadenmanagementsysteme. Verfolgen einen Schaden von der ersten Schadenmeldung (First Notice of Loss, FNOL) bis zur Regulierung. Guidewire ClaimCenter und Duck Creek Claims dominieren den US-Markt. Schadendaten sind der Golden Record für Schadenhöhen, Reserven und Regulierungsdaten, auch wenn Policendaten in sie einfließen.

Billing- und Prämienbuchhaltungssysteme. Verfolgen, was tatsächlich in Rechnung gestellt und eingezogen wurde, was häufig von dem abweicht, was laut Police fällig war, wegen Änderungen während der Laufzeit, Kündigungen oder Zahlungsfristen.

Rückversicherungssysteme. Verfolgen das zedierte Geschäft, also den Anteil des Risikos, den ein Versicherer an einen Rückversicherer (ein Unternehmen, das Versicherer versichert) wie Munich Re oder Swiss Re weitergibt. Diese Systeme besitzen den Golden Record für Vertragsbedingungen und Recoverables (Beträge, die dem Zedenten zurückstehen).

Daten von Drittanbietern und Auskunfteien. Externe Anreicherungsquellen: Kreditauskunfteien (Equifax, TransUnion), Fahrzeug- und Führerscheinregister, CLUE-Berichte (Comprehensive Loss Underwriting Exchange, eine US-Datenbank zur Schadenhistorie, betrieben von LexisNexis) sowie Katastrophenmodelle von Anbietern wie Verisk oder Moody's RMS. Keine davon ist ein Golden Record für interne Felder, aber sie sind oft der *einzige* Nachweis für externe Risikofakten, etwa einen früheren, nicht offengelegten Schaden.

Telematik- und IoT-Daten. Usage-Based-Insurance-Programme (UBI) wie Progressives Snapshot oder State Farms Drive Safe & Save erzeugen Rohdatenströme zum Fahrverhalten (Bremsen, Geschwindigkeit, Kilometerleistung), die vor dem Eingang ins Warehouse zu Risikoscores aggregiert werden.

Vertriebs- und CRM-Daten. Makler- und Agentenportale, Angebotsrechner und Callcenter-Logs. Oft die unsauberste Quelle, weil die Erfassungsqualität je nach Intermediär schwankt.

Regulatorische Datenebenen, die man kennen sollte

In den USA erzwingen die aufsichtsrechtlichen Meldungen der NAIC (National Association of Insurance Commissioners) eine standardisierte Berichterstattung zu Schadenreserven und Prämien. Deshalb pflegen US-Versicherer einen parallelen „Statutory Data Mart“, getrennt von den Daten für ihre GAAP-Berichterstattung (Generally Accepted Accounting Principles).

In Europa verlangt Solvency II (die risikobasierte Solvenzregulierung der EU, in Kraft seit 2016) eine granulare Dokumentation der Data Lineage für alles, was in Kapitalberechnungen einfließt. Deshalb investieren europäische Versicherer stark in Data-Governance-Tooling speziell für das regulatorische Reporting, überwacht von der EIOPA (European Insurance and Occupational Pensions Authority).

Wer besitzt den Golden Record?

Das ist die nützlichste Fähigkeit in dieser Lektion: für jedes einzelne Feld zu wissen, welches System maßgeblich ist.

| Feld | Golden-Record-Eigentümer | Warum |

|---|---|---|

| Deckungssumme | Policenverwaltungssystem | Es ist der Vertrag |

| Höhe der Schadenreserve | Schadensystem | Sachbearbeiter aktualisieren sie live |

| Kundenadresse | Meist CRM, manchmal PAS | Hängt vom MDM-Setup des Versicherers ab |

| Frühere Schadenhistorie | Auskunftei (CLUE) | Interne Systeme sehen nur die eigene Historie |

| Zedierte Schadenhöhe | Rückversicherungssystem | Dort liegen die Vertragsbedingungen |

| Kreditbasierter Versicherungsscore | Feed der Kreditauskunftei | Extern berechnet, read-only eingelesen |

Wenn zwei Systeme sich widersprechen, ist diese Tabelle Ihr erster Schritt beim Troubleshooting. Eine Abweichung zwischen der Prämie im PAS und der Prämie im Billing-System ist nicht zwangsläufig ein Fehler; es kann bedeuten, dass ein Nachtrag während der Laufzeit noch nicht synchronisiert wurde.

Wie konsolidiert wird: die Pipeline

Die meisten großen Versicherer betreiben inzwischen eine Variante dieses Ablaufs:

Source systems (PAS, Claims, Billing, Reinsurance, Bureau feeds)
        ↓ (batch ETL or streaming CDC)
Data lake / landing zone (raw, schema-on-read)
        ↓ (transformation, validation rules)
Enterprise data warehouse (conformed, modeled)
        ↓
Master Data Management (MDM) layer resolves entity conflicts
        ↓
Reporting marts (actuarial, finance, regulatory) + ML feature stores

CDC (Change Data Capture) ersetzt zunehmend das nächtliche Batch-ETL (Extract, Transform, Load), weil Schadensachbearbeiter und Underwriter heute Sichtbarkeit nahezu in Echtzeit erwarten. Eine einfache Validierungsregel, die in der Landing-Zone-Stufe läuft, könnte so aussehen:

sql
-- Markiert Schäden, bei denen der gezahlte Betrag die Deckungssumme übersteigt (ein häufiger Datenqualitäts-Check)
SELECT claim_id, policy_id, paid_amount, coverage_limit
FROM claims_landing c
JOIN policy_snapshot p ON c.policy_id = p.policy_id
WHERE c.paid_amount > p.coverage_limit
  AND c.paid_amount IS NOT NULL;

Solche Regeln fangen Integrationsfehler ab (ein Schaden, der mit der falschen Policenversion verknüpft ist), bevor sie die nachgelagerte Reservierung verderben.

Wissenscheck

1. Wenn Policenverwaltungsdaten und Schadenmanagementdaten sich über die Deckungssumme eines offenen Schadens widersprechen, welcher Wert sollte generell als maßgeblich gelten und warum?

2. Warum können Billing- und Prämienbuchhaltungsdaten von dem abweichen, was das Policenverwaltungssystem als fällig ausweist?

3. Was ist der Hauptgrund dafür, dass ein einzelner Kfz-Schaden Systeme wie Telematik-Feeds, Kalkulationsplattformen von Werkstätten und APIs für Polizeiberichte durchläuft, von denen keines für Interoperabilität gebaut wurde?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE richtigen Antworten dazu, welche Systeme in der Datenlandschaft der Versicherung als „Golden Record“ für bestimmte Datenarten dienen.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE richtigen Antworten dazu, warum das Verständnis wiederkehrender Quellsystemtypen für jemanden wichtig ist, der mit Versicherungsdaten Entscheidungen trifft.

Wählen Sie alle richtigen Antworten aus.

Datenqualitätsmetriken, die zählen

Generische Datenqualitäts-Frameworks (Vollständigkeit, Genauigkeit, Aktualität, Konsistenz) gelten auch hier, aber die Versicherung gibt ihnen scharfe, messbare Zähne.

Completeness Rate: Anteil der befüllten Pflichtfelder. Ein üblicher Zielwert für kritische Schadenfelder (Schadendatum, Schadenursache) liegt über 98 Prozent; darunter beginnen aktuarielle Reservierungsmodelle, unzuverlässige Ergebnisse zu liefern.

Match Rate in der Entity Resolution: Wenn MDM versucht, „John A. Smith“ über CRM, PAS und einen Auskunftei-Feed hinweg zu verknüpfen, verfolgen Versicherer typischerweise, welcher Anteil automatisch aufgelöst wird und welcher eine manuelle Prüfung braucht. Praktiker nennen häufig automatisierte Match Rates im Bereich von 80 bis 95 Prozent als gesund, allerdings variiert das enorm je Versicherer und ist kein allgemeiner Benchmark; behandeln Sie jede konkrete Zahl als Schätzung.

Lag Time / Latenz: wie lange es dauert, bis ein Ereignis (eine Schadenzahlung) im Warehouse erscheint. Regulatorisches Reporting unter Solvency II oder die NAIC-Statutory-Statements verlangen typischerweise monatliche oder quartalsweise Finalität, die interne Reservierung will aber zunehmend tägliche oder nahezu Echtzeit-Feeds.

Reconciliation Break Rate: der Anteil der Datensätze, die zwischen zwei Systemen, die übereinstimmen sollten, nicht abgestimmt werden können, zum Beispiel im PAS gebuchte Prämie gegen im Hauptbuch erfasste Prämie. Finance- und Aktuariatsteams verfolgen das monatlich; eine steigende Break Rate ist ein Frühwarnsignal für ein Integrationsproblem.

Lineage Coverage: der Anteil der meldepflichtigen Felder mit dokumentierter, prüfbarer Lineage zurück zur Quelle. Solvency-II-Prüfer in Europa testen das gezielt während der Modellvalidierung.

Ein einfaches Rechenbeispiel: Wenn ein Versicherer 500.000 Schäden pro Jahr bearbeitet und die Vollständigkeitsprüfung bei 9.500 einen fehlenden Pflichtcode „Schadenursache“ findet, ergibt sich die Completeness Rate = (500.000, 9.500) / 500.000 = 98,1 Prozent. Das liegt genau an der üblichen internen Schwelle, also eher ein Fall für das Data-Governance-Komitee als für Ignorieren.

Governance-Strukturen hinter den Metriken

Die meisten Versicherer formalisieren das über einen Data Governance Council, in dem typischerweise ein Chief Data Officer mit Verantwortlichen aus Aktuariat, Compliance und IT zusammensitzt, sowie über ein Data-Stewardship-Modell, in dem benannte Business Owner (nicht die IT) für bestimmte Domänen verantwortlich sind, etwa „Claims Data Steward“ oder „Policy Data Steward“. Das ist Standardpraxis bei großen Versicherern und wird zunehmend Pflicht statt Option, angesichts der Dokumentationsanforderungen von Solvency II in Europa und der verschärften NAIC-Erwartungen an Modellgovernance in den USA nach dem Wachstum KI-basierter Underwriting-Tools.

Einen praktischen Einstieg in Datenqualitätsdimensionen, die branchenübergreifend gelten, bietet die Übersicht zum DAMA-DMBOK-Framework, ein breit referenzierter Standard im Datenmanagement.

How Insurance Companies Use Data

Watch on YouTube

Wichtigste Erkenntnisse

  • Versicherungsdaten kommen aus strukturell unterschiedlichen Quellen (Policenverwaltung, Schaden, Rückversicherung, Auskunfteien, Telematik), jede mit eigenem Golden Record; Widersprüche zwischen Systemen sind oft Timing-Fragen, keine Fehler.
  • Machen Sie es sich zur Gewohnheit, vor dem Troubleshooting jeder Datenabweichung zu fragen: „Welches System besitzt dieses Feld?“ Das ist die schnellste Diagnose-Abkürzung der Branche.
  • Operativ wichtigste Datenqualitätsmetriken: Completeness Rate, Match Rate der Entity Resolution, Latenz und Reconciliation Break Rate; verfolgen Sie diese monatlich, nicht jährlich.
  • Regulatorische Frameworks (NAIC in den USA, Solvency II und EIOPA in Europa) schreiben zunehmend dokumentierte Data Lineage vor, was Governance von einem Nice-to-have in eine Prüfungsanforderung verwandelt.
  • Behandeln Sie jeden konkreten Benchmark-Prozentsatz als Schätzung, solange er nicht von einem benannten Regulator oder einer Studie stammt; interne Schwellen variieren stark je Versicherer und Geschäftsbereich.