Warum Underwriter in der Versicherung einem einzelnen Antragsdatensatz nicht trauen können

Kurzfassung: Ein einzelner Versicherungsantrag ist eine Aussage über eine Person zu einem Zeitpunkt – keine verlässliche Sicht auf deren Historie über Angebote, Policen, Schäden, Fahrzeuge, Dienstleister und Kontaktdaten hinweg. Entity Resolution verknüpft Datensätze bereits bei der Ingestion, sodass Underwriting- und Schadensysteme aktuellen, erklärbaren Kontext abfragen können, ohne ein einzelnes gemeinsames Feld als Identitäts- oder Betrugsnachweis zu behandeln.

Prüfen Sie den Identitätslayer hinter Ihrem Underwriting-Prozess. Demo buchen oder Tilores Studio kostenlos testen.

Ein Antrag kann vollständig und trotzdem irreführend sein. Der Name kann anders geschrieben sein als in einer früheren Police. Die Adresse kann neu sein. Eine Telefonnummer kann zu einem ganzen Haushalt gehören. Bei einer Führerscheinnummer kann die ausstellende Behörde fehlen. Ein Anspruchsteller, ein Fahrzeug, eine Werkstatt, ein Dienstleister oder ein Anwalt kann bereits an anderer Stelle unter einem anderen Datensatz auftauchen.

Underwriter brauchen nicht mehr Vertrauen in das Formular. Sie brauchen einen kontrollierten Weg, um festzustellen, welche Datensätze sich auf dieselbe Person beziehen und welche lediglich miteinander in Beziehung stehen. Diese Unterscheidung zählt, bevor eine Police gezeichnet wird – und sie zählt erneut, wenn ein Schaden gemeldet wird.

Warum kann ein Underwriter einem einzelnen Antragsdatensatz nicht trauen?

Ein Underwriter kann einen einzelnen Antragsdatensatz nicht als vollständige Identität behandeln, weil dieser Datensatz nur eine Quelle, ein Schema und einen Zeitpunkt abbildet.

Der Antrag mag für sich genommen korrekt sein. Er kann trotzdem nicht zeigen, ob der Antragsteller früher schon einmal unter einer anderen E-Mail-Adresse ein Angebot eingeholt hat, nach einer Namensänderung in einer älteren Police auftaucht, sich eine Adresse mit einem anderen Versicherungsnehmer teilt oder über ein Fahrzeug oder eine Kontaktangabe mit einem früheren Schaden verbunden ist. Diese Fakten liegen in anderen Datensätzen.

Ein starker Identifikator löst nicht jeden Fall. Führerscheinnummern können an eine Jurisdiktion gebunden sein. Telefonnummern und E-Mail-Adressen ändern sich oder werden neu vergeben. Namen, Daten und Postleitzahlen enthalten Tippfehler. Haushaltsmitglieder teilen sich Kontaktdaten. Ein sauberer exakter Abgleich kann die Person verfehlen, während ein zu weiter unscharfer Abgleich zwei Personen zusammenführt, die getrennt bleiben müssten.

Entity Resolution behandelt den Antrag als zu verknüpfenden Beleg, nicht als fertige Kundenwahrheit. Tilores wendet konfigurierte deterministische Regeln, Fuzzy Matching und probabilistisches Scoring an, sobald Datensätze eingelesen werden. Die entstehende Entität hat eine dauerhafte ID, verknüpfte Quelldatensätze und Graphkanten, die erklären, wie die Datensätze zusammenhängen. Die Underwriting-Anwendung fragt diesen aktuellen, aufgelösten Kontext ab.

Was ändert sich, wenn Datensätze vor dem Underwriting aufgelöst werden?

Die Auflösung vor dem Underwriting verschiebt die Prüfeinheit von einer einzelnen Antragszeile zu einer Entität mit Quellbelegen.

Frage	Einzelner Antragsdatensatz	Aufgelöster Entitätskontext
Wer stellt den Antrag?	Die im aktuellen Formular behauptete Identität	Eine dauerhafte Entität, verknüpft über freigegebene Quelldatensätze hinweg
Ist diese Person schon einmal aufgetaucht?	Nur wenn ein harter Identifikator auf dieselbe Weise übereinstimmt	Deterministische Regeln, Fuzzy Matching und probabilistisches Scoring können geänderte und fehlerbehaftete Datensätze verbinden
Welche Angaben widersprechen sich?	Widersprüche bleiben in anderen Systemen verborgen	Quelldatensätze bleiben zur Prüfung sichtbar
Welche Beziehungen sind relevant?	Gemeinsame Adressen, Fahrzeuge, Dienstleister und Kontakte wirken isoliert	Graphkanten legen Verbindungen offen, ohne jeden verwandten Datensatz zur selben Person zu erklären
Was erhält das Entscheidungssystem?	Einen Antrag als Momentaufnahme	Den aktuellen aufgelösten Kontext nach der Ingestion

Das heißt nicht, dass jedes Feld zum Golden Fact wird. Die Quelldatensätze bleiben wichtig. Je nach Feld und Produkt braucht ein Underwriter den aktuellsten Wert, die vertrauenswürdigste Quelle, sämtliche beobachteten Werte oder eine Konfliktmarkierung. Der Identitätslayer sollte genug Belege bewahren, damit diese Wahl möglich ist.

Tilores steht neben Bestandsführung, Schadensystemen, MDM, Data Warehouse und Entscheidungssystemen. Es ersetzt weder deren Regeln noch Tarifierung, Governance oder Fallbearbeitung. Es liefert den aufgelösten Personen- und Beziehungskontext, den diese Systeme brauchen.

Welche Identifikatoren sollte ein Identitätsmodell in der Versicherung vergleichen?

Ein Identitätsmodell in der Versicherung sollte mehrere unabhängige Identifikatoren vergleichen und die Regelformen auf Produkt, Jurisdiktion und Datenqualität abstimmen.

Für eine Person können Name, Geburtsdatum, Adresse, Postleitzahl, E-Mail, Mobilnummer, Führerscheinnummer samt ausstellender Jurisdiktion und freigegebene nationale Identifikatoren nützlich sein. Für einen Schaden kann das Modell zusätzlich schadenspezifische Felder und Felder unterstützender Entitäten vorhalten: Policennummer, Fahrzeug-Identifizierungsnummer, Dienstleisterkennung, Werkstattkennung, Anwaltskennung und Schadensort.

Diese Felder erfüllen nicht alle denselben Zweck. Eine Schadennummer identifiziert einen Schaden, nicht einen Anspruchsteller. Ein Fahrzeug identifiziert einen beteiligten Gegenstand, nicht automatisch dessen Fahrer. Eine gemeinsam genutzte Mobilnummer kann eine Analystensuche stützen, ist aber zu schwach, um jeden Datensatz zusammenzuführen, der sie verwendet. Eine Führerscheinnummer ist sicherer, wenn sie mit der ausstellenden Jurisdiktion und einem weiteren bestätigenden Feld kombiniert wird.

Der produktive Regelsatz sollte deshalb mehrere unterschiedlich geformte Verknüpfungsregeln nutzen. Eine Regel kann Geburtsdatum, Führerscheinnummer und Jurisdiktion kombinieren. Eine andere Geburtsdatum, E-Mail und einen unscharfen Nachnamen. Ein Rückfall ohne starken Identifikator kann Geburtsdatum, exakten Nachnamen, Postleitzahl und unscharfen Vornamen verbinden. Konsistenzregeln können eine Zusammenführung blockieren, wenn verlässliche Felder einander widersprechen.

Das Ziel ist nicht die größtmögliche Entität. Das Ziel ist die richtige Entität.

Wie unterstützt Entity Resolution das Underwriting, ohne die Entscheidung zu treffen?

Entity Resolution unterstützt das Underwriting, indem sie aktuelle Identitäts- und Beziehungsbelege zurückgibt; über Annahme, Tarifierung und Vorlagepflicht entscheidet weiterhin das Underwriting-System.

Der Ablauf ist unkompliziert:

1. Der Antragsdienst übermittelt den neuen Antragsdatensatz über die Tilores GraphQL API.
2. Tilores löst diesen Datensatz bei der Ingestion mit den konfigurierten Regeln auf und führt ihn zusammen.
3. Der Underwriting-Dienst fragt die aktuelle Entität über die Quelldatensatz-ID, die Entitäts-ID oder freigegebene Suchparameter ab.
4. Der Entscheidungsprozess prüft die zurückgegebenen Datensätze, Kanten, Scores, Treffer und relevanten verbundenen Entitäten.
5. Der Versicherer wendet Produktregeln, Risikomodelle, Datenberechtigungen und menschliche Prüfung an.

Diese Grenze schützt Erklärbarkeit und Verantwortlichkeit zugleich. Der Entitätslayer kann zeigen, warum Datensätze verknüpft wurden. Das Underwriting-Modell kann zeigen, wie dieser Kontext die Entscheidung beeinflusst hat. Keine der beiden Schichten muss so tun, als hätte sie die Aufgabe der anderen übernommen.

Es unterstützt außerdem die Korrektur. War eine frühere Zusammenführung falsch, kann ein kontrolliertes Auftrennen die Entität reparieren. Ändert sich ein Quelldatensatz oder wird er entfernt, kann sich der Entitätsgraph aktualisieren. Die nächste Abfrage liefert den aktuellen Kontext, statt die Identität aus einer neuen Zeilenauswahl wieder aufzubauen.

Worin unterscheidet sich Betrug im Underwriting von Betrug im Schadenfall?

Betrug im Underwriting betrifft die Identität und die Angaben, die vor der Deckung präsentiert werden; Betrug im Schadenfall betrifft die Personen, Gegenstände, Dienstleister und Ereignisse, die nach einem Schaden präsentiert werden.

Prozess	Identitätsfrage	Nützlicher aufgelöster Kontext	Entscheidungsverantwortung
Angebot und Antrag	Ist dieser Antragsteller schon einmal unter geänderten Angaben aufgetreten?	Frühere Angebote, Policen, Kontakthistorie und Entitätsbelege	Underwriting und Betrugskontrollen
Vertragsänderung	Gehört die gewünschte Änderung zum aktuellen Versicherungsnehmer?	Aktuelle Personenentität, freigegebene Kontakte und zugehörige Policen	Bestandsführung und Authentifizierung
Schadenmeldung	Welcher Anspruchsteller, welche Police, welches Fahrzeug und welches Ereignis gehören zusammen?	Aufgelöster Anspruchsteller und verbundene Policen- oder Objektdatensätze	Schadenannahme
Schadenermittlung	Tauchen Dienstleister, Werkstätten, Fahrzeuge, Kontakte oder Anwälte fallübergreifend wiederholt auf?	Fallübergreifender Entitäts- und Beziehungsgraph	Betrugsermittlung und Fallmanagement
Laufende Überprüfung	Haben neue Belege die Entität oder die Beziehungen verändert?	Aktueller aufgelöster Kontext nach jedem neuen Ingestion-Ereignis	Underwriting-, Schaden- und Compliance-Teams

Die Schadenermittlung profitiert von der Graphstruktur, weil organisierter Betrug sich selten in einer einzigen Anspruchstellerzeile abbildet. Eine Telefonnummer, Adresse, ein Fahrzeug, ein Dienstleister, ein Zahlungsmittel, eine Werkstatt oder ein Anwalt kann über ansonsten getrennte Schäden hinweg wiederkehren. Das nützliche Signal ist das Muster und der Beleg dafür, nicht das Vorhandensein eines einzelnen gemeinsamen Feldes.

Unser Leitfaden zur Betrugserkennung mit Entity Resolution und Graph Neural Networks beschreibt, wie Graphanalyse auf aufgelösten Entitäten aufsetzen kann. Entity Resolution bereitet den Graphen auf. Was das Muster bedeutet, entscheidet ein Betrugsmodell, eine Regel-Engine oder ein Ermittler.

Gegen welche False Positives sollten Versicherer bewusst designen?

Versicherer sollten gegen das Über-Zusammenführen rechtmäßiger Personen designen, die sich verbreitete oder haushaltsbezogene Identifikatoren teilen.

Familien teilen sich Adressen. Paare teilen sich Telefonnummern. Fuhrparks teilen sich Fahrzeuge und Firmenkontakte. Ärztenetze teilen sich Dienstleisterangaben. Werkstattnetze teilen sich Unternehmensdaten. Häufige Namen und Geburtsdaten kollidieren. Verknüpft eine Regel allein über einen gemeinsamen Anker, kann das System verwandte Personen zu einer Entität zusammenfallen lassen und jede nachgelagerte Entscheidung vergiften.

Die Gegenmaßnahme ist Bestätigung durch mehrere Quellen. Starke Verknüpfungsregeln kombinieren unabhängige Felder. Suchregeln dürfen weit genug bleiben, um eine Gruppe zu finden, ohne diese Gruppe zu einer Person zu machen. Konsistenzregeln blockieren Zusammenführungen, die verlässlichen Identitätsfeldern widersprechen. Die menschliche Prüfung übernimmt den unklaren Mittelbereich.

Das ist in regulierten Entscheidungen besonders wichtig. Eine Beziehung kann einen genaueren Blick rechtfertigen, ist aber kein Betrugsnachweis. Das System sollte die Datensatz-IDs, Feldbelege, Graphkanten und Match-Scores hinter der Beziehung offenlegen. Prüfer müssen zwischen „dieselbe Person“, „verwandte Person“ und „gemeinsames Attribut“ unterscheiden können.

Wie fügt sich der aufgelöste Kontext neben Kredit-, KYC- und Policensystemen ein?

Der aufgelöste Kontext speist bestehende Kredit-, KYC-, Policen-, Schaden- und Datensysteme, statt sie zu ersetzen.

Ein Versicherer nutzt womöglich bereits einen Kundenstamm, eine Bestandsführungsplattform, ein Data Warehouse, Betrugsregeln, KYC-Prüfungen und externe Daten. Jedes System hat eine andere Sicht und eine andere Aufgabe. Tilores stellt eine dedizierte Auflösungsschicht bereit, die diese Datensätze zu dauerhaften Entitäten verbinden und das aktuelle Ergebnis über GraphQL zurückgeben kann.

Das Muster ähnelt dem für Verbraucherkreditdaten. Die Quellhistorie muss verfügbar bleiben, das Matching muss fehlerbehaftete Datensätze verkraften, und die daraus folgende Entscheidung bleibt außerhalb der Auflösungsschicht. Wo die Kundenprüfung nach dem Onboarding weiterläuft, zeigt Perpetual KYC, warum frischer Entitätskontext immer dann zählt, wenn neue Informationen eintreffen.

Für die Versicherung ist das praktische Ergebnis Kontinuität. Underwriter, Schadenbearbeiter, Betrugsermittler und Kundenservice können mit derselben Entitäts-ID arbeiten und sehen dabei weiterhin die Quellbelege, die für ihren eigenen Prozess relevant sind.

Was sollte ein Versicherer in einer Evaluierung testen?

Ein Versicherer sollte Identitätsgenauigkeit, Beziehungsqualität, Korrekturverhalten und Abfragenutzen an repräsentativen Datensätzen testen.

Beginnen Sie mit bekannten Übereinstimmungen und bekannten Nicht-Übereinstimmungen. Nehmen Sie Namensänderungen, Tippfehler, alte Adressen, gemeinsame Haushalte, wiederverwendete Telefonnummern, an Jurisdiktionen gebundene Führerscheinnummern, mehrere Fahrzeuge, wiederkehrende Dienstleister und bewusst widersprüchliche Felder auf. Ergänzen Sie frühere Policen und Schäden, damit der Test Kontinuität misst und nicht nur die Deduplizierung innerhalb der aktuellen Antragsakte.

Messen Sie falsche Zusammenführungen und verpasste Verknüpfungen getrennt. Prüfen Sie, welche Regeln ausgelöst haben. Kontrollieren Sie, ob die GraphQL-Antwort die Entitäts-ID, Quelldatensätze, Kanten, Scores und Felder liefert, die der nachgelagerte Prozess braucht. Korrigieren Sie dann eine falsche Zusammenführung, trennen Sie die Entität auf, lesen Sie einen neuen Datensatz ein und prüfen Sie, ob die nächste Abfrage den aktualisierten Kontext zurückgibt.

Halten Sie schließlich die Entscheidungsgrenze sichtbar. Die Evaluierung sollte belegen, dass der Identitätslayer erklärbaren Kontext liefert. Sie sollte einen erfolgreichen Abgleich nicht als Ersatz für das Urteil des Underwritings oder für einen Betrugsbefund verwenden.

FAQ

Warum ist ein einzelner Versicherungsantrag keine verlässliche Kundensicht?

Er enthält nur die Felder, die ein Prozess zu einem Zeitpunkt erhoben hat. Er kann weder frühere Datensätze unter geänderten Angaben zeigen noch Widersprüche zwischen Quellen oder Beziehungen zu Policen, Schäden, Fahrzeugen und beteiligten Parteien, die anderswo geführt werden.

Entscheidet Entity Resolution, ob ein Antragsteller betrügt?

Nein. Entity Resolution verknüpft und trennt Datensätze, pflegt den Entitätskontext und legt Belege offen. Wie mit diesem Kontext umzugehen ist, entscheiden Underwriting-Regeln, Betrugsmodelle, Fallsysteme und menschliche Prüfer.

Wann löst Tilores einen Versicherungsantragsteller auf?

Tilores löst den Antragsdatensatz bei der Ingestion auf und führt ihn zusammen. Das Underwriting- oder Schadensystem ruft den aktuellen aufgelösten Kontext anschließend über eine GraphQL-Abfrage ab.

Darf ein Versicherer Datensätze über eine gemeinsame Telefonnummer verknüpfen?

Eine gemeinsame Telefonnummer kann Suche oder Ermittlung stützen, sollte Personen aber normalerweise nicht allein zusammenführen. Haushalte, Unternehmen und neu vergebene Nummern erzeugen Kollisionen, deshalb brauchen Verknüpfungsregeln bestätigende Felder.

Was ist der Unterschied zwischen einer Entität und einer Beziehung?

Eine Entität gruppiert Datensätze, die sich auf dieselbe Person, dasselbe Unternehmen oder denselben Gegenstand beziehen. Eine Beziehung verbindet getrennte Entitäten – etwa einen Anspruchsteller mit einem Fahrzeug oder einen Dienstleister mit mehreren Schäden –, ohne sie für dasselbe zu erklären.

Wie hilft Entity Resolution Teams in der Schadenbetrugsermittlung?

Sie verbindet Datensätze zu Anspruchstellern, Policen, Fahrzeugen, Dienstleistern, Werkstätten, Kontakten und weiteren freigegebenen Quellen über Schäden hinweg. Ermittler können dann wiederkehrende Entitäten und gemeinsame Beziehungen samt den zugrunde liegenden Quellbelegen prüfen.

Ersetzt Tilores die Bestandsführung oder das Schadenfallmanagement?

Nein. Tilores steht als Entity-Resolution-Schicht neben diesen Systemen. Policensysteme führen den Vertragsstand, Schadensysteme die Fallbearbeitung und Betrugssysteme die Alerts und Entscheidungen.

Was sollte eine Underwriting-Evaluierung umfassen?

Verwenden Sie repräsentative, unsaubere Daten mit bekannten Übereinstimmungen und Nicht-Übereinstimmungen. Testen Sie gemeinsame Haushalte, geänderte Identifikatoren, widersprüchliche Felder, frühere Policen, Schadenbeziehungen, falsche Zusammenführungen, verpasste Verknüpfungen, Korrekturverhalten und den GraphQL-Kontext, der an den Entscheidungsprozess zurückgegeben wird.