+150 XP

Fraud-Detection-Modelle auf Basis von Schadendaten aufbauen

# Fraud-Detection-Modelle auf Basis von Schadendaten aufbauen

Ein Personenschaden landet auf dem Schreibtisch eines Sachbearbeiters: Auffahrunfall, drei Insassen, alle melden Weichteilverletzungen im Nackenbereich, alle behandelt in derselben Klinik, alle innerhalb von 48 Stunden nach dem Unfall vom selben Anwalt vertreten. Einzeln betrachtet ist nichts davon illegal. Zusammen ist es die klassische Signatur eines organisierten Betrugsrings.

Ihr Job als Datenverantwortlicher ist es, einem Modell beizubringen, dieses Muster zu erkennen, und zwar ohne die tausenden legitimen Schleudertrauma-Fälle zu flaggen, die oberflächlich ähnlich aussehen.

Warum Fraud Detection ein Datenproblem ist und kein Regelproblem

Versicherer arbeiten seit Jahrzehnten mit Regeln. Eine Regel sagt: „Flagge jeden Schaden über 10.000 $, bei dem die Behandlung mehr als 30 Tage nach dem Unfall beginnt.“ Regeln sind transparent und leicht prüfbar, aber Betrüger lernen sie und bleiben knapp unter der Schwelle.

Soft fraud (das Übertreiben eines echten Schadens) und hard fraud (ein vollständig gestellter oder erfundener Schaden) entwickeln sich beide weiter. Der interessante, teure Betrug ist organisiert: Ringe aus Leistungserbringern, Anwälten und „Patienten“, die dasselbe Drehbuch über viele Schäden hinweg recyceln.

Das ist ein Musterproblem. Und Muster über tausende Schäden hinweg sind genau das, worin Datenmodelle gut sind.

Die Coalition Against Insurance Fraud veröffentlicht solide, kostenlose Hintergrundinformationen dazu, wie diese Schemata funktionieren. Überfliegen Sie ihre fraud resources, bevor Sie Features entwerfen; wer die Tat versteht, baut bessere Signale dafür.

Beginnen Sie mit der Analyseeinheit

Einsteiger modellieren „den Schaden“. Betrugsringe leben *zwischen* den Schäden. Sie brauchen also drei Ebenen:

  • Schadenebene: ein Schadenereignis.
  • Entitätsebene: eine Person, Klinik, ein Fahrzeug oder Anwalt, die über viele Schäden hinweg auftauchen.
  • Netzwerkebene: wie diese Entitäten verbunden sind.

Ein einzelner verdächtiger Schaden sagt Ihnen wenig. Derselbe Chiropraktiker, der auf 200 Auffahrschäden mit geringer Geschwindigkeit und nahezu identischen Behandlungsplänen auftaucht, sagt Ihnen viel.

Feature Engineering: den Tatort in Signale übersetzen

Wandeln wir unseren Eingangsfall in Features um, die ein Modell lesen kann.

Features auf Schadenebene

  • Tage vom Unfall bis zur ersten Behandlung (sehr kurz oder auffällig verzögert, beides ist relevant).
  • Behandlungsintensität: Anzahl der Besuche relativ zur Verletzungsschwere.
  • Verhältnis von Weichteilverletzungen (schwer widerlegbar) zu objektiv überprüfbaren Verletzungen.
  • Wurde der Unfall der Polizei gemeldet? Gab es unabhängige Zeugen?
  • Tageszeit und Ort (manche gestellten Unfälle häufen sich an bestimmten Stellen).

Features auf Entitätsebene

Hier zeigt sich organisierter Betrug.

  • Auf wie vielen Schäden erscheint diese Klinik, dieser Anwalt oder diese Werkstatt in diesem Jahr?
  • Welcher Anteil der Schäden eines Leistungserbringers betrifft denselben Verletzungstyp?
  • Tauchen dieselben drei Insassen gemeinsam bei früheren Unfällen auf?

Velocity- und Koinzidenz-Features

  • Anzahl der Insassen, die alle Personenschäden gemeldet haben (gestellte Unfälle maximieren die Anspruchsteller pro Crash).
  • Anwalt innerhalb von X Stunden mandatiert (schnelle rechtliche Vertretung, bevor Schmerzen realistischerweise einsetzen würden).
  • Mehrere Anspruchsteller mit derselben Adresse oder Telefonnummer.

Keines davon ist ein Beweis. Jedes ist ein schwaches Signal. Die Aufgabe des Modells ist es, viele schwache Signale zu einem kalibrierten Risk Score zu kombinieren.

Im Graph verstecken sich die Ringe

Klassische tabellarische Modelle übersehen das Bindegewebe. Betrugsringe sind von Natur aus ein Graph: Knoten sind Personen, Kliniken, Fahrzeuge, Telefonnummern und Bankkonten; Kanten sind gemeinsame Schäden.

Bauen Sie den Graph, dann berechnen Sie daraus Features:

  • Degree: wie viele Schäden ein Knoten berührt.
  • Connected Components: eng verbundene Cluster aus Anspruchstellern, Leistungserbringern und Anwälten, die gemeinsam wiederkehren.
  • Shared-Attribute-Links: zwei „unabhängige“ Anspruchsteller mit derselben Telefonnummer sind eine starke Kante.
python
import networkx as nx

# Nodes: claimants, providers, attorneys, phones, VINs
# Edges: appears-on-same-claim or shares-attribute
G = nx.Graph()
G.add_edge("claimant_A", "clinic_9")
G.add_edge("claimant_B", "clinic_9")
G.add_edge("claimant_A", "phone_555")
G.add_edge("claimant_B", "phone_555")  # suspicious shared attribute

# Find tight clusters that recur across claims
components = list(nx.connected_components(G))
suspicious = [c for c in components if len(c) > 15]

Ein Cluster aus fünfzehn „Fremden“, die alle über eine Klinik und eine Telefonnummer laufen, ist der Ring. Dieser strukturelle Fakt ist ein Feature, das Sie in das nachgelagerte Modell einspeisen.

Modellwahl: supervised, unsupervised oder beides

Sie haben selten saubere Fraud-Labels. Bestätigter Betrug ist ein winziger, verzerrter Ausschnitt: nur die Fälle, die jemand bereits erwischt hat. Arbeiten Sie also in Schichten.

Supervised Models

Trainieren Sie auf bestätigtem Betrug (untersucht und nachgewiesen) plus bestätigt legitimen Schäden. Gradient-Boosted Trees (XGBoost, LightGBM) verarbeiten gemischte Features gut und liefern Feature Importances, die Sachbearbeiter prüfen können. Gut, um *bekannte* Muster zu erwischen.

Die Schwäche: sie lernen nur Betrug, der wie früherer Betrug aussieht.

Unsupervised Anomaly Detection

Für neue Schemata nutzen Sie Anomaly Detection: Isolation Forests, Autoencoder oder Clustering. Diese flaggen Schäden, die von der Norm abweichen, ohne Labels zu benötigen. Das Ziel ist nicht, „Betrug“ festzustellen, sondern zu sagen: „Das ist statistisch ungewöhnlich, schau genauer hin.“

Der praktische Stack

Die meisten erfahrenen Versicherer fahren beides: einen Supervised Score für bekannte Typologien, einen Anomalie-Score für das Unbekannte, und Graph-Features, die in beide einfließen. Ein Schaden, der bei allen drei hoch liegt, geht direkt an die Special Investigations Unit (SIU), das interne Team, das Betrugsverdacht untersucht.

Das False-Positive-Problem ist das ganze Spiel

Hier liegt die Falle. Nehmen wir an, Betrug macht rund 10 Prozent der Schäden aus (eine häufig genannte Schätzung; die realen Quoten variieren je nach Sparte und sind schwer präzise zu messen, weil unentdeckter Betrug per Definition nicht gezählt wird).

Wenn Ihr Modell „zur Sicherheit“ 30 Prozent der Schäden flaggt, haben Sie Ihre SIU begraben. Sachbearbeiter verlieren das Vertrauen, ignorieren die Alerts, und das ganze System stirbt. Das ist Alert Fatigue, und sie tötet mehr Fraud-Programme als schlechte Mathematik.

Zwei Disziplinen lösen das:

1. Optimieren Sie auf Precision bei geringem Volumen. Sie müssen nicht jeden Betrug erwischen. Sie brauchen, dass die obersten 2 Prozent der geflaggten Schäden die Zeit eines Ermittlers wirklich wert sind. Messen Sie Precision at k: Von den 100 Schäden, die Sie oben flaggen, wie viele sind echt? Das ist die Zahl, die Ihre SIU interessiert.

2. Machen Sie Scores erklärbar. Ein Sachbearbeiter handelt nicht auf Basis von „das Modell sagt 0,87“. Geben Sie Gründe: „dieselbe Klinik auf 180 Schäden, drei Insassen traten gemeinsam bei einem früheren Schaden auf, Anwalt innerhalb von 6 Stunden mandatiert.“ Tools wie SHAP-Werte verwandeln einen Score in eine kurze Liste von Treibern. Erklärbarkeit ist zunehmend auch eine regulatorische Erwartung, denn einen Versicherungsnehmer als verdächtig zu flaggen hat reale Konsequenzen.

Governance: das ist regulierte Zone

Fraud-Modelle berühren geschützte Entscheidungen. Ein paar Leitplanken:

  • Keine verbotenen oder Proxy-Variablen verwenden. Features, die mit Ethnie, Religion oder nationaler Herkunft korrelieren, können illegale Diskriminierung erzeugen, auch unbeabsichtigt. Testen Sie auf Disparate Impact.
  • Halten Sie einen Menschen in der Loop. Das Modell leitet Schäden zur Prüfung weiter; es sollte nicht automatisch ablehnen. Eine Ablehnung ist eine menschliche, dokumentierte Entscheidung.
  • Dokumentieren Sie alles. Aufsichtsbehörden und Gerichte können fragen, warum ein Schaden untersucht wurde. „Das Modell hat es geflaggt“ genügt nicht.

Die NAIC (National Association of Insurance Commissioners) veröffentlicht laufend Leitlinien zum Einsatz von KI und Daten in der Versicherung; es lohnt sich, das zu verfolgen, während die Erwartungen bis 2026 strenger werden.

Wissenscheck

1. Warum argumentiert die Lektion, dass Fraud Detection im Kern ein Datenproblem und kein Regelproblem ist?

2. Ein einzelner Auffahrschaden mit geringer Geschwindigkeit und Weichteilverletzungen ist für sich schwer von einem legitimen Schleudertrauma zu unterscheiden. Was zeigt das über die passende Analyseeinheit?

3. Die Lektion warnt davor, die „tausenden legitimen Schleudertrauma-Fälle, die oberflächlich ähnlich aussehen“, als Betrug zu flaggen. Welches zentrale Modellierungsproblem hebt das hervor?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE richtigen Antworten. Welche Analyseebenen sind laut Lektion nötig, um organisierte Betrugsringe zu erkennen?

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE richtigen Antworten. Was gilt laut Lektion für die Unterscheidung zwischen soft fraud und hard fraud?

Wählen Sie alle richtigen Antworten aus.

Den Kreis schließen: Feedback macht es funktionsfähig

Ein Fraud-Modell wird nicht „einmal trainiert“. Jede SIU-Untersuchung produziert ein neues Label: Betrug bestätigt oder entlastet. Speisen Sie diese Ergebnisse zurück.

Zwei Vorbehalte:

  • Confirmation Bias. Wenn Sie nur untersuchen, was das Modell flaggt, lernen Sie immer nur über Schäden, die das Modell schon verdächtigt hat. Untersuchen Sie regelmäßig eine kleine Zufallsstichprobe von Schäden mit *niedrigem Score*, um Betrug zu finden, den das Modell verpasst. Sonst wird das Modell selbstsicher blind.
  • Concept Drift. Ringe passen sich an. Wenn Ihr stärkstes Signal (etwa eine bestimmte Klinik) abgeschaltet wird, verschiebt sich das Muster. Überwachen Sie, ob sich Ihre Feature Importances über die Zeit verändern, und trainieren Sie auf einem rollierenden Fenster nach.

Zurück zu unserem Schaden

Unser Eingangsfall: drei Insassen, eine Klinik, ein schneller Anwalt, alles Weichteilverletzungen. Durch den Stack gelaufen:

  • Schaden-Features: hohe Insassenzahl, schneller Anwalt, schwer überprüfbare Verletzungen. Erhöht.
  • Entitäts-Features: diese Klinik erscheint auf einem ungewöhnlich hohen Anteil von Auffahrschäden mit geringer Geschwindigkeit. Erhöht.
  • Graph: zwei der drei Insassen traten gemeinsam bei einem früheren Schaden auf. Starke Kante.

Kombinierter Score: hoch, mit drei erklärbaren Treibern. Der Fall geht mit klarer Begründung an die SIU, und die zehn legitimen Schleudertrauma-Fälle, die am selben Nachmittag bearbeitet werden (ein Insasse, normaler Behandlungsrhythmus, keine gemeinsamen Entitäten), laufen unberührt durch.

Das ist das Ziel: den Ring erwischen, den ehrlichen Anspruchsteller verschonen, die Zeit des Sachbearbeiters respektieren.

Key Takeaways

  • Modellieren Sie das Netzwerk, nicht nur den Schaden. Organisierter Betrug lebt in den Verbindungen zwischen Kliniken, Anwälten und wiederkehrenden Anspruchstellern; Graph-Features legen ihn offen.
  • Schichten Sie Supervised und Unsupervised Models. Supervised Scores erwischen bekannte Typologien; Anomaly Detection erwischt neue.
  • Precision bei geringem Volumen schlägt reinen Recall. Schützen Sie Ihre SIU vor Alert Fatigue, indem Sie nur die wertvollsten Schäden flaggen, mit erklärbaren Gründen.
  • Schließen Sie den Feedback-Loop und prüfen Sie auf blinde Flecken. Ziehen Sie Stichproben aus Schäden mit niedrigem Score und überwachen Sie Drift, damit das Modell weiterlernt, während die Ringe sich anpassen.
  • Behandeln Sie es als regulierte Entscheidungsfindung. Testen Sie auf Disparate Impact, lassen Sie Ablehnungen von Menschen entscheiden und dokumentieren Sie, warum jeder Schaden geflaggt wurde.