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 APIAPIApplication Programming Interface: eine standardisierte Schnittstelle, über die Anwendungen kommunizieren und Daten austauschen, ohne die interne Funktionsweise der jeweils anderen zu kennen.Vollständige Definition ansehen → 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 kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →ö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 mamaEinsatz von Software, um wiederkehrende Marketingaufgaben und Kampagnen zu automatisieren und Personalisierung in großem Maßstab über Kanäle wie E-Mail, Web und Social zu ermöglichen.Vollständige Definition ansehen →ß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 GAAPGAAPDer standardisierte Satz von Rechnungslegungsregeln für konsistente, vergleichbare Abschlüsse, dominant im US-Reporting.Vollständige Definition ansehen →-Berichterstattung (Generally Accepted Accounting Principles).

In Europa verlangt Solvency II (die risikobasierte Solvenzregulierung der EU, in Kraft seit 2016) eine granulare Dokumentation der Data LineageData LineageData Lineage zeigt, wie Daten sich durch Systeme bewegen und dabei transformiert werden, von der Quelle bis zur Nutzung: woher sie kommen, was sie verändert hat und wohin sie gehen.Vollständige Definition ansehen → 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.

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 PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen →

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:

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

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.

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.