+150 XP

Data lineage und Governance für das regulatorische Reporting

# Data lineage und Governance für das regulatorische Reporting

In Zelle D47 eines Solvency-II-QRT-Templates steht eine Zahl: „Best Estimate Liabilities, Line of Business 12, EUR 340.662.000“. Ein Prüfer fragt: Woher kommt diese Zahl? Wenn niemand im Raum sie Schritt für Schritt bis zu einem Vertragsdatensatz im Quellsystem zurückverfolgen kann, hat diese Meldung eine Lineage-Lücke. Lineage-Lücken sind laut den Aufsichtsberichten der EIOPA (European Insurance and Occupational Pensions Authority) und den Prüfungen auf Ebene der US-Bundesstaaten nach NAIC-Standards (National Association of Insurance Commissioners) durchgängig der häufigste Prüfungsbefund bei europäischen und US-amerikanischen Versicherern. In dieser Lektion geht es darum, diese Lücke zu schließen: was Lineage ist, wie man sie aufbaut und wie man messen kann, ob die Governance tatsächlich funktioniert.

Was „Lineage“ in der Praxis bedeutet

Data lineage ist der dokumentierte, nachvollziehbare Weg, den ein Datenelement von seinem Ursprung (einem Quellsystem) über jede Transformation, Aggregation und Ladung bis zu seinem endgültigen Platz in einem Bericht nimmt.

Bei einem Versicherer durchläuft eine einzelne gemeldete Zahl typischerweise:

1. Quell- und Operativsysteme: Vertragsverwaltung (Prämien, Deckungsbedingungen), Schadensysteme (Reserven, Zahlungen), Rückversicherungssysteme (zedierte Beträge).

2. Data warehouse oder data lake: wo Datensätze extrahiert, transformiert und geladen werden (ETL).

3. Aktuarielle Modelle: Reservierungsengines, Kapitalmodelle (z. B. interne Modelle oder Standardformel unter Solvency II).

4. Reporting-Layer: das Tool, das QRTs (Quantitative Reporting Templates) oder die Schedules des NAIC Annual Statement füllt.

Die Lineage-Dokumentation beantwortet für jede gemeldete Zahl drei Fragen: Wo ist sie entstanden, was ist mit ihr passiert, und wer hat sie angefasst.

Warum die Aufsicht genau darauf achtet

Zwei Regulierungsregime bilden den Rahmen dieser Lektion:

  • Solvency II (EU, seit 2016 in Kraft, beaufsichtigt von der EIOPA und nationalen Aufsichtsbehörden wie der BaFin in Deutschland oder der ACPR in Frankreich) verpflichtet Versicherer zur Einreichung von QRTs sowie eines jährlichen RSR (Regulatory Supervisory Report) und SFCR (Solvency and Financial Condition Report). Die Meldeanforderungen der „Säule 3“ verlangen ausdrücklich Datenqualitätsstandards: Richtigkeit, Vollständigkeit und Angemessenheit (Artikel 19 der Delegierten Verordnung 2015/35).
  • NAIC-Anforderungen in den USA, bundesstaatlich angewendet, regeln das Annual Statement, die RBC (Risk-Based Capital)-Meldungen und seit 2020 den zunehmenden Einsatz eigener NAIC-Tools zur Datenerhebung und -analyse. Es gibt kein bundesweites Äquivalent zu Solvency II; die US-Aufsicht ist bundesstaatlich organisiert und über NAIC-Standards koordiniert.

Beide Regime laufen auf dieselbe Erwartung zu: Versicherer müssen auf Anfrage nachweisen können, wie eine Zahl entstanden ist. Das wird häufig als „Data traceability“ oder „Auditability“ bezeichnet.

Die EIOPA-Leitlinien zur internen Governance nennen die Dokumentation der Data lineage ausdrücklich als aufsichtliche Erwartung, nicht nur als Best Practice.

Die Anatomie einer Lineage-Lücke

Eine Lücke entsteht, wenn ein Glied in der Kette nicht dokumentiert oder nicht überprüfbar ist. Häufige Ursachen aus der Praxis:

  • Manuelle Anpassungen in Spreadsheets zwischen Warehouse und aktuariellem Modell, ohne Versionskontrolle oder Freigabeprotokoll.
  • Systemmigrationen (ein häufiges Ereignis nach M&A), bei denen die historische Mapping-Logik verloren geht.
  • Unklare Verantwortlichkeit für Felder wie „brutto vs. netto Rückversicherung“, was zu Doppelzählungen oder Auslassungen führt.
  • Undokumentierte Geschäftsregeln im ETL-Code, z. B. ein vor Jahren hart codierter Währungsumrechnungskurs, der nie überprüft wurde.

Ein vereinfachter Lineage-Datensatz für unsere Beispielzahl könnte so aussehen:

Field: Best_Estimate_Liabilities_LoB12
Source: PolicyAdmin_System_EU (table: claims_reserve, field: reserve_amt)
Extract date: 2026-03-31
Transformation 1: currency conversion GBP->EUR, rate source = ECB daily rate
Transformation 2: aggregation by LoB per EIOPA LoB mapping table v4.2
Transformation 3: actuarial adjustment, model: Reserving_Model_v7.1, run_id: 20260405_02
Loaded to: QRT_S.17.01, cell D47
Approved by: Head of Actuarial Reporting, 2026-04-10

Die letzte Zeile ist genauso wichtig wie die technische Spur: Governance ist nicht nur IT, sie ist Accountability.

Governance-Rollen und Kontrollmetriken

Governance-Frameworks verteilen Verantwortung, damit Lineage nicht vom institutionellen Gedächtnis abhängt. Die Standardstruktur:

  • Data owner: verantwortlich für eine Datendomäne (z. B. gehört dem Head of Underwriting die Vertragsdaten-Domäne).
  • Data steward: steuert Qualität und Definitionen operativ im Tagesgeschäft.
  • Data Quality Committee: prüft Metriken und genehmigt Prioritäten für die Behebung, oft mit Berichtslinie an einen Chief Data Officer.

Metriken, auf die Boards und Aufsichtsbehörden tatsächlich schauen (die Zahlen unten sind illustrative Branchen-Benchmarks, als Schätzwerte und nicht als universelle Schwellen zu verstehen):

| Metrik | Was sie misst | Typischer Zielwert (Schätzung) |

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

| Lineage coverage | % der kritischen Datenelemente (CDEs) mit dokumentierter End-to-End-Lineage | 90 %+ für CDEs, die in regulatorische Berichte einfließen |

| Closure rate für Datenqualitätsthemen | % der identifizierten DQ-Themen, die innerhalb des SLA behoben werden | 85–95 % innerhalb des Quartals |

| Manual adjustment ratio | % der gemeldeten Zahlen, die einen manuellen Schritt (Spreadsheet) durchlaufen | Niedriger ist besser; viele Versicherer zielen auf unter 10 % |

| Anzahl Critical Data Elements (CDE) | Anzahl der Felder, die formal als regulatorisch kritisch klassifiziert und verstärkt kontrolliert werden | Je Unternehmen unterschiedlich; oft mehrere Hundert bis einige Tausend |

Rechenbeispiel: Angenommen, ein Versicherer hat 1.200 CDEs, die in seine Solvency-II-QRTs einfließen. Eine interne Prüfung findet für 1.050 davon eine vollständige Lineage-Dokumentation.

Lineage coverage = 1.050 / 1.200 = 87,5 %

Bei einem internen Ziel von 90 % hat dieser Versicherer eine Lücke von 2,5 Prozentpunkten, also rund 30 Felder, die vor dem nächsten Meldezyklus behoben werden müssen. Diese Lücke wird zum Prüfungsbefund.

Der Bezug zu BCBS 239

Obwohl für Banken geschrieben, werden die BCBS 239-Prinzipien des Basler Ausschusses („Principles for effective risk data aggregation and risk reporting“, 2013) von Datenteams in der Versicherungsbranche verbreitet als Governance-Vorlage genutzt, weil sie granularer sind als der Solvency-II-Text selbst. Direkt übertragbare Kernprinzipien: Daten müssen richtig, vollständig, zeitnah und anpassungsfähig sein, und Unternehmen müssen Berichte reproduzieren und ohne wesentliche Verzögerung bis zur Quelle zurückverfolgen können, was Praktiker in der Regel so auslesen, dass eine Ad-hoc-Anfrage der Aufsicht innerhalb von Tagen und nicht Wochen erfüllt werden kann.

Wissenscheck

1. Ein Prüfer hinterfragt eine Zahl in einem Solvency-II-QRT-Template. Was bedeutet in diesem Kontext eine echte „Lineage-Lücke“?

2. Warum gilt die Dokumentation von „wer hat sie angefasst“ als genauso wesentlich wie „wo ist sie entstanden“?

3. Eine gemeldete Best-Estimate-Liabilities-Zahl durchläuft ein Vertragsverwaltungssystem, einen ETL-Prozess im Data warehouse und ein aktuarielles Reservierungsmodell, bevor sie im QRT-Template ankommt. Welche Aussage beschreibt am besten, warum jede Stufe für die Lineage relevant ist?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE richtigen Antworten dazu, warum Aufsichtsbehörden wie EIOPA und NAIC Data lineage im regulatorischen Reporting betonen.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE richtigen Antworten zu Systemen bzw. Stufen, die typischerweise zum Data-lineage-Pfad einer regulatorisch gemeldeten Zahl bei einem Versicherer gehören.

Wählen Sie alle richtigen Antworten aus.

Ein Lineage-Programm aufbauen: praktische Schritte

1. Zuerst die CDEs klassifizieren. Versuchen Sie nicht, die Lineage für jedes Feld im Warehouse zu dokumentieren. Beginnen Sie mit Feldern, die in QRTs, SFCR-Kennzahlen und RBC-Berechnungen einfließen.

2. Erfassung automatisieren, wo möglich. Moderne ETL- und Data-Catalog-Tools (z. B. Collibra, Informatica, Apache Atlas) können technische Lineage automatisch aus Pipeline-Metadaten erzeugen und reduzieren die Abhängigkeit von manueller Dokumentation, die veraltet.

3. Jeden manuellen Eingriff protokollieren. Wenn ein Aktuar eine Zahl in Excel anpasst, bevor sie ins Modell geht, braucht dieser Schritt einen Zeitstempel, einen Namen und eine Begründung.

4. Lineage testen, nicht nur dokumentieren. Führen Sie regelmäßige „Trace-back“-Übungen durch: eine gemeldete Zahl zufällig auswählen und jemanden außerhalb des ursprünglichen Teams ihre Lineage allein anhand der Dokumentation rekonstruieren lassen. Gelingt das nicht, hat die Dokumentation ihren eigentlichen Test nicht bestanden.

5. Behebungsmaßnahmen an Governance-Metriken koppeln und diese Metriken dem Risikoausschuss des Boards berichten, nicht nur der IT.

🎬 [VIDEO: „What is Data Lineage?“ - youtube.com - eine kurze, zugängliche Erklärung der Data-lineage-Konzepte, anwendbar über regulierte Branchen hinweg, nützlich für nicht-technische Zuschauer, bevor es um Versicherungsspezifika geht]

Die wichtigsten Erkenntnisse

  • Data lineage ist der nachvollziehbare Weg einer Zahl vom Quellsystem bis zur regulatorischen Meldung; Lineage-Lücken sind der häufigste Befund in Datenprüfungen nach Solvency II und NAIC.
  • Solvency II (EU, EIOPA-beaufsichtigt) und das bundesstaatlich organisierte NAIC-Framework in den USA verlangen von Versicherern, Richtigkeit, Vollständigkeit und Nachvollziehbarkeit der gemeldeten Zahlen nachzuweisen, nicht nur die richtige Endzahl zu produzieren.
  • Governance mit klaren Rollen: Data owners, Data stewards und ein Data Quality Committee, gemessen mit konkreten Metriken wie Lineage coverage und Manual adjustment ratio.
  • Ein Rechenbeispiel: 1.050 dokumentierte CDEs von insgesamt 1.200 ergeben 87,5 % Lineage coverage, unter einem verbreiteten internen Ziel von 90 %, und genau diese Unterdeckung markieren Aufsichtsprüfer.
  • BCBS 239 stammt aus der Bankenwelt, wird von Versicherern aber breit übernommen als granularer, praxistauglicher Governance-Standard für Datenaggregation und Reporting-Integrität.