Schadenleistungs-Leakage-Erkennung

Das echte Ausmaß des Problems

Schadenleistungs-Leakage ist kein Randthema. VCA Software zitiert Insurance Thought Leadership mit rund 6 Prozent der gesamten Schadenzahlungen im US-Markt, etwa 67 Milliarden US-Dollar im Jahr, und schreibt, dass veröffentlichte Schätzungen je nach Sparte und Methode stark schwanken. Bei 500 Millionen Euro Schadenvolumen im Jahr wären 6 Prozent 30 Millionen Euro.

Die NTT DATA Claims Leakage Identification Platform (CLIP) unterstützt Versicherer dabei, Leakage entlang der Wertschöpfungskette zu identifizieren, zu messen und zu analysieren. NTT DATA nennt aus der Praxis:

• 6–12 % durchschnittliches Einsparpotenzial in der Kfz-Versicherung
• 18 % in der Sparte Home Insurance

Wichtig: Das sind keine Betrugsfälle. Es handelt sich um legitime Schadensfälle von legitimen Versicherungsnehmern, die jedoch aus Prozessfehlern, Klauselunkenntnis oder Verhandlungsschwäche zu viel ausgezahlt wurden.

Worum geht es genau, die Leakage-Taxonomie

Schadenleistungs-Leakage ist nicht homogen. Es gibt zwei grundlegend unterschiedliche Kategorien, die verschiedene ML-Ansätze erfordern:

Hartes Leakage, technische Fehler mit direktem Rückforderungspotenzial:

• Auszahlungen jenseits von Policensublimits
• Regulierung von Schäden, die durch Deckungsausschlüsse eigentlich nicht gedeckt waren
• Doppelzahlungen (derselbe Schadensfall mehrfach reguliert, unterschiedliche Sachbearbeiter)
• Falsch angewendete Selbstbeteiligungen (zu gering oder nicht abgezogen)
• Fälle ohne gültige Police zum Schadenzeitpunkt

Weiches Leakage, nicht regelwidrig, aber systematisch suboptimal:

• Auszahlungsbeträge, die statistisch deutlich über dem Median vergleichbarer Fälle liegen, ohne erkennbaren Grund
• Verhandlungsergebnisse mit Anwälten oder Werkstätten, die unter dem erzielbaren Benchmark liegen
• Schadenfälle ohne Subrogationsprüfung (hätte ein Dritter in Anspruch genommen werden können? → dazu mehr im Subrogation Mining)
• Reservierungen, die konsistent zu hoch angesetzt sind und durch langsamere Rückstellungsauflösung Kapitalkosten erzeugen

Der Unterschied ist entscheidend: Hartes Leakage lässt sich oft retrospektiv zurückfordern (je nach Verjährung und Policenbedingungen). Weiches Leakage ist in der Vergangenheit verloren, aber in Zukunft vermeidbar.

Diese Unterscheidung ist auch das, was Claims-Leakage-Erkennung fundamental von der Betrugserkennung trennt: Betrug setzt absichtliche Täuschung voraus. Leakage passiert, weil Prozesse und Klauseln komplex sind und Menschen Fehler machen, auch ohne jeden Vorsatz.

Mit vs. ohne KI, ein ehrlicher Vergleich

Die Leakage-Potenziale stammen von NTT DATA (insurance.nttdata.com, “Small Leaks Sink Great Ships”); die übrigen Werte der Tabelle sind Annahmen dieser Seite.

Einschätzung auf einen Blick

Zeitersparnis, mittel (3/5) Die direkte Arbeitszeitentlastung betrifft primär Schadenauditoren und die Innenrevision: NTT DATA nennt für CLIP 50–80 % schnellere Closed-File-Reviews. Sachbearbeiter in der laufenden Regulierung profitieren durch klare Markierungs-Hinweise, was genau geprüft werden soll. Dennoch bleibt dies nicht die primäre Stärke dieses Anwendungsfalls: Die eigentliche Wirkung liegt in der Kostensenkung, nicht in der direkten Stundenentlastung. Verglichen mit Schadensmeldungsverarbeitung oder Angebotsautomatisierung, die täglich Bearbeitungszeit für viele Sachbearbeiter einsparen, ist der Effekt hier konzentrierter.

Kosteneinsparung, sehr hoch (5/5) Das ist die stärkste Achse dieses Anwendungsfalls. Das von NTT DATA genannte Einsparpotenzial (6–12 % in der Kfz-Versicherung, 18 % in der Sparte Home Insurance) lässt sich direkt in Euro umrechnen. Für einen Versicherer mit 200 Millionen Euro Schadenaufwand und einer Leakage-Quote von 8 Prozent liegen 16 Millionen Euro im Feuer. Verhindert das System davon ein Drittel, sind das gut 5 Millionen Euro weniger Aufwand im Jahr. Verwechsle die beiden Größen nicht, die Leakage-Quote ist das Potenzial, nicht die Einsparung. Unter den Versicherungs-Anwendungsfällen in dieser Kategorie teilt sich diese Bewertung mit Betrugserkennung, Echtzeit-Tarifierung und Reparaturpreisinflations-Erkennung, allesamt Kostenhebel mit direktem Euro-Bezug. Die Bewertung ist trotzdem gerechtfertigt, weil Leakage-Erkennung das gesamte Schadenportfolio scant, nicht nur verdächtige Fälle.

Schnelle Umsetzung, schwierig (2/5) Kein Schönreden: Ein vollständiges Leakage-Erkennungssystem braucht 9–18 Monate bis zum Produktivbetrieb. Es braucht strukturierte Schadensdaten aus mehreren Jahren, eine saubere Datenmigration in ein Analytics-System, eine Verbindung zum Claims-Management-System (Guidewire, SAP FS-CM, msg.Insurance), und einen validierten ML-Ansatz. Wer mit einem retroaktiven Portfolio-Audit beginnt, kann erste Ergebnisse schneller sehen (3–6 Monate für die Pilot-Analyse), aber das ist der Audit, nicht das Echtzeit-System. Eine der anspruchsvollsten Implementierungen unter den hier verglichenen Versicherungs-Anwendungsfällen.

ROI-Sicherheit, hoch (4/5) Was Claims Leakage von vielen anderen Use Cases unterscheidet: Der Nutzen ist direkt messbar. Du kannst das identifizierte Leakage-Volumen in Euro ausweisen, die Rückforderungen (bei hartem Leakage) tracken, und die Differenz zu Vergleichsfällen dokumentieren. Ein sauber durchgeführtes Pilot-Audit nach 3–6 Monaten gibt belastbare Zahlen. Der eine fehlende Punkt zur Höchstwertung: Bei weichem Leakage (Verhandlungsschwäche, schlechte Benchmarks) ist die Attribution schwieriger, du weißt, dass du teuer reguliert hast, aber nicht immer, ob du günstiger hättest regulieren können.

Skalierbarkeit, sehr hoch (5/5) Einmal gebaut, scant das Modell jede neue Schadensmeldung ohne proportional steigenden Aufwand. Ob dein Schadenvolumen um 20 % wächst oder du eine neue Sparte integrierst: Der Grenzaufwand ist gering. Die einzige Skalierungsbedingung ist Datenqualität, bei neuen Sparten mit anderen Regulierungsmustern muss das Modell nachtrainiert werden.

Richtwerte, stark abhängig von Schadenvolumen, Spartenstruktur und Qualität der Bestandsdaten.

Was das System konkret macht

Schadenleistungs-Leakage-Erkennung arbeitet in zwei Modi, die du kombinieren oder sequentiell einführen kannst:

Modus 1: Retroaktives Portfolio-Audit

Das System analysiert abgeschlossene Schadensfälle der letzten 3–5 Jahre. Das Machine Learning-Modell gruppiert alle Fälle nach Schadentyp, Sparte, Schadenhöhe, Region, Schadenursache und weiteren Merkmalen. Für jede Gruppe berechnet es einen statistischen Erwartungsbereich für die Regulierungshöhe. Fälle, die deutlich außerhalb dieses Bereichs liegen, werden markiert, mit einem Erklärungswert: „Dieser Haftpflichtfall wurde 43 % über dem Median ähnlicher Fälle reguliert. Mögliche Ursache: kein Gutachter hinzugezogen.”

Gleichzeitig führt ein regelbasierter Layer eine Deckungsprüfung durch: Wurde der korrekte Deckungsumfang auf den Policentyp angewendet? Sind Sublimits eingehalten? Gibt es einen Ausschluss, der nicht berücksichtigt wurde?

Das Ergebnis ist eine priorisierte Liste von Fällen, die Sachbearbeiter oder Innenrevisoren manuell nachprüfen sollten, mit Begründung je Fall.

Modus 2: Echtzeit-Scoring bei Neuschäden

Bei jedem neu eingehenden Schadensfall, zum Zeitpunkt der Ersterfassung (First Notice of Loss, FNOL) oder während der Regulierung, berechnet das Modell einen Leakage-Score. Dieser Score fließt als Hinweis in die Sachbearbeiteroberfläche ein: „Achtung: Ähnliche Fälle wurden im Schnitt mit 4.200 € reguliert. Der vorgeschlagene Betrag liegt bei 7.800 €. Bitte Deckungsklausel §12 Abs. 3 prüfen.”

Ob der Sachbearbeiter den Hinweis akzeptiert oder mit Begründung übergeht, wird protokolliert, das ist die Datenbasis für das Modell-Retraining.

Was das System nicht macht

Es ersetzt keine menschliche Entscheidung. Es blockiert keine Auszahlung automatisch. Und es erkennt keinen Betrug, das ist ein anderes System mit anderen Trainingsdaten und anderen Modellen. Wer beides kombinieren will, betreibt zwei separate Scoring-Layer, die unterschiedliche Flags setzen.

Retroaktives Audit vs. Echtzeit-Scoring, der Unterschied zählt

Das sind keine Varianten desselben Systems, es sind zwei unterschiedliche Investitionsentscheidungen mit unterschiedlichen Laufzeiten und Risikostrukturen.

Die Empfehlung für jeden Versicherer, der neu einsteigt: zuerst das retroaktive Audit. Es erzeugt innerhalb von Monaten belastbare Zahlen, und ist die überzeugendste interne Argumentationshilfe für die Vollimplementierung.

Konkrete Werkzeuge, was wann passt

Kein Weg führt an einer ehrlichen Toolauswahl vorbei: Claims-Leakage-Erkennung ist ein Spezialproblem, und die relevanten Lösungen sind sehr unterschiedlich positioniert.

Shift Technology , wenn du Echtzeit-Leakage-Prävention und Automatisierung kombinieren willst Das 2025 vorgestellte Shift Claims bewertet und priorisiert laut Shift Schadenfälle, unterstützt Sachbearbeiter und automatisiert Aufgaben mit KI-Agenten, um unter anderem Claims Leakage zu senken. Frühe Anwender berichten laut Shift 3 % niedrigere Schadenverluste, 30 % schnellere Schadenbearbeitung und eine Automatisierungsrate von 60 %; Shift nennt AXA Switzerland als frühen Anwender. Einen Preis nennt die archivierte Pressemitteilung nicht.

NTT DATA CLIP, wenn du ein strukturiertes Portfolio-Audit willst Die Claims Leakage Identification Platform von NTT DATA liefert laut NTT DATA detaillierte, automatisierte und quantitative Analysen von Claims Leakage. Sinnvoller Einstieg für mittelgroße Versicherer, die zunächst das Potenzial verstehen wollen, bevor sie in Echtzeit-Integration investieren. Einen Preis nennt der archivierte NTT-DATA-Beitrag nicht. Kontakt über insurance.nttdata.com.

Celonis , wenn der Schadenbearbeitungsprozess selbst das Problem ist Claims Leakage entsteht oft nicht nur durch schlechte Deckungsanwendung, sondern durch Prozessfehler: Fälle, die zu lange liegen, zu viele Handwechsel haben, oder Schritte überspringen. Celonis Process Mining legt diese Muster offen und identifiziert, wo Regulierungsschritte systematisch abgekürzt oder umgangen werden. Das Tool ist kein Leakage-Detector im engeren Sinne, aber ein wertvolles Diagnosewerkzeug in der Vorbereitungsphase.

Dataiku , wenn du ein Custom-ML-Modell intern bauen willst Für Versicherer mit einer eigenen Data-Science-Abteilung ist Dataiku eine Option, um Claims-Leakage-Modelle intern zu entwickeln, auf eigenen Daten, mit voller Kontrolle über Modellarchitektur und Erklärbarkeit. Die Plattform bietet vorgefertigte Pipelines für Insurance Analytics und die notwendige MLOps-Infrastruktur für Monitoring und Retraining. Erfordert 2–4 interne Data Scientists plus Implementierungsunterstützung. Sinnvoll, wenn du Hersteller-Unabhängigkeit und volle Datensouveränität priorisierst.

SAS Fraud Management , für Leakage-Erkennung nicht belegt Die Toolseite beschreibt SAS Fraud Management als Echtzeit-Überwachung von Zahlungen und nicht-monetären Transaktionen, ein Einsatz für Leakage-Erkennung in der Schadenregulierung ist dort nicht belegt. Eine Empfehlung für Claims Leakage sprechen wir deshalb nicht aus.

Wann welcher Ansatz:

• Retroaktives Audit, erste Potenzialschätzung → NTT DATA CLIP (Kontakt über insurance.nttdata.com)
• Echtzeit-Prävention + Enterprise-Vollintegration → Shift Technology
• Prozessdiagnose als Vorarbeit → Celonis
• Eigenentwicklung mit interner Data-Science → Dataiku

Datenschutz und Datenhaltung

Claims-Leakage-Erkennung verarbeitet hochsensible Daten: personenbezogene Daten von Versicherungsnehmern, Gesundheitsdaten in Personenschadenregulierungen, Bankverbindungen, Schadenfotos, ärztliche Gutachten. Das bedeutet: maximale DSGVO-Sensibilität.

DSGVO Art. 22, automatisierte Entscheidungen Wenn das Leakage-Scoring dazu führt, dass eine Auszahlung verzögert oder verweigert wird, ohne dass ein Mensch die Entscheidung trifft, greift DSGVO Art. 22 über automatisierte Einzelentscheidungen mit erheblicher Wirkung. Für die Versicherungsbranche gilt § 37 BDSG als nationale Ausnahmeregel, er erlaubt automatisierte Entscheidungen in der Versicherungsleistungserbringung, sofern die Person das Recht auf menschliche Überprüfung hat. In der Praxis bedeutet das: Keine automatische Markierung darf direkt zu einer Auszahlungssperre führen, immer muss ein menschlicher Sachbearbeiter die finale Entscheidung treffen.

Dieser Abschnitt ist eine fachliche Orientierung, keine Rechts- oder Complianceberatung. Für verbindliche Einschätzungen zu BaFin-Anforderungen, Art. 22 DSGVO oder § 37 BDSG wende dich an einen Fachanwalt für Versicherungsrecht.

Datenhaltung praktisch:

• Celonis : Celonis sagt, die KI-Funktionen laufen in derselben Region wie die Plattform des Kunden. Eine Standardregion nennen die archivierten Seiten nicht. Laut Trust Center läuft die Plattform auf AWS und Microsoft Azure, und Kunden wählen den Standort ihrer Instanz.

Was es kostet, realistisch gerechnet

Phase 1: Retroaktives Portfolio-Audit (3–6 Monate)

• NTT DATA CLIP-Pilotaudit: Preis nennen wir nicht
• Intern (Annahme dieser Seite): 20–40 Stunden Datenvorbereitung plus Abstimmungsaufwand mit IT und Compliance
• Erwartetes Ergebnis: Quantifiziertes Leakage-Potenzial nach Sparte, die Grundlage für den Business Case der Vollintegration

Phase 2: Echtzeit-Integration (9–18 Monate)

• Shift Technology oder vergleichbare Plattform: Preis nennen wir nicht.
• Interne Kosten: IT-Ressourcen für CMS-Integration (Guidewire, SAP FS-CM, msg.Insurance), Datenvorbereitung, Testing und Change Management, Annahme dieser Seite: 2–4 interne FTE über 12 Monate.
• Laufend: Modell-Monitoring, vierteljährliches Retraining, Pflege der Deckungsregel-Bibliothek.

Was du dagegenrechnen kannst Ein Versicherer mit 300 Millionen Euro Schadenvolumen und 8 % Leakage-Quote hat theoretisch 24 Millionen Euro Leakage im Jahr. Wenn das System 30 % davon verhindert oder identifiziert (konservative Annahme): 7,2 Millionen Euro, im ersten Jahr nach Vollbetrieb. Selbst wenn du nur 50 % dieser Einsparung tatsächlich realisierst (weil weiches Leakage nicht vollständig verhindert wird und hartes Leakage nicht immer rückforderbar ist): 3,6 Millionen Euro jährlicher Netto-Benefit ist für die meisten Versicherer eine klare positive Rechnung.

Der entscheidende Schritt: nicht die Vollimplementierung als erstes verkaufen, sondern das Pilot-Audit. Ein Audit, das ein hohes Leakage-Potenzial aufzeigt, begründet die Vollintegration selbst.

Drei typische Einstiegsfehler

1. Leakage-Erkennung und Betrugserkennung als ein System planen Die Versuchung ist groß: beide Systeme arbeiten mit Schadensdaten, beide markieren Ausreißer. Aber die Trainingsdaten, die Modellarchitektur, die Eskalationswege und die rechtlichen Anforderungen sind fundamental verschieden. Betrugserkennungssysteme sind für die SIU (Special Investigation Unit) optimiert und produzieren rechtsfeste Dokumentation für Strafverfolgung. Leakage-Systeme sind für Sachbearbeiter und Innenrevision optimiert und produzieren Verbesserungshinweise. Wer beide in einem gemeinsamen Modell entwickelt, landet nach 9 Monaten mit einem System, das Betrug mit zu vielen Falsch-Positiven übersieht und Leakage-Hinweise produziert, die vor Gericht nicht verwertbar sind, weil das Training auf gemischten Labels keine saubere Entscheidungsgrenze lernt. Lösung: Zwei separate Scoring-Layer mit getrennten Trainingsdaten, getrennten Schwellenwerten und getrennten Eskalationspfaden, von Projektbeginn an.

2. Starten ohne saubere Datenbasis Claims-Leakage-ML braucht konsistente, vollständig ausgefüllte Schadensdaten über mindestens 3 Jahre. In der Praxis findet man: unterschiedliche Schadenscodes in verschiedenen Jahren (Taxonomy-Änderungen), fehlende Felder in Altfällen, inkonsistente Deckungs-Kennzeichnung, Daten in mehreren System-Generationen. Wer ohne Daten-Audit einsteigt, trainiert ein Modell auf gemischte Qualität, und bekommt schlechte Modell-Performance zurück. Lösung: 4–6 Wochen Daten-Audit und -Bereinigung vor dem Modellbau einplanen.

3. Falsch-Positive ignorieren statt monitoren Das ist der regulatorisch gefährlichste Fehler. Wenn das Leakage-System zu viele legitime Fälle markiert und damit die Regulierungsdauer verlängert, entsteht eine VVG-Problematik: Der Versicherer ist verpflichtet, unstrittigen Schadenersatz unverzüglich zu leisten (§ 14 VVG). Systematische Verzögerungen durch übertriebenes Flagging können als Regulierungserschwernis gewertet werden. Lösung: Eine klare False-Positive-Rate als KPI definieren, als Zielwert etwa ein Zehntel der markierten Fälle, wöchentlich monitoren und die Modell-Thresholds daran anpassen.

Dieser Abschnitt ist eine fachliche Orientierung, keine Rechts- oder Complianceberatung. Für verbindliche Einschätzungen zu VVG §14 oder BaFin-Anforderungen bei Regulierungsverzögerungen wende dich an einen Fachanwalt für Versicherungsrecht.

4. Kein Modell-Retraining einplanen Claims Leakage ML ist kein fire-and-forget-System. Reparaturkosten inflationieren, das verändert die Referenzwerte für Kfz-Schäden. Gerichtsentscheidungen zu Personenschäden ändern Benchmark-Beträge. Neue Klauselgenerationen kommen in den Bestand. Ein Modell, das 2024 trainiert wurde und 2026 unverändert läuft, markiert entweder zu viele Fälle (weil die Welt sich verändert hat) oder zu wenige. Quartalsweises Retraining ist das Minimum, und muss als laufende Betriebsaufgabe eingeplant sein, nicht als Einmalaufwand.

Was mit der Einführung wirklich passiert, und was nicht

Die technische Implementierung ist das, was im Projektplan steht. Was nicht im Projektplan steht, ist das Schwierigere.

Sachbearbeiter-Widerstand gegen „automatische Besserwisser” Ein System, das einem erfahrenen Sachbearbeiter sagt, dass seine Regulierung 43 % über dem Median liegt, wird nicht widerstandslos akzeptiert. Die typische Reaktion: „Das war ein komplizierter Fall, das System versteht den Kontext nicht.” Oft hat der Sachbearbeiter sogar recht, der Kontext fehlt tatsächlich. Die Lösung ist nicht technisch, sondern organisatorisch: Erstens muss jeder Flag eine erklärbare Begründung liefern (welche Merkmale haben den Score ausgelöst), nicht nur einen Score. Zweitens muss die Unternehmensführung klar kommunizieren, dass Sachbearbeiter den Flag mit Begründung zurückweisen dürfen und darin ausdrücklich bestärkt werden, das System ist ein Hinweis, kein Urteil.

Die Innenrevision als Verbündeter, nicht als Bremse Leakage-Erkennung stärkt die Innenrevision strukturell, sie bekommt 100 % Abdeckung statt Stichproben. Das ist für viele Revisionsleiter ein echter Gewinn. Nutze das: Binde die Innenrevision früh in die Definition der Leakage-Kategorien ein. Was gilt als Leakage, was als legitime Regulierungsvariation? Diese Frage ist nicht technisch, sie ist inhaltlich, und die Innenrevision hat die Antworten.

Falsche Erwartungen an Rückforderungsquoten Nicht jedes identifizierte harte Leakage ist rückforderbar. Verjährungsfristen nach BGB (§ 195: 3 Jahre) begrenzen das Rückholpotenzial aus alten Portfolios. Manche Überzahlungen sind regulatorisch zwar korrekt gewesen, aber prozessual unglücklich, kein Rückforderungsrecht. Und aggressive Rückforderungen gegenüber Versicherungsnehmern schaffen Reputationsrisiken. Internes Leakage (zu hohe Sachverständigengebühren, ineffiziente Werkstattverhandlungen) ist politisch einfacher zu adressieren als externes.

Dieser Abschnitt ist eine fachliche Orientierung, keine Rechts- oder Complianceberatung. Für verbindliche Einschätzungen zu Verjährungsfristen nach § 195 BGB, Rückforderungsansprüchen gegenüber Versicherungsnehmern oder Haftungsfragen bei ML-gestützter Schadenprüfung wende dich an einen Fachanwalt für Versicherungsrecht.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

„Wir kennen unsere Regulierungsqualität, wir haben erfahrene Sachbearbeiter.” Das stimmt, und die Erfahrung ist wertvoll. Aber auch erfahrene Sachbearbeiter kennen nicht alle 200 Policenvarianten mit allen Klauseln auswendig. Das Problem ist nicht Inkompetenz, sondern Komplexität und Volumen. Ein Sachbearbeiter, der 80 Fälle im Monat bearbeitet, kann nicht bei jedem Fall alle Deckungsklauseln gegen alle historischen Vergleichsfälle prüfen. Das System tut das, schneller und konsistenter, nicht besser im Urteil, aber breiter in der Abdeckung.

„Das macht uns rechtlich angreifbar, wenn wir Schäden re-prüfen.” Das ist ein reales Risiko, aber ein handhabbares. Wenn du externe Versicherungsnehmer auf Basis von ML-Flags zu Rückzahlungen aufforderst, brauchst du rechtlich belastbare Begründungen. Der ML-Flag allein ist keine Grundlage für eine Rückforderung. Die Überprüfung muss durch einen Sachbearbeiter mit sachlicher Begründung erfolgen. Bei internen Leakage-Potenzialen (Werkstattgebühren, Sachverständigenkosten) ist das Risiko deutlich geringer. Lass dich von einem Versicherungsrechtsexperten beraten, welche Szenarien welches Rückforderungsrecht begründen.

Dieser Abschnitt ist eine fachliche Orientierung, keine Rechts- oder Complianceberatung. Für verbindliche Einschätzungen zu Rückforderungsansprüchen, BGB-Verjährung oder Haftungsrisiken bei ML-gestützter Schadenprüfung wende dich an einen Fachanwalt für Versicherungsrecht.

„Wir haben die Daten nicht strukturiert genug.” Das ist der häufigste und ehrlichste Einwand. Viele Versicherer wissen, dass ihre Schadensdaten in mehreren System-Generationen liegen, inkonsistent kodiert sind oder Felder systematisch leer sind. Die gute Nachricht: Das ist lösbar, aber es dauert länger als gedacht. Der Daten-Audit am Anfang ist kein bürokratischer Schritt, sondern der Kern des Projekts. Wer glaubt, er könne den Daten-Audit überspringen und direkt mit dem ML anfangen, wird nach 3 Monaten mit einem Modell dastehen, das auf Datenmüll trainiert wurde.

Woran du merkst, dass das zu dir passt

Du bist gut positioniert für Claims-Leakage-Erkennung, wenn:

• Du verarbeitest mindestens 30.000–50.000 Schadensmeldungen pro Jahr, darunter sind die statistischen Grundlagen für ein ML-Modell zu dünn
• Du hast strukturierte Schadensdaten aus mindestens 3 Jahren in einem einheitlichen System, mehrere System-Generationen oder inkonsistente Kodierung machen den Daten-Aufbereitungsaufwand prohibitiv
• Du hast eine Innenrevision oder ein Schaden-Audit-Team, das heute Stichproben manuell prüft, die brauchen das System und werden es verteidigen
• Deine Schadenquote ist in den letzten 2–3 Jahren gestiegen ohne klaren strukturellen Grund, das ist ein Hinweis, dass Leakage wächst
• Du hast ein modernes CMS (Guidewire, SAP FS-CM, msg.Insurance) und eine IT-Abteilung, die API-Integrationen bauen kann

Drei harte Ausschlusskriterien, wer es noch nicht tun sollte:

1. Unter 30.000 Schadenfälle pro Jahr (Unternehmensgröße): Das statistische Fundament für ein ML-Modell fehlt. Leakage-Analyse für kleine Portfolios funktioniert besser mit regelbasierten Systemen und gezielten manuellen Audits, kein ML erforderlich.

2. Keine konsistente Schadensdaten-Taxonomie über mindestens 3 Jahre (Datenreife): Wenn Schadentypen in verschiedenen Jahren unterschiedlich kodiert wurden, wenn Pflichtfelder systematisch leer sind, oder wenn die Datenmigration aus Legacy-Systemen nie abgeschlossen wurde, wird das Modell auf unzuverlässigen Trainingsdaten aufgebaut. Das Ergebnis: hohe False-Positive-Rate, niedriges Vertrauen der Sachbearbeiter, Projektstop nach 12 Monaten.

3. Kein modernes Claims-Management-System für Echtzeit-Integration (Infrastrukturreife): Wer seine Schäden noch in einer proprietären AS/400-Applikation verwaltet oder mit Excel-gestützten Workflows arbeitet, kann kein Echtzeit-Scoring integrieren. Das retroaktive Audit ist noch möglich (Datenexport als Basis), aber der eigentliche Wert, Prävention in Echtzeit, ist ohne CMS-Integration nicht erreichbar.

Das kannst du heute noch tun

Der schnellste Einstieg ohne großes Commitment: Führe intern ein Mini-Audit durch. Wähle eine Sparte aus (idealerweise Kfz-Haftpflicht, weil die Vergleichbarkeit der Fälle hoch ist) und ziehe die letzten 200–300 abgeschlossenen Fälle. Schau dir die Verteilung der Auszahlungsbeträge an: Wie viel Varianz gibt es? Gibt es Ausreißer, die auf den ersten Blick auffallen?

Das dauert einen halben Tag. Wenn du dabei Fälle findest, bei denen du dich fragst, warum der Betrag so hoch war, dann hast du dein erstes internes Argument für ein systematisches Audit.

Für den strukturierten nächsten Schritt: Nutze den folgenden Prompt, um einen ersten Leakage-Analyse-Rahmen für eine manuelle Stichprobe zu erstellen.

Quellen & Methodik

• NTT DATA, Small Leaks Sink Great Ships (insurance.nttdata.com, 17.11.2022). Durchschnittliches Einsparpotenzial 6–12 % (Kfz), 18 % in der Sparte Home Insurance; Closed-File-Review mit CLIP 50–80 % schneller.
• Shift Technology, Pressemitteilung zu Shift Claims (shift-technology.com, September 2025). Frühe Anwender berichten 3 % niedrigere Schadenverluste, 30 % schnellere Schadenbearbeitung, 60 % Automatisierungsrate und über 99 % Genauigkeit bei der Schadenbewertung; AXA Switzerland ist früher Anwender.
• VCA Software, Claims Leakage in Insurance (vcasoftware.com/claims-leakage, aktualisiert 9. Juli 2026). Zitiert Insurance Thought Leadership mit rund 6 % der gesamten Schadenzahlungen im US-Markt, etwa 67 Mrd. USD im Jahr; veröffentlichte Schätzungen schwanken je nach Sparte und Methode.
• DSGVO Art. 22 und § 37 BDSG: Automatisierte Einzelentscheidungen in der Versicherungsleistungserbringung.
• Hard/Soft Leakage Taxonomie: Workers’ Compensation Claims Leakage-Definitionen (wcabdefense.com und amaxx.com, Praxisberichte aus der Regulierung).
• Implementierungskosten: Orientierungsgrößen ohne veröffentlichte Preisliste, weder eigene Erhebung noch repräsentative Studie. Enterprise-Konditionen gibt es nur auf Anfrage.

Du willst wissen, ob dein Schadenportfolio das statistische Volumen für ein ML-Modell mitbringt, und welche Sparte der sinnvollste Einstieg wäre? Meld dich für ein kurzes Gespräch.