Velocity-Rules und Rate-Limiting im Fraud, richtig gemacht

Eine Velocity-Rule zählt, wie oft etwas innerhalb eines Zeitfensters passiert, und handelt, wenn der Zählwert eine Schwelle überschreitet: fünf Kartenversuche in einer Minute, drei neue Zahlungsempfänger in einer Stunde, zehn Logins von einem Gerät vor Mittag. Richtig gemacht ist sie ein günstiges, erklärbares Gate, das offensichtlichen Missbrauch stoppt, bevor dein Modell überhaupt läuft. Falsch gemacht ist sie eine Maschine, die zum Quartalsende deine besten Kunden blockiert.

Der Grund, warum Velocity vierzig Jahre Fraud-Tooling überlebt, ist, dass sie auf Signalen arbeitet, die du ohnehin schon hast, und dass sie sich selbst erklärt. Wenn eine Regel auslöst, kannst du auf die exakten Events zeigen, die sie ausgelöst haben – das zählt, wenn ein Kunde sich beschwert und wenn ein Regulierer fragt. Der Grund, warum sie schiefgeht, ist, dass die meisten Teams die Schwelle als Einstellung behandeln statt als Entscheidung mit einem Preisschild. Jemand wählt fünf, weil sich fünf richtig anfühlt, bringt es live und misst nie, was fünf tatsächlich mit den Leuten gemacht hat, die keinen Betrug begangen haben.

Bring den Zähler in Ordnung, bevor du die Schwelle anfasst

Die meisten Velocity-Fehler sind keine Tuning-Fehler. Es sind Zählfehler, und sie bleiben unsichtbar, bis jemand die Zahlen abgleicht.

Der Zähler muss Point-in-Time-korrekt sein. Wenn du eine Transaktion bewertest, darf der verwendete Zählwert nur Events widerspiegeln, die zu genau diesem Zeitpunkt bereits eingegangen waren, nicht Events, die später ankamen. Wenn deine Trainingsdaten gegen einen aus der vollständigen Historie berechneten Zähler joinen, lernt das Modell aus Informationen, die das Produktionssystem zum Entscheidungszeitpunkt nicht haben wird. Das ist Leakage, und sie bläht deine Offline-Metriken auf, während deine Live-Block-Rate irgendwo ganz anders hindriftet. Die Lösung ist, Velocity-Features aus einem unveränderlichen Event-Log mit einem Event-Time-Index zu berechnen und den Zählwert für jede Trainingszeile zum Entscheidungs-Zeitstempel neu zu berechnen.

Dann ist da der Schlüssel. Eine Velocity-Rule ist nur so gut wie die Entität, gegen die sie zählt. Versuche pro Kartennummer zu zählen, ist trivial zu umgehen: Der Betrüger rotiert Karten und bleibt unter jeder Schwelle. Du willst gegen eine aufgelöste Entität zählen, die die Rotation überlebt. Das bedeutet Entity Resolution über Gerät, Karte, E-Mail und Zahlungsempfänger, bevor der Zähler hochzählt, sodass zehn Versuche eines Akteurs über zehn Karten hinweg als zehn registriert werden, nicht als jeweils einer.

Ein paar Dinge, die wir prüfen, bevor wir irgendeinem Velocity-Zähler in Produktion trauen:

• Zählwerte sind auf eine aufgelöste Entität verschlüsselt, nicht auf einen rohen Identifier, den ein Betrüger kontrolliert.
• Der Streaming-Zählwert gleicht sich gegen eine tägliche Batch-Neuberechnung ab, und auf die Abweichung wird alarmiert.
• Verspätet und außer der Reihe eintreffende Events werden explizit behandelt, mit einem definierten Watermark, nicht stillschweigend verworfen.
• Jeder Zähler hat eine Lineage zurück zu den Quell-Events, sodass eine ausgelöste Regel für den Audit-Trail rekonstruiert werden kann.

Überspring das, und du wirst deinen Aufwand fürs Schwellen-Tuning damit verbringen, einen Zähler zu kompensieren, der still und leise falsch ist.

Justiere gegen ein False-Positive-Budget, nicht gegen ein Bauchgefühl

Eine Schwelle ist ein Tauschgeschäft. Senk sie, und du fängst mehr Fraud und blockst mehr legitime Kunden. Heb sie an, und du machst das Gegenteil. Die Zahl, die daraus eine Entscheidung statt eines Ratens macht, ist das False-Positive-Budget: wie viele gute Kunden du bereit bist zu blocken, pro Segment, pro Tag.

Leg das Budget pro Segment fest, weil die Kosten eines False Positive nicht einheitlich sind. Einen neuen Account mitten im Signup zu blocken, kostet dich eine Akquise. Einen Gehaltslauf für einen etablierten Geschäftskunden zu blocken, kostet dich die Beziehung. Eine einzige globale Schwelle behandelt diese als gleichwertig – deshalb sind globale Schwellen für irgendwen meist falsch.

Die Methode, die wir verwenden, ist unglamourös, und sie funktioniert:

• Bau ein Eval-Set aus gelabelten Outcomes, zeitlich herausgehalten, sodass du in einem Zeitraum testest, den die Schwelle nie gesehen hat.
• Miss für jede Kandidaten-Schwelle den gefangenen Fraud und die geblockten legitimen Kunden, aufgeschlüsselt nach Segment.
• Lies die Block-Rate gegen das Budget des Segments. Wenn eine Schwelle das Budget überzieht, ohne dass der gefangene Fraud entsprechend steigt, ist sie kein Kandidat.
• Wähl den Punkt auf dieser Kurve, hinter dem das Business tatsächlich stehen wird, und schreib auf, warum.

Der letzte Schritt zählt mehr, als er klingt. Schwellen verfallen. Kundenverhalten verschiebt sich, ein Marketing-Push verändert deinen Traffic-Mix, ein neues Produkt verschiebt die Verteilung. Eine Schwelle, die im März richtig war, überzieht ihr Budget im Juni stillschweigend. Überwache die realisierte False-Positive-Rate als Drift-Signal und schau erneut hin, wenn sie ausbricht, statt zu warten, bis die Beschwerde-Queue es dir sagt.

Regeln und Modelle sind ein System

Das ausgeleierte Framing lautet Regeln gegen Machine Learning. In einem funktionierenden Stack sind sie Schichten derselben Pipeline, und jede macht den Job, in dem die andere schlecht ist.

Velocity-Rules sind das schnelle, günstige, harte Gate. Sie laufen zuerst, auf Features, deren Berechnung fast nichts kostet, und sie behandeln die Missbrauchsmuster, die eindeutig sind: der Credential-Stuffing-Burst, die Card-Testing-Schleife, der Zahlungsempfänger, der in neunzig Sekunden hinzugefügt und leergeräumt wird. Diese direkt zu blocken, hält sie aus dem Scoring-Budget des Modells heraus und hält deine Latenz für die Transaktionen niedrig, die echte Analyse verdienen.

Das Modell behandelt Mehrdeutigkeit. Es wägt dieselben Velocity-Zählwerte als Features ab, neben allem anderen, und produziert einen Score für die Fälle, die eine harte Regel nicht ohne Kollateralschaden auflösen kann. Ein Kunde, der vier Überweisungen in einer Stunde macht, könnte ein Betrüger sein oder könnte Auftragnehmer bezahlen. Eine Regel sagt: block bei drei; ein Modell sagt: schau auf die Zahlungsempfänger, die Beträge, die Gerätehistorie und entscheide.

Dazwischen sitzt die Case-Management-Schicht, und sie braucht dieselbe Sorgfalt wie die Automatisierung. Straight-Through-Processing sollte die sauberen Transaktionen freigeben, ohne dass ein Mensch sie anfasst. Alles, was eine Regel oder ein Modell markiert, aber nicht hart blockt, geht zur Prüfung – mit den Zählwerten, den auslösenden Events und dem Score im Anhang, sodass ein Analyst in Sekunden handeln kann und die Disposition als Label zurückfließt. Diese Feedback-Schleife hält beide Schichten ehrlich: Regeln, die du nie prüfst, werden zu einer permanenten Steuer auf gute Kunden, und Modelle, die du nie neu labelst, driften.

Behandle die beiden als ein System mit einem gemeinsamen False-Positive-Budget, einem gemeinsamen Eval-Set und einem gemeinsamen Audit-Trail, und Velocity verdient sich ihren Platz als älteste Kontrolle, die noch immer ihren Beitrag leistet. Behandle die Schwelle als Set-and-forget-Konfigurationswert, und sie wird zum Grund, warum sich dein Fraud-Team zum Quartalsende ständig entschuldigt.