Third-Party-Betrug und First-Party-Betrug erzeugen denselben Verlustbetrag aus entgegengesetzten Ursachen. Beim Third-Party-Betrug agiert jemand als ein Kunde, der er nicht ist: eine gestohlene Karte, eine Account-Übernahme, ein vorgetäuschter Antragsteller. Beim First-Party-Betrug verursacht der echte Kontoinhaber den Verlust absichtlich – indem er im Antrag falsche Angaben macht oder Geld leiht, ohne die Absicht, es zurückzuzahlen. Der Unterschied entscheidet darüber, welches Modell Sie bauen und wie Sie den Verlust behandeln.
Sobald Sie das akzeptieren, löst sich viel nachgelagerte Verwirrung auf. Der Grund, warum sich so viele Betrugsprogramme anfühlen, als liefen sie auf der Stelle, ist, dass sie ein Modell trainieren, eine Policy festlegen und eine Kennzahl reporten – über zwei Populationen hinweg, die außer dem Buchungssatz im Hauptbuch fast nichts gemeinsam haben.
Die Taxonomie ist eine operative Entscheidung, keine Namensübung
Man behandelt die Betrugstaxonomie gern als Vokabular. Sie ist eher eine Routing-Tabelle. Das Label, das Sie einem Verlust anhängen, entscheidet, welches Team ihn verantwortet, welches Modell ihn scort, welchen Recovery-Pfad er durchläuft und welche Zeile er in der Gewinn- und Verlustrechnung trifft.
Der sauberste Schnitt verläuft danach, wer transagiert, im Verhältnis zu dem, wer erfasst ist:
- Third-Party: Die transagierende Partei ist nicht die erfasste Person, und die erfasste Person ist ein Opfer. Gestohlene Zugangsdaten, Card-not-present-Missbrauch, Account-Übernahme, synthetische Identitäten, die die Daten einer realen Person entleihen.
- First-Party: Die transagierende Partei ist die erfasste Person, und es gibt kein separates Opfer. Falschangaben im Antrag, Bust-out und Never-Pay-Konten, bei denen die Absicht zum Ausfall schon bei der Kontoeröffnung bestand.
Es gibt eine ehrlich gesagt unangenehme Grauzone. Eine synthetische Identität, die teils aus der echten SSN einer realen Person zusammengesetzt ist, liegt zwischen beiden, und Refund-Missbrauch durch einen echten Kunden ist First-Party-Verhalten, das viele Teams unter Disputes statt überhaupt unter Betrug verbuchen. Solche Fälle löst man nicht, indem man über Definitionen streitet. Man löst sie, indem man die Entscheidungsregel niederschreibt, die die eigene Organisation konsistent anwenden wird, und dann das Label stabil hält, damit sechs Monate Historie über die gesamte Kette hinweg dasselbe bedeuten. Eine driftende Taxonomie ist schlimmer als eine grobe, denn Ihre Eval-Sets erben die Drift, und Sie können nicht mehr sagen, ob das Modell schlechter wurde oder sich die Labels verschoben haben.
Warum ein einziges Modell nicht beiden dienen kann
Die beiden Populationen trennen sich in der Zeit, und die Zeit ist der Großteil dessen, womit ein Betrugsmodell arbeiten muss.
Third-Party-Verluste konzentrieren sich rund um Ereignisse: den Moment des Antrags, die erste Card-not-present-Transaktion, ein Passwort-Reset gefolgt von einem neuen Zahlungsempfänger. Das Signal ist eine Diskrepanz zwischen der behaupteten Identität und dem Verhalten, und es ist oft schon in den ersten Stunden erkennbar. Velocity, Wiederverwendung von Gerät und IP, Entity Resolution über Anträge hinweg, eine Lieferadresse, die diese Woche bereits auf vier anderen Konten aufgetaucht ist.
First-Party-Verluste kündigen sich beim Onboarding nicht an, denn beim Onboarding ist an der Identität technisch nichts falsch. Die Person ist die, die sie zu sein behauptet. Falsch ist das angegebene Einkommen, die angegebene Absicht oder die Tragfähigkeit, die das Underwriting angenommen hat. Dieses Signal tritt später zutage: beim First-Payment-Default, in einem Bust-out-Muster, bei dem die Ausnutzung kurz vor dem Erlöschen des Kontos gegen das Limit klettert, in einem Cluster von Konten aus demselben Funnel, die alle in derselben Vintage ausfallen.
Die Features unterscheiden sich also, die Labels treffen zu unterschiedlichen Takten ein, und das Reifefenster ist ein anderes. Wenn Sie beides in ein Ziel zusammenwerfen, erhalten Sie ein Modell, das in beidem mittelmäßig ist. Konkret:
- Label-Timing. Ein Third-Party-Label kann innerhalb von Tagen bestätigt werden. Ein First-Party-Bust-out ist nicht bestätigbar, bevor das Konto gealtert ist, manchmal über das Quartalsende hinaus. Trainieren Sie auf einem Snapshot, sind Ihre First-Party-Positiven noch ungelabelt, sodass das Modell lernt, sie seien Negative. Das ist Lookahead, der rückwärts läuft. Nichts aus der Zukunft leckt in die Features; die Zukunft ist schlicht noch nicht eingetreten, und so wird ein ungelabelter Bust-out als gutes Konto gescort.
- Point-in-Time-Korrektheit. First-Party-Features stützen sich auf Rückzahlungs- und Ausnutzungsverläufe. Wenn Ihr Feature Store den aktuellen Saldo statt des Saldos zum Scoring-Datum ausliefert, haben Sie auf dem Ergebnis trainiert. Das Konto fiel aus – natürlich war die Ausnutzung hoch.
- Kostenasymmetrie. Ein False Positive bei Third-Party ist eine abgelehnte Transaktion und ein verärgerter echter Kunde. Ein False Positive bei First-Party ist ein abgelehnter Antragsteller und eine Fair-Lending-Frage, denn die ablehnende Entscheidung muss unter dem ECOA erklärbar sein. Ihr False-Positive-Budget ist nicht ein Budget. Es sind zwei, in unterschiedlichen Währungen denominiert.
Zwei Modelle – oder zumindest zwei Heads auf einer gemeinsamen Repräsentation – mit getrennten Labels und getrennten Schwellenwerten. Reporten Sie sie ebenfalls getrennt.
Die Klassifizierung verzerrt still und leise alles Nachgelagerte
Hier ist der Teil, der echtes Geld kostet und auf einem Dashboard nahezu unsichtbar ist. First-Party-Betrug sieht exakt wie ein Kreditausfall aus und wird deshalb als Kreditverlust verbucht. Das Konto wurde in gutem Glauben eingeräumt, der Kunde hörte auf zu zahlen, der Verlust fließt in die Kreditlinie und in die Vorsorge für erwartete Kreditverluste. Niemand markiert es, denn die Arithmetik stimmt.
Die Folgen potenzieren sich:
- Ihre Betrugsrate ist unterschätzt und Ihr Kreditverlust überschätzt, sodass Kapital und Rückstellungen gegen die falsche Ursache gebildet werden.
- Das Underwriting erfährt nie, welche Antragsmuster ein Never-Pay vorhersagten, weil diese Konten als gewöhnliche Ausfälle gelabelt und in das Kreditmodell zurückgespeist wurden, nicht in das Betrugsmodell.
- Das Recovery-Team jagt First-Party-Betrug über einen Inkasso-Pfad, der für Kunden gebaut ist, die in Rückstand geraten sind – nicht für Menschen, die nie zu zahlen beabsichtigten. Das verschwendet den Aufwand und lässt das eigentliche Muster unentdeckt.
Das zu beheben ist unglamourös. Es ist ein Reconciliation- und Lineage-Problem, bevor es ein Modellierungsproblem ist. Sie brauchen Charge-off-Reason-Codes, die eine First-Party-Betrugskennzeichnung tragen können, einen Audit-Trail, der festhält, warum ein Konto umklassifiziert wurde, und einen periodischen Durchlauf, der Kredit-Charge-offs erneut auf Bust-out-Signaturen untersucht. Die Umklassifizierung muss belastbar sein, denn Sie verschieben einen Verlust zwischen regulatorischen Töpfen, und jemand wird Sie bitten, das zu rechtfertigen.
Der Lohn ist, dass Ihre Betrugszahlen beginnen, Betrug zu beschreiben, Ihre Kreditzahlen beginnen, Kredit zu beschreiben, und jedes nachgelagerte Modell endlich auf Labels trainiert, die bedeuten, was sie sagen. Straight-through processing auf den sauberen Fällen wird sicher, weil das Label, das die Entscheidung speist, an dem Punkt, an dem es angewandt wird, dasselbe bedeutet wie zu dem Zeitpunkt, als das Modell trainiert wurde. Nichts davon funktioniert, solange die Trennung nicht real in den Daten ist – und nicht nur auf der Folie, die sie beschreibt.
Häufige Fragen
Wie unterscheiden sich First-Party- und Third-Party-Betrug in einem Satz?
Beim Third-Party-Betrug gibt sich jemand als ein rechtmäßiger Kunde aus oder bestiehlt ihn, während beim First-Party-Betrug der Kontoinhaber selbst den Verlust verursacht – meist, indem er im Antrag lügt oder sich einer Schuld entzieht, die er von vornherein nie zurückzahlen wollte.
Warum nicht einfach beides als Betrugsverlust behandeln und weitermachen?
Weil sich beide über den Lebenszyklus des Kontos unterschiedlich verhalten: Third-Party-Verluste häufen sich rund um Onboarding und Card-not-present-Vorgänge, während First-Party-Verluste bei der ersten Zahlung oder beim Charge-off zutage treten. Ein einziges Modell, das auf einem gemischten Label trainiert wird, lernt daher ein verwaschenes Signal und verfehlt beides.
Welche Art wird am häufigsten als Kreditverlust fehlklassifiziert?
First-Party-Betrug. Er sieht aus und verhält sich wie ein gewöhnlicher Kreditausfall und wird deshalb routinemäßig der Kreditlinie statt der Betrugslinie zugebucht. Das unterschätzt den Betrug, überschätzt den erwarteten Kreditverlust und verschleiert den Grund, aus dem das Konto notleidend wurde.