Schadennetzwerk-Betrugserkennung (Fraud Ring)

Das echte Ausmaß des Problems

Versicherungsbetrug ist kein Randproblem. Der Gesamtverband der Deutschen Versicherungswirtschaft (GDV) schätzt den jährlichen Schaden durch Versicherungsbetrug auf mehr als sechs Milliarden Euro — Tendenz steigend. Jede zehnte Schadenmeldung gilt als verdächtig. Der Anteil, der tatsächlich auf organisierte Betrugsringe zurückgeht, ist schwer zu isolieren, aber nach Brancheneinschätzung für einen überproportionalen Teil des Gesamtschadens verantwortlich: Ein einzelner Ring kann hunderte Tausend bis mehrere Millionen Euro aus einem Versicherer heraussaugen — systematisch, über Monate, von keinem Einzelfall-Scoring erfasst.

Das strukturelle Problem: Klassische Betrugserkennung ist einzelfallbasiert. Jede Schadenmeldung wird für sich bewertet — Schadensort, Betrag, Dauer, Plausibilität. Ein Ring arbeitet anders. Er verteilt das Risiko auf viele scheinbar normale Fälle, von denen keiner allein auffällig ist. Die Verbindungen — eine Werkstatt, ein Anwalt, eine Adresse, ein Zeitfenster — sind nur sichtbar, wenn man alle Fälle gleichzeitig betrachtet und ihre Verbindungen kartiert.

Das Fraunhofer SIT und ein fränkischer Versicherer haben im Projekt EWV (Erkennung von Wirtschaftskriminalität und Versicherungsbetrug) einen Machine Learning-basierten Prototyp entwickelt und erprobt, der Betrugshinweise in Kfz-Schadensfällen identifiziert — mit dem Ergebnis, dass das System rund 40 Prozent aller verdächtigen Fälle aus einem realen Schadensportfolio herausfiltern konnte. Was der Ansatz dabei bewies: Netzwerkinformation ist der entscheidende Unterschied zwischen Einzelfallscoring und echtem Fraud-Ring-Erkennung.

Und das in einer Branche, in der ein einziger Ring mit zehn Beteiligten und 24 Monaten Aktivität leicht 500.000 Euro Schaden anrichten kann, bevor er überhaupt ins Visier eines Ermittlers gerät.

Wie ein Fraud Ring funktioniert: Anatomie eines Netzwerkangriffs

Fraud Rings sind keine improvisierten Gelegenheitsbetrugsgruppen. Die Varianten, die für den größten Schaden verantwortlich sind, operieren methodisch — mit klarer Rollenverteilung und über Monate bis Jahre aufgebauten Verbindungen. Wer erkennen will, was KI-basierte Netzwerkanalyse leisten kann, muss verstehen, welche Topologien sie erkennen soll.

Kfz-Kollusions-Ring (häufigster Typ in Deutschland)
Kernstruktur: Halter A und Halter B inszenieren einen Unfall. A ist “Verursacher”, B der “Geschädigte”. Beide melden den Schaden. Halter A nutzt eine Werkstatt, die bewusst überhöhte Rechnungen ausstellt. Ein kooperierender Anwalt übernimmt die Regulierung von B. Der Anwalt und die Werkstatt kennen sich — sie erhalten einen Teil des Erlöses. Das Netzwerk besteht aus: Halter-Halter-Verbindung (Unfallbeteiligte), Halter-Werkstatt-Verbindung (Reparaturhistorie), Halter-Anwalt-Verbindung (Mandatshistorie). Keiner dieser Verbindungen ist allein verdächtig. Die Kombination ist es.

Ärzte-Patienten-Ring (Kranken- und Unfallversicherung)
Arzt X stellt für Patienten A, B, C, D und E Diagnosen aus, die Arbeitsunfähigkeit oder Behandlungsbedarf begründen. Die Patienten sind keine echten Patienten — sie erhalten Bescheinigungen gegen Bezahlung. Die Versicherung reguliert Krankengeld oder Behandlungskosten, ohne zu merken, dass alle fünf Patienten denselben Arzt nennen. Erkennungsmerkmal im Graphen: Cluster aus einem Arztknoten mit überdurchschnittlich hoher Knotenverbindungszahl zu Schadenstellern, die in keinerlei anderem Zusammenhang verbunden sind.

Werkstatt-Zentralknoten-Ring (Kfz-Sachschaden)
Nicht alle Halter im Ring kennen sich untereinander. Die Werkstatt ist der Knotenpunkt: Sie empfiehlt Haltern bestimmte Gutachter, stellt überhöhte Rechnungen, koordiniert Anwälte. Die einzelnen Halter denken, sie machen legalen Schadensersatz — nur die Werkstatt weiß, dass das System systematisch ausgenutzt wird. Erkennungsmerkmal: Ungewöhnlich hohe Anzahl an Schadensmeldungen, die über eine einzige Werkstatt laufen, in Kombination mit Muster bei Schadenssummen (immer leicht unter Gutachterpflichtgrenze) und Anwaltsauftritten.

Staged-Accident-Ring (inszenierte Unfälle)
Hochprofessionell: Netzwerk aus Statisten, Fahrern, Gutachtern und Anwälten. Unfälle werden bewusst inszeniert — echte Kollisionen unter kontrollierten Bedingungen. Die Beteiligten kennen sich von vorherigen Vorfällen. Im Graphen sichtbar als reziproke Netzwerke: A war Unfallbeteiligter bei B, B bei C, C bei A — triangulierte Verbindungen, die bei echten Zufallsunfällen extrem unwahrscheinlich sind.

Das entscheidende Muster in allen Varianten: Die einzelnen Schadensfälle sind nicht auffällig — die Verbindungsstruktur ist es. Genau das können Graph-Algorithmen erkennen, Einzelfall-Scoring hingegen nicht.

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ GNN-Modelle auf gesundheitsversicherungsspezifischen Datensätzen; F1-Score 82–84 % (Scientific Reports 2025, Nature). ² Eigene Erfahrungswerte auf Basis FRISS-Kundendaten und EWV-Projektbericht Fraunhofer SIT. ³ Abhängig von Qualität der Trainingsdaten und Entity Resolution.

Einschätzung auf einen Blick

Zeitersparnis — hoch (4/5)
Ein SIU-Ermittler, der manuell ein Betrugsnetzwerk kartiert, arbeitet Wochen: Abfragen aus verschiedenen Systemen, händische Kreuztabellen, Postanschriften abgleichen, Gutachterregistrierungen nachschlagen. Ein Graph-System macht das in Minuten — und zeigt dem Ermittler eine klickbare Visualisierung, aus der er direkt Hypothesen ableiten kann. Nicht ganz maximal bewertet, weil die Zeiteinsparung im Wesentlichen für SIU-Mitarbeitende gilt; Sachbearbeitende im ersten Schadenseingang spüren wenig Unterschied in ihrem täglichen Workflow.

Kosteneinsparung — sehr hoch (5/5)
Das ist der stärkste Kostenhebel unter den verglichenen Versicherungs-Anwendungsfällen. Jeder abgebrochene Fraud Ring spart direkt buchbare Beträge — keine indirekten Wirkungen, keine Annahmen über Produktivitätsgewinn. Ein Versicherer mit jährlichem Betrugschaden von zehn Millionen Euro, der durch Graph-Analyse 30 Prozent davon verhindert, spart drei Millionen Euro — im ersten Jahr. Die laufenden Tool- und Betriebskosten liegen selbst im Custom-GNN-Szenario bei einem Bruchteil dieser Summe. Das Höchstwert-Scoring ist hier gerechtfertigt.

Schnelle Umsetzung — sehr niedrig (1/5)
Das ist der schwierigste Einstieg unter den verglichenen Versicherungs-Anwendungsfällen. Entity Resolution (Deduplizierung von Adressen, Werkstätten, Gutachternamen) ist technisch aufwendig. Der Aufbau eines Graphen aus historischen Schadendaten erfordert Datenengineering. Das Training eines überwachten GNN-Modells benötigt ausreichend bestätigte Betrugsfälle als Labels — und die sind oft nicht strukturiert in den Kernsystemen vorhanden. Realistisch: 12–20 Wochen bis zum ersten produktiven Pilot. Wer das unterschätzt, scheitert an der Datenqualität, nicht am Algorithmus.

ROI-Sicherheit — sehr hoch (5/5)
Einer der seltensten 5-Werte in dieser Kategorie — und hier ist die Begründung konkret: Wenn das System einen Betrugsring erkennt und die SIU ihn bestätigt, ist der Wert direkt buchbar — Betragshöhe der gesperrten Regulierungen. Es gibt keinen Interpretationsspielraum (“wurden diese Stunden wirklich eingespart?”), keine indirekten Kausalketten. Der verhinderte Schaden ist der ROI. Das unterscheidet diesen Use Case von fast allen anderen in dieser Kategorie.

Skalierbarkeit — hoch (4/5)
Graph-Algorithmen skalieren gut — mehr Knoten, mehr Kanten, mehr Schadenmeldungen verbessern die Erkennungsqualität, weil das Modell mehr Muster lernen kann. Kein proportionaler Mehraufwand. Nicht ganz maximal bewertet, weil quartalsweises Retraining des GNN-Modells nötig ist, wenn Betrüger ihr Verhalten anpassen (Concept Drift), und weil das Entity-Resolution-Problem mit wachsendem Datenvolumen ebenfalls komplexer wird.

Richtwerte — stark abhängig von Schadensvolumen, Qualität der Stammdaten und verfügbarer SIU-Kapazität.

Was das System konkret macht

Der technische Kern ist eine Graphdatenbank — eine Datenstruktur, die Entitäten als Knoten und Beziehungen als Kanten speichert. In der Versicherungswelt sieht das so aus:

Knoten: Policenhalter, Kfz-Kennzeichen, Werkstätten, Gutachter, Anwälte, Ärzte, Adressen, IP-Adressen aus Online-Anträgen.

Kanten: “Antragsteller X war Unfallbeteiligter bei Schadensfall Y”, “Werkstatt Z hat Gutachten für Schadensfall A und B erstellt”, “Anwalt Q vertritt Antragsteller aus fünf verschiedenen Schadensfällen”.

Sobald dieser Graph aufgebaut ist, laufen Algorithmen darüber:

Community Detection (z.B. Louvain-Algorithmus): Erkennt natürliche Cluster — Gruppen von Knoten, die untereinander stärker verbunden sind als mit dem Rest des Graphen. Ein Ring schlägt sich als Cluster nieder, auch wenn keine direkte Adressgemeinsamkeit vorliegt.

PageRank / Zentralitätsmaße: Identifiziert Knotenpunkte mit ungewöhnlich vielen Verbindungen — die Werkstatt, der Anwalt, der Gutachter, der im Zentrum eines Rings steht.

Graph Neural Networks (GNN): Wenn genügend bestätigte Betrugsfälle als Trainingsdaten vorliegen, lernt ein GNN nicht nur Clusterbildung, sondern auch, welche Verbindungsmuster und Knotenmerkmale statistisch mit Betrug korrelieren. Das Modell gibt dann für jeden neuen Schadensfall einen Wahrscheinlichkeitswert aus — ähnlich dem klassischen Fraud Score, aber angereichert um die Netzwerkinformation.

Das Ergebnis für den Ermittler: Ein Alert “Cluster C47 — 11 Schadensfälle, gemeinsame Werkstatt und Anwalt, anomale Betragsmuster” mit einer klickbaren Graphvisualisierung, in der alle Verbindungen sofort sichtbar sind. Kein manuelles Suchen mehr.

Konkrete Werkzeuge — was wann passt

Es gibt drei grundlegend verschiedene Ansätze, je nach Unternehmensgröße, Datenvolumen und verfügbarer IT-Kapazität.

FRISS Trust Automation — Der schnellste Weg für P&C-Versicherer ohne eigenes Data-Science-Team. FRISS ist speziell für Versicherungsbetrug gebaut — keine generische Fraud-Plattform — und enthält Network Link Analysis out of the box. Die Netzwerkanalyse arbeitet auf Claims-Daten und angereicherten externen Quellen (HIS, Kfz-Register, Sozialdaten). Laut Herstellerangabe produktiv in sechs Monaten. Nachteil: Black Box für das eigene Data-Science-Team, Preise nur auf Anfrage, begrenzt auf 2–3 Hop-Analysen. Empfehlung: Erster Schritt für Versicherer ohne eigene Infrastruktur, Schadensvolumen ab ~100.000 Meldungen/Jahr.

Neo4j Graph Database + eigene Algorithmen — Für Versicherer mit IT-Kapazität und einem oder mehreren Datenanalysten. Neo4j als Graph-Datenbankschicht, Community-Detection-Algorithmen aus dem integrierten Graph Data Science Plugin, visualisierbar mit Neo4j Bloom. Kein eingebautes ML — aber volle Kontrolle über Algorithmen, Daten und Ergebnisinterpretation. AuraDB Professional ab ~65 USD/Monat (reine Datenbankkosten, Implementierungsaufwand intern). Empfehlung: Mittelgroße Versicherer mit Datenteam, die Netzwerkanalyse als eigenständiges Ermittlungswerkzeug betreiben wollen.

Neo4j + PyTorch Geometric (Custom GNN) — Der technisch anspruchsvollste Weg, aber der mit der höchsten Erkennungsgenauigkeit bei ausreichend Trainingsdaten. PyTorch Geometric (PyG) ist die Open-Source-Bibliothek für Graph Neural Networks auf PyTorch-Basis. Sie erlaubt das Training eigener GNN-Modelle auf Versicherungsgraphen — mit kontrollierter Merkmalsdefinition, eigenen Trainingsloop und DSGVO-konformer On-Premise-Verarbeitung. Empfehlung: Großversicherer mit eigenem Data-Science-Team, >5.000 bestätigten Betrugsfällen als Trainingsdaten, Bereitschaft zur 6–12 Monate dauernden Modellentwicklung.

SAS Fraud Management — Wenn du bereits SAS-Infrastruktur im Haus hast oder eine Enterprise-Fraud-Plattform mit breitem Regulierungsnachweis suchst. SAS kombiniert Transaktions-Scoring und Netzwerkanalyse auf einem System. Sehr hohe Implementierungskosten (ab 500.000 EUR/Jahr Lizenz), aber Forrester-Leader und BaFin-konform. Für die meisten mittelgroßen Versicherer nicht wirtschaftlich. Empfehlung: Nur wenn SAS bereits im Haus ist oder das Volumen die Enterprise-Kosten rechtfertigt.

Zusammenfassung: Wann welcher Ansatz

• Schneller Einstieg, kein eigenes Data-Science-Team → FRISS
• Netzwerkanalyse mit eigener IT-Kontrolle → Neo4j
• Maximale Erkennungsgenauigkeit, eigene GNN-Modelle → Neo4j + PyTorch Geometric
• Bereits SAS-Infrastruktur vorhanden → SAS Fraud Management

Datenschutz und Datenhaltung

Versicherungsschadendaten enthalten hochsensible personenbezogene Daten — Namen, Adressen, Fahrzeugdaten, medizinische Diagnosen (bei Kranken- und Unfallversicherung), Kontoverbindungen. Die Verarbeitung dieser Daten durch ein Graph-System unterliegt der DSGVO mit besonderen Anforderungen:

• Grundsatz der Datensparsamkeit: Das Graphmodell darf nur die Datenpunkte verarbeiten, die für die Betrugserkennung tatsächlich notwendig sind. Medizinische Details gehören in der Regel nicht in den Claims-Graph — Verbindungsmuster (Arzt A behandelt Patienten B, C, D aus demselben Schadensfall) reichen.
• Profilierungsverbot: Automatisierte Betrugsbewertungen gelten nach DSGVO Art. 22 als automatisierte Entscheidung mit erheblicher Auswirkung, wenn sie direkt zur Ablehnung eines Schadens führen. Die Lösung: Das System generiert Verdachtsalerts — ein menschlicher SIU-Ermittler trifft die finale Entscheidung. Dokumentiere diesen Human-in-the-Loop ausdrücklich.
• Auftragsverarbeitungsvertrag (AVV): Sowohl FRISS als auch Neo4j (AuraDB) stellen AVV-Vorlagen bereit. Aktiv anfordern und vor Produktivbetrieb unterzeichnen.
• Datenhaltung EU:
  • FRISS: EU-Rechenzentren, DSGVO-konform.
  • Neo4j AuraDB: EU-Region explizit auswählen (Frankfurt/Ireland verfügbar) — standardmäßig US-Hosting.
  • Custom GNN mit PyTorch: vollständig On-Premise möglich, empfohlen für Großversicherer mit Datenschutzbedenken.
• Betroffenenrechte: Das HIS-Register (Hinweis- und Informationssystem der Versicherungswirtschaft) ermöglicht betroffenen Personen Auskunftsansprüche über gespeicherte Betrugsverdachtsmerkmale. Die Einbindung externer Register ist mit dem Datenschutzbeauftragten vorab zu klären.

Empfehlung: Datenschutz-Folgenabschätzung (DSFA) vor dem Launch — bei Versicherern mit Graph-Systemen über Personendaten in dieser Größenordnung in der Regel ohnehin DSGVO-Pflicht (Art. 35).

Was es kostet — realistisch gerechnet

Einrichtungskosten

Der größte Kostenblock liegt nicht in Lizenzen, sondern in der Datenaufbereitung. Entity Resolution — das systematische Deduplizieren von Werkstattnamen, Anwaltsnamen und Adressen aus verschiedenen Schadensystemen — ist Handarbeit und dauert je nach Datenbankqualität vier bis acht Wochen.

• FRISS-Implementierung (inkl. API-Integration Kernsystem): typisch 80.000–200.000 EUR einmalig (Implementierungspartner + FRISS-Consulting)
• Neo4j + eigene Graph-Analytik aufbauen: 40.000–80.000 EUR Entwickleraufwand (Graph-Datenbankschicht, ETL-Pipeline, Visualisierung)
• Custom GNN (Neo4j + PyTorch Geometric, vollständig eigenentwickelt): 150.000–400.000 EUR Entwickleraufwand, inkl. Datenwissenschaftler

Laufende Kosten (monatlich)

• FRISS: Preise auf Anfrage; nach Branchenquellen typisch 5.000–25.000 EUR/Monat bei mittleren Versicherern
• Neo4j AuraDB Professional: ab ~65 USD/Monat Datenbankkosten — dominiert wird der laufende Aufwand von internem Personalaufwand (0,25–0,5 FTE Analysten)
• Custom GNN auf eigener Infrastruktur: 2.000–8.000 EUR/Monat Recheninfrastruktur + Modellbetrieb

Wie du den ROI misst

Die Messung ist direkter als bei fast jedem anderen KI-Use-Case: Du addierst die Schadenssumme aller Fälle, die durch Ring-Alerts gestoppt wurden — das ist der verhinderte Schaden. Setze dagegen die Kosten für False-Positive-Ermittlungen, die kein Betrug ergaben. Die Netto-Einsparung ist dein ROI.

Konservatives Rechenbeispiel:
Ein Versicherer mit 300 Mio. EUR jährlichem Betrugschaden (branchentypisch ~2 % der Prämieneinnahmen bei 15 Mrd. EUR Prämienvolumen) implementiert Neo4j-basierte Ring-Erkennung. Erkennungsquote im ersten Jahr: 15 % aller Ring-Schäden. Verhinderte Schäden: 45 Mio. EUR × Recovery Rate 60 % = 27 Mio. EUR direkte Einsparung. Implementierungskosten: 80.000 EUR einmalig, 300.000 EUR/Jahr laufend. ROI-Faktor: 90:1. Selbst wenn die Erkennungsquote bei 5 % liegt, ist der ROI noch positiv.

Drei typische Einstiegsfehler

1. Entity Resolution wird unterschätzt — und das Projekt scheitert daran.
Der Graph-Algorithmus ist fertig. Das Modell kann Community Detection. Aber die Werkstatt “Auto Müller GmbH” im Schadensystem ist eine andere als “Autohaus Müller” im Kfz-Register, die ihrerseits eine andere als “Müller KFZ-Service” in der Gutachterdatenbank. Ohne normalisierte Identifikatoren über alle Quellen hinweg zeigt der Graph Knotenfriedhöfe statt Netzwerke. Lösung: Entity Resolution zur Hauptaufgabe machen — dedizierte Zeit, dedizierter Datenverantwortlicher, bevor irgendein Algorithmus läuft.

2. Kein Feedback-Loop zwischen SIU und Modell.
Ein GNN-Modell lernt aus bestätigten Betrugsfällen. Wenn die SIU keinen Prozess hat, ihre Ermittlungsergebnisse (Betrug bestätigt / kein Betrug) strukturiert zurück ins System zu schreiben, hört das Modell nach dem initialen Training auf zu lernen. Nach 12 Monaten erkennt es nur noch Betrugstypen, die im Trainingsdatensatz vorhanden waren. Neuartige Ringstrukturen gehen durch. Lösung: Bestätigungsrückmeldung als Pflichtschritt im SIU-Workflow verankern, nicht als Option.

3. Das Modell erkennt Ringe — aber keine SIU-Kapazität zum Ermitteln.
Ein System, das 50 Rindalerts pro Woche erzeugt, ist nur so gut wie das Team, das diese Alerts verfolgen kann. Mehr Alerts als SIU-Kapazität führen zu Prioritätsstau, selektiver Bearbeitung und schließlich dazu, dass Alerts ignoriert werden. Lösung: Alert-Volumen und SIU-Kapazität vor dem Launch abgleichen. Lieber Alertschwellwert erhöhen und dafür höhere Trefferquote als hundert Leads, von denen 90 verfallen.

4. Concept Drift — das Modell wird still schlechter.
Versicherungsbetrüger passen sich an. Wenn ein Ring merkt, dass bestimmte Verbindungsmuster zu Sperren führen, verändert er seine Struktur — mehr Hops zwischen Knoten, andere Werkstatt alle sechs Monate, andere Anwälte im Rotation. Ein GNN-Modell, das auf einem historischen Datensatz trainiert wurde, erkennt diese Variante nicht. Das Modell degradiert still: Die Erkennungsrate sinkt, nicht die Konfidenzwerte — das System wirkt zuverlässig und übersieht neue Muster. Lösung: Modell quartalsweise auf neuen bestätigten Betrugsfällen evaluieren, bei Erkennungsrückgang sofort neu trainieren. Concept Drift als regulären Betriebsparameter behandeln, nicht als Ausnahme.

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

Die technische Einführung ist nicht der schwierige Teil. Das Schwierige ist die organisatorische Anpassung.

Widerstandsmuster 1: SIU verteidigt manuelle Prozesse.
Erfahrene Ermittler haben Intuition entwickelt — sie erkennen manche Ringe durch Mustererfahrung, ohne Algorithmen. Ein System, das automatisch Alerts erzeugt, kann sich anfühlen wie ein Angriff auf diese Expertise. Konkret hilft: Das SIU-Team in die Algorithmusauswahl einbinden — welche Merkmale sollen in die Netzwerkanalyse einfließen? Wenn die Ermittler mitgebaut haben, verteidigen sie das System. Wenn es ihnen übergeben wurde, bekämpfen sie es.

Widerstandsmuster 2: Compliance stoppt Datenzusammenführung.
Du möchtest HIS-Daten, Kfz-Register, interne Schadendaten und externe Sozialdaten im Graphen zusammenführen. Compliance und Datenschutzbeauftragte werden jeden dieser Datenflüsse einzeln prüfen. Das dauert. Plane mindestens sechs bis acht Wochen Abstimmungszeit mit Datenschutz und Compliance ein — bevor ein einziger Knoten im Graphen landet.

Was wirklich funktioniert:
Der stärkste Hebel für Akzeptanz ist ein konkreter Erstfund. Wenn das System in den ersten vier Wochen einen Ring sichtbar macht, den niemand manuell gesehen hätte — und die SIU diesen Ring bestätigt — ändert sich die Stimmung im Raum sofort. Diesen Erstfund als internen Case Study kommunizieren: Wer war beteiligt, wie viel hat er schon reguliert bekommen, wie lange unentdeckt.

Realistischer Zeitplan mit Risikohinweisen

Wer mit FRISS (SaaS-Ansatz) startet statt Custom-GNN zu bauen, kann Phase 3 auf Woche 8–12 vorziehen — aber auch hier gilt: Entity Resolution und Datenqualität bestimmen das Tempo.

Häufige Einwände — und was dahintersteckt

„Wir haben schon ein Fraud-Scoring-System.”
Einzelfall-Scoring und Netzwerkanalyse sind nicht dasselbe — sie erkennen verschiedene Betrugsmuster. Ein klassisches Scoring-System bewertet jeden Fall für sich: Schadensmuster, Antragsteller-Historie, Risikoindikator. Ein Fraud Ring ist so konstruiert, dass jeder Einzelfall normal aussieht. Beide Ansätze nebeneinander zu betreiben ist keine Redundanz, sondern Schichtung: Das Scoring fängt Opportunisten, das Netzwerksystem fängt Profis. Wer nur das eine hat, übersieht das andere. Tatsächlich ist die Kombination aus Einzelfall-Score und Netzwerksignal (kombiniertes Modell) die effektivste Konfiguration — das zeigt auch die Literatur zu Machine-Learning-Ansätzen in diesem Bereich.

„Unsere Daten sind nicht gut genug dafür.”
Das ist die häufigste ehrliche Einschätzung — und sie trifft oft zu. Aber “nicht gut genug” ist kein Ja/Nein-Urteil, sondern eine Frage des Aufwands. Eine Datenqualitätsanalyse (zwei bis drei Wochen) gibt belastbare Auskunft: Wie viele Werkstätten sind in verschiedenen Systemen unter verschiedenen Namen erfasst? Wie viele Schadensfälle haben keinen validen Halteridentifikator? Dieser Aufwand lohnt sich als erstes Investment — er zeigt, ob der Graphansatz grundsätzlich möglich ist oder ob zuerst Stammdatenbereinigung nötig ist. Letzteres lohnt sich ohnehin, unabhängig vom Fraud-Projekt.

„Zu viele False Positives machen das unbrauchbar.”
False Positives sind kein Systemversagen, sondern ein Kalibrierungsproblem. Kein Fraud-Ring-System der Welt hat null False Positives — die Frage ist, ob die echten Funde den Ermittlungsaufwand für falsche Alerts überwiegen. Bei einem Ring, der 500.000 Euro verursacht hat, lohnt es sich, zehn False Positive Leads zu verfolgen, um ihn zu finden. Bei einem Ring für 20.000 Euro nicht. Die Alertschwellwerte müssen nach Schadensgröße und SIU-Kapazität justiert werden — das ist keine Schwäche des Ansatzes, sondern normales Systemtuning. FRISS enthält solche Kalibrierungsoptionen standardmäßig.

Woran du merkst, dass das zu dir passt

• Du hast ein SIU-Team, das manuell Betrugsverdachtslagen kartiert — und der größte Engpass ist die Zeit für die Recherche, nicht die Ermittlungsqualität
• Deine Betrugserkennungsquote stagniert, obwohl du Einzelfall-Scoring verwendest — du ahnst, dass koordinierter Betrug durch das Raster fällt, kannst es aber nicht belegen
• Dein Kernsystem enthält normalisierte Drittpartei-Identifikatoren (Werkstattnummern, Anwaltsbarcodes aus dem Anwaltsregister, Gutachter-IDs) — die Grundvoraussetzung für einen belastbaren Graphen
• Du hast mindestens 200.000 Schadenmeldungen pro Jahr — bei weniger ist die Graphdichte zu dünn für statistisch belastbare Cluster
• Du kannst auf historische bestätigte Betrugsfälle zugreifen — idealerweise 2.000+ dokumentierte Fälle, ohne die ein überwachtes GNN-Modell nicht sinnvoll trainiert werden kann

Wann es sich noch nicht lohnt — drei harte Ausschlusskriterien:

1. Weniger als 150.000 Schadenmeldungen pro Jahr. Bei zu kleinem Schadensvolumen ist der Graph zu dünn. Community-Detection-Algorithmen finden statistisch bedeutsame Cluster erst ab einer bestimmten Datendichte. Unter dieser Schwelle produziert das System zu viele zufällige Schein-Cluster. Für kleinere Versicherer ist ein spezialisierter externer Dienstleister, der Branchennetzwerkdaten aggregiert, der effizientere Weg.

2. Keine dokumentierten bestätigten Betrugsfälle im Kernsystem. Ein GNN-Modell lernt aus bestätigtem Betrug. Wenn die SIU Ermittlungsergebnisse nicht strukturiert ins System zurückschreibt — sondern in Excel-Tabellen oder Word-Dokumenten führt —, gibt es keine Trainingsdaten. Zuerst den Feedback-Loop implementieren; erst dann über GNN nachdenken. Mit FRISS ist ein vorab trainiertes Branchenmodell verfügbar, das dieses Problem überbrückt — aber auch da gilt: ohne laufendes Feedback verschlechtert sich die Erkennungsqualität über Zeit.

3. Keine dedizierte Ressource für Modellwartung und Alert-Betrieb. Ein Graphsystem, das eingerichtet und dann sich selbst überlassen wird, degradiert — Concept Drift sorgt dafür, dass die Erkennungsrate nach 12–18 Monaten signifikant sinkt, ohne dass jemand es merkt. Ohne eine Person, die das System quartalsweise evaluiert und Modelle nachtrainiert, ist die langfristige Wirkung begrenzt.

Das kannst du heute noch tun

Mach eine Netzwerkprobe auf deinen eigenen Daten — kostenlos, ohne Infrastruktur, in zwei Stunden.

Exportiere aus deinem Schadensystem die letzten drei Jahre Kfz-Schadensmeldungen mit folgenden Feldern: Schadensnummer, Antragsteller-ID, beteiligte Kfz-Kennzeichen, Werkstatt-Name, Anwaltsname (falls vorhanden), Schadendatum, Schadensbetrag. Lädt du diese CSV in Neo4j AuraDB Free (kostenlos, sofort nutzbar) und verbindest Antragsteller mit Werkstätten und Anwälten als Kanten, kannst du mit dem folgenden Cypher-Query sofort erste Muster sehen:

MATCH (w:Werkstatt)<-[:REPARIERT_BEI]-(s1:Schaden)
MATCH (w)<-[:REPARIERT_BEI]-(s2:Schaden)
WHERE s1 <> s2
MATCH (a:Anwalt)<-[:VERTRETEN_VON]-(s1)
MATCH (a)<-[:VERTRETEN_VON]-(s2)
RETURN w.name, a.name, count(*) AS gemeinsame_faelle
ORDER BY gemeinsame_faelle DESC
LIMIT 20

Was du damit sofort siehst: Welche Werkstatt-Anwalt-Kombinationen wie oft gemeinsam in Schadensfällen auftauchen. Zehn Fälle mit derselben Werkstatt und demselben Anwalt sind ein Signal, das manuelle Überprüfung verdient.

Das ist kein Produktionssystem. Es ist ein Machbarkeitstest — und er kostet nichts außer zwei Stunden Datenexport und Datenbankeinrichtung.

Wenn du lieber mit einem strukturierten Prompt starten willst, um einen ersten Analyserahmen aufzubauen:

Quellen & Methodik

• Schadensvolumen Deutschland 6 Mrd. EUR/Jahr: Gesamtverband der Deutschen Versicherungswirtschaft (GDV), Pressemitteilung „Versicherungsbetrug verursacht Schäden von über sechs Milliarden Euro im Jahr” (gdv.de). Jede zehnte Schadenmeldung gilt als Betrugsverdacht — ebenfalls GDV.
• 40 % Erkennungsquote Fraunhofer-Prototyp: EWV-Projekt (Erkennung von Wirtschaftskriminalität und Versicherungsbetrug), Fraunhofer SIT Darmstadt und Bitkom, Abschlussbericht 2020 (sifo.de / bitkom.org). Prototyp bei einem fränkischen Versicherer eingesetzt.
• GNN F1-Score 82–84 % auf Versicherungsdaten: Qian et al. (2025), „Fraud detection and explanation in medical claims using GNN architectures”, Scientific Reports / Nature. Heterogene GNN-Architekturen auf gesundheitsversicherungsspezifischen Datensätzen.
• 19,7 % Recall-Gewinn, 33 % False-Positive-Reduktion: RL-GNN-Fusionsansatz, PMC (PubMed Central) 2025, „Reinforcement learning with GNN fusion for real-time financial fraud detection”.
• Concept Drift als Versagensmodus: Chen et al. (2023), „Detecting Concept Drift in Financial Fraud Using Temporal Graph Neural Networks”, ResearchGate; bestätigt durch Expert Systems with Applications Systematic Review (2023), doi:10.1016/j.eswa.2023.122156.
• Neo4j AuraDB Preise: Neo4j offizielle Preisseite neo4j.com/pricing (Stand April 2026), AuraDB Professional ab ~65 USD/Monat.
• FRISS: FRISS-Website friss.com und Microsoft AppSource-Eintrag; 175+ Versicherer, 40+ Länder, SaaS-Modell (Stand April 2026).
• Anatomie Fraud Rings: Bitkom/SIT-Projektbericht; FRISS-Blog „Die 4 häufigsten Arten von Versicherungsbetrug” (friss.com/de); AWS Architecture Blog „Fraud ring detection using Neo4j and graphs” (aws.amazon.com).