Eine synthetische Identität wird aus echten Bestandteilen zusammengesetzt: einem gültigen Namen, einem Geburtsdatum, einer real existierenden Adresse, oft einer echten Steuer- oder Personalausweisnummer, die jemandem gehört, der nie etwas davon mitbekommt. Klassisches KYC prüft jedes Feld gegen seine Quelle, und jedes einzelne Feld besteht. Um den Betrug bei der Antragstellung zu erkennen, bewertet man die Beziehungen zwischen diesen Komponenten und die Historie dahinter, nicht die Komponenten selbst.
Diese Neubetrachtung verändert, was man baut. Dokumentenprüfung und Datenbankabgleiche beantworten, ob die Daten gültig sind. Die Erkennung synthetischer Identitäten muss eine schwierigere Frage beantworten: Steht hinter diesem Antrag ein einzelner realer Mensch, und existiert dieser Mensch kohärent seit länger, als der Betrugsring ihn gebraucht hätte? Der größte Teil des Signals steckt in dieser zweiten Frage, und fast nichts davon steckt in den Feldern des Formulars.
Warum die Einzelteile bestehen, die Person aber nicht
Die Ökonomie dahinter ist einfach. Ein Ring kultiviert eine synthetische Identität über Monate, manchmal Jahre. Er eröffnet eine kleine besicherte Kreditkarte, leistet Zahlungen, wird an die Auskunfteien gemeldet und lässt eine dünne, aber saubere Akte anwachsen. Wenn er dann echten Kredit beantragt, sieht die Identität aus wie ein junger Kunde mit geringem Risiko und kurzer Historie. Anschließend folgt der Bust-out: Der Ring reizt jede Linie bei mehreren Kreditgebern in einem engen Zeitfenster bis zum Limit aus und verschwindet. Kein Opfer ruft an, um etwas zu bestreiten, weshalb der Verlust als First-Party-Fraud gebucht und häufig fälschlich als gewöhnlicher Kreditausfall codiert wird.
Die Anzeichen sind struktureller Natur, und man findet sie, indem man über Anträge hinweg schaut statt in einen einzelnen hinein.
- Geteilte Attribute über vermeintlich verschiedene Personen hinweg. Eine Telefonnummer, ein Gerät oder ein Bankkonto, das an viele Identitäten gebunden ist. Eine Adresse, die ein Cluster dünner Akten verankert, die alle innerhalb weniger Wochen voneinander eröffnet wurden.
- Eine Historie, die zu abrupt beginnt. Eine Kreditakte mit einer Spur harter Anfragen, aber ohne Vorgeschichte: keine alte Versorger-Spur, keine Adress-Zeitleiste, kein Beschäftigungsnachweis, der der ersten Zeile der Akte vorausgeht.
- Kennzeichen-Diskrepanzen, die einzeln durchgehen. Ein Name und eine Personalausweisnummer, die getrennt verifiziert werden, deren Ausstellungsdaten, Alter und Adress-Zeitleiste sich aber nicht zu einem plausiblen einzelnen Lebenslauf zusammenfügen.
- Velocity, die ein echter Antragsteller nicht erzeugt. Dieselbe Identität, oder leichte Permutationen davon, die in einem komprimierten Zeitfenster über den eigenen Funnel und über Konsortialdaten hinweg auftaucht.
Keines dieser Signale ist für sich allein entscheidend. Ein echter Mensch kann umziehen, das Telefon wechseln und eine dünne Akte haben. Aufgabe des Modells ist es, die Kombination gegen ein Falsch-Positiv-Budget abzuwägen, denn jede als synthetisch markierte Identität steht neben einem echten Antragsteller mit dünner Akte, den man lieber genehmigen würde.
Die Datenschicht, die das wirklich braucht
Das Modell ist der einfache Teil. Der schwierige Teil ist, Features zusammenzustellen, die zum Entscheidungszeitpunkt korrekt sind und die eine Identität über das gesamte Buch hinweg beschreiben, nicht über ein einzelnes Formular. Zwei Probleme dominieren.
Erstens Entity Resolution. Man kann nicht berechnen, wie viele Identitäten sich ein Gerät teilen, wenn man nicht entscheiden kann, wann zwei Datensätze dasselbe Gerät, dieselbe Adresse oder dasselbe Bankkonto sind. Normalisierung und Fuzzy Matching bauen den stabilen Identitätsgraphen, der unter jedem Velocity- und Shared-Attribute-Feature liegt. Ist dieser Graph schwach, sind die besten Signale nur Rauschen. Es ist dasselbe Resolution-Problem, das über Finanzdaten-Feeds hinweg auftaucht, hier nur auf Antragsteller gerichtet.
Zweitens Point-in-Time-Korrektheit. Betrugslabels kommen verspätet. Ein Konto wird erst nach dem Bust-out als synthetisch bestätigt, manchmal sechs Monate nach der Buchung. Wenn man auf heute berechneten Features trainiert und sie mit einem Antrag vom vergangenen Frühjahr verknüpft, sickert Information aus der Zukunft in die Vergangenheit. Der Graph, den man abfragt, muss so rekonstruiert werden, wie er zum Zeitpunkt jener Entscheidung war. Jedes Feature im Store braucht einen As-of-Zeitstempel, und jede Trainingszeile muss den Graphen zu ihrem eigenen Antragszeitpunkt lesen. Lässt man das weg, sieht die Offline-AUC hervorragend aus, während das Produktionsmodell nichts fängt, weil es klammheimlich die Zeitung von morgen gelesen hat.
Ein paar Dinge, an die wir uns beim Bau der Pipeline halten:
- Lineage auf jedem Feature, damit eine ablehnende Entscheidung erklärt und ihr Prüfpfad rekonstruiert werden kann. Betrugsablehnungen unterliegen weiterhin der Fair-Lending-Prüfung; eine ablehnende Entscheidung, die man nicht erklären kann, ist eine, die man unter ECOA und Regulation B nicht verteidigen kann.
- Eine ehrliche Label-Policy. Unterscheide zwischen bestätigt synthetisch, bestätigtem First-Party-Bust-out und gewöhnlicher Abschreibung. Wirft man sie zusammen, trainiert man das Modell darauf, Kreditrisiko statt Betrug vorherzusagen.
- Eval-Sets, die um das Bust-out-Fenster herum aufgebaut sind, nicht um einen zufälligen Split. Ein zeitbasierter Split, der die jüngsten Kohorten zurückhält, ist der einzige Test, der der Produktion ähnelt.
Scoring bei der Buchung, Monitoring danach
Am Ende betreibt man zwei Modelle gegen ein Problem. Der Score zum Antragszeitpunkt sitzt im Straight-Through Processing und lebt unter einem harten Latenzbudget; er stützt sich auf Graph- und Velocity-Features, die günstig auszuliefern sind, plus Signale aus der dünnen Kredithistorie der Auskunftei. Sein Precision-Ziel wird davon bestimmt, wie viele manuelle Prüfungen das Team verkraften kann, weshalb der Schwellenwert ebenso eine Geschäfts- wie eine statistische Entscheidung ist.
Das zweite Modell überwacht gebuchte Konten auf das Bust-out-Muster: koordinierte Auslastungsspitzen, Zahlungsverhalten, das sich über ein Cluster geteilter Attribute hinweg im Gleichschritt verschiebt, Erstzahlungsausfälle gehäuft nach Gerät oder Adresse. Hier werden synthetische Identitäten gefangen, die durch die Vordertür gekommen sind, bevor der Verlust eintritt. Es erzeugt zugleich die Labels, die das Buchungsmodell im nächsten Quartal besser machen, weshalb sich beide einen Feature Store und eine Resolution-Schicht teilen müssen, statt in getrennten Stacks zu leben.
Drift ist hier wichtiger als bei den meisten Modellen. Ringe ändern ihre Taktik in dem Moment, in dem ein Signal aufhört zu funktionieren, sodass ein Feature, das im letzten Quartal Gewicht hatte, ohne Vorwarnung flach werden kann. Überwache Feature-Verteilungen und segmentweise Precision kontinuierlich, und behandle eine plötzliche Änderung der Genehmigungsrate in irgendeinem Thin-File-Segment als etwas, das zu untersuchen ist, und nicht als Zahl, die man feiert.
Häufige Fragen
Warum rutscht Betrug mit synthetischen Identitäten durch die üblichen KYC-Prüfungen?
Jede Komponente einer synthetischen Identität ist ein echter, verifizierbarer Datenpunkt, deshalb bestehen Dokumenten- und Datenbankprüfungen problemlos. Was scheitert, ist die Beziehung zwischen den Komponenten: Die Identität hat keine kohärente Historie und keinen Nachweis, dass über die Zeit hinweg eine einzelne reale Person dahintersteht.
Lässt sich eine synthetische Identität bereits bei der Antragstellung erkennen, oder erst nach dem Ausfall?
Einen erheblichen Anteil lässt sich schon bei der Antragstellung erkennen, vor allem über Velocity, Graphen geteilter Attribute und Signale aus dünnen Kredithistorien. Der Rest wird erst während eines Bust-out-Fensters sichtbar, deshalb müssen ein Score zum Buchungszeitpunkt und ein Modell zur Portfolioüberwachung zusammenarbeiten.
Was ist der größte Datenfehler, den Teams beim Bau dieser Modelle machen?
Leakage aus Labels, die erst nach der Buchung vergeben wurden, und Features, die mit Daten berechnet wurden, die zum Entscheidungszeitpunkt noch gar nicht existierten. Beides bläht die Offline-Metriken auf und bricht in der Produktion zusammen. Point-in-Time-Korrektheit im Feature Store ist die mit Abstand wichtigste Kontrolle.