Betrug und autorisierte Push-Payment-Fraud erkennen

Bei autorisiertem Push-Payment-Betrug (APP-Fraud) überweist die Kundin das Geld selbst. Sie meldet sich von ihrem gewohnten Gerät an, durchläuft jeden Authentifizierungsschritt und bestätigt eine Überweisung, die sie für legitim hält. Nicht das Konto ist kompromittiert, sondern die Person. Die Erkennung muss bewerten, ob die echte Kontoinhaberin getäuscht wird – und das bestimmt sowohl, was man misst, als auch, wie man reagiert.

Standardmodelle für Zahlungsbetrug sind gegen einen anderen Gegner trainiert. Sie lernen die Fingerabdrücke eines Angreifers, der ein Konto übernommen hat: ein neues Gerät, ein unbekanntes Netzwerk, eine Session, die sich völlig anders verhält als die Historie der Kundin. Bei einem APP-Betrug ist jedes einzelne dieser Signale sauber, weil die echte Kundin die Arbeit macht. Richtet man ein Account-Takeover-Modell auf Betrugsverkehr, winkt es die Zahlung durch, denn nach seiner eigenen Definition ist nichts verkehrt. Die Betrugserkennung braucht einen eigenen Scoring-Pfad, gebaut auf anderen Features und einem anderen Label, mit einer eigenen Vorstellung davon, was ein schlechtes Ergebnis überhaupt ist.

Das ist keine abstrakte Frage. In Großbritannien sind die verbindlichen Erstattungsregeln des Payment Systems Regulator am 7. Oktober 2024 in Kraft getreten, und die sendende und empfangende Bank teilen sich nun die Kosten für die Entschädigung der meisten APP-Betrugsopfer über Faster Payments. Eine korrekte Erkennung wurde damit von einer Kulanzübung zu einer direkten Position in der Verlustrechnung.

Zuerst kommt das Label-Problem

Vor jeder Modellierung muss das Ziellabel stimmen, denn APP-Labels sind auf subtile Weise vergiftet – auf eine Weise, die die Offline-Zahlen schönt.

Das Label, das man will, lautet „diese Zahlung war Betrug”, und die einzige verlässliche Quelle ist das bestätigte Ergebnis: Die Kundin hat es gemeldet, der Fall wurde bearbeitet, die Empfängerbank hat ein Mule-Konto bestätigt. Diese Bestätigung trifft Tage oder Wochen nach der Zahlung ein. Alles, was man in diesem Fenster erfährt, ist für Trainingszwecke kontaminiert. Die spätere Reputation des Empfängerkontos, die Tatsache, dass fünfzehn weitere Opfer an dieselbe Bankleitzahl gezahlt haben, die Erinnerung der Kundin an das Telefongespräch – nichts davon existierte, als die Zahlung autorisiert wurde.

Also erzwinge Point-in-Time-Korrektheit gnadenlos. Friere jedes Feature auf den Autorisierungszeitstempel ein und gleiche es gegen die Lineage des Zahlungsevents ab.

• Empfänger-Features dürfen nur widerspiegeln, was vor der Belastung bekannt war – nicht das Mule-Flag, das erst nachträglich angehängt wurde.
• Verhaltens-Features müssen aus der Session bis zum Bestätigungsklick berechnet werden, nicht aus der vollständigen Session inklusive des Moments, in dem die Kundin dem Betrüger auflegt.
• Verknüpfe niemals die Ergebnis-Tabelle aus dem Case-Management in den Feature-Satz. Sie ist die Quelle des Labels; berührt sie die Features, hast du ein Leak gebaut.

Wenn ein Betrugsmodell im Backtest dramatisch besser aussieht als das Account-Takeover-Modell daneben, unterstelle Lookahead, bis das Gegenteil bewiesen ist. Der Großteil des scheinbaren Zugewinns entpuppt sich als ein Feature, das die Antwort still mitkodiert.

Signale, die Betrug tatsächlich trennen

Eine unter Manipulation ausgelöste Zahlung hinterlässt Spuren, aber sie liegen im Kontext der Zahlung und im Verhalten der Kundin, nicht in ihrer Identität. Das sind die Feature-Familien, die das Engineering wert sind.

• Neuheit und Velocity des Empfängers. Eine allererste Zahlung an einen brandneuen Zahlungsempfänger, der Minuten vor der Überweisung angelegt wurde, an ein Konto, das selbst erst seit Tagen existiert. Entity Resolution über die gesamte Empfängerpopulation zeigt, wenn ein Konto plötzlich von vielen nicht verbundenen Absendern Geld erhält.
• Session-Reibung und Zögern. Langes Verweilen auf dem Zahlungsbildschirm, wiederholtes Editieren des Verwendungszwecks, der Empfängername mehrfach getippt und neu getippt, eine Session, die pausiert, als würde die Kundin ein Skript an jemanden zurücklesen. Einzeln schwach, in Kombination nützlich.
• Zahlungszweck gegen das Profil. Eine Überweisung auf ein „sicheres Konto”, ein Investment-Empfänger, ein Notaranderkonto-Betrag, der zu keiner bekannten Immobilientransaktion passt, oder eine Kundin, die nie vierstellige Faster Payments sendet und plötzlich ihr gesamtes Guthaben bewegt.
• Gleichzeitige Telefonaktivität, wo man sie beobachten kann. Auf dem Mobilgerät ist ein laufender Anruf während der Zahlung eines der stärkeren Manipulationssignale, denn Impersonation-, Investment- und Romance-Scams laufen fast alle über ein aktives Telefonat.
• Gemeinsame Intelligence zum Empfänger. Treffer nach Bankleitzahl und Kontonummer gegen branchenweite Betrugsmelde-Feeds, angewendet Point-in-Time, sodass nur zählt, was vor der Zahlung veröffentlicht wurde.

Kein einzelnes Signal ist entscheidend. Die Aufgabe des Modells ist es, sie zu einem Absichts- und Manipulations-Score zu fusionieren, auf den eine Policy-Schicht reagieren kann – und ihn schnell genug zurückzugeben, dass die saubere Mehrheit im Straight-Through-Processing durchläuft.

Eingreifen, ohne die guten Überweisungen zu blockieren

Der Score wählt einen Reibungsgrad, kein Genehmigen-oder-Ablehnen-Urteil, und diese Abstufung richtig hinzubekommen, ist der Punkt, an dem sich ein False-Positive-Budget auszahlt. Jede APP-Überweisung ist eine Zahlung, die die Kundin ausführen will. Blockiert man zu viele, lehnt man Miete, Kautionen und Gehälter ab; schlimmer noch, die Kundin weicht auf einen Kanal aus, den man überhaupt nicht bewerten kann.

Passe die Intervention an das Score-Band und das Betrugsmuster an.

• Niedriger Score: Straight-Through, keine Reibung. Das ist die überwältigende Mehrheit, und sie muss unsichtbar bleiben.
• Mittlerer Score: eine gezielte, empfängerspezifische Warnung. Generische „Sind Sie sicher?”-Banner werden reflexartig weggeklickt. Eine Warnung, die den Betrugstyp benennt, auf den die Features zeigen, ist eine, die eine Kundin tatsächlich liest.
• Hoher Score: ein harter Stopp für einen Menschen. Eine Abkühlfrist für die Zahlung, ein skriptbasierter ausgehender Anruf oder die Pflicht, über einen zweiten Kanal zu bestätigen, bevor das Geld das Konto verlässt.

Jede Intervention wird in den Audit-Trail geschrieben: der Score, die beitragenden Features und die ergriffene Maßnahme. Ein Prüfer kann so rekonstruieren, warum eine Zahlung angehalten wurde, und man kann messen, ob die Reibung einen Verlust verhindert oder nur jemanden verärgert hat. Verfolge die Wirksamkeit der Interventionen als eigene Kennzahl. Eine Warnung, nach der niemand je eine Zahlung abbricht, ist eine Warnung, die nichts bewirkt – und sie verbraucht dein Reibungsbudget ohne Gegenwert.

Beobachte Drift genau, denn Betrugsskripte wechseln schneller als Kartenbetrugstaktiken. Wenn Impersonation von „Ihr Konto ist kompromittiert” zu „Ihr Paket braucht eine Freigabegebühr” wechselt, verschieben sich Sprache und Zahlungsmuster mit, und Features, die auf das Playbook des letzten Quartals abgestimmt sind, verfallen. Schneide das Eval-Set in regelmäßiger Kadenz aus aktuellen bestätigten Fällen neu und halte die Empfänger-Intelligence im Feature Store frisch – sonst rutscht das Modell still zurück dahin, alles durchzuwinken.