Velocity-Grenzen und Anti-Missbrauch

1) Was ist Velocity und warum wird es benötigt?

• Reduzierung von Betrug und Ausnutzung von Boni/Promo,
• Schutz der Zahlungsinfrastruktur vor „Stürmen“,
• Halten Sie eine gesunde Konversion aufrecht, indem Sie fragwürdige Versuche in eine Herausforderung (3DS/SCA) umwandeln, anstatt nach Möglichkeit „hart abzulehnen“.

Velocity-Kontrollen ergänzen Scoring, AVS/CVV, 3DS2/SCA und Smart-Routing.

2) Welche Entitäten zu begrenzen (scopes)

• Zahlungseinheiten: 'card _ token' (vault/network), 'bin', 'issuer', 'psp _ route'.
• Benutzerdefiniert: 'account _ id', 'kyc _ level', 'email/phone'.
• Technisch: 'device _ id' (fingerprint/SDK), 'ip', 'asn', 'session _ id'.
• Geschäftskontext: 'bonus _ id', 'campaign _ id', 'country', 'mcc 7995' Untertyp (Einzahlung/Auszahlung).
• Finanziell: „amount _ bucket“ (mikro/mittel/groß), „currency“, „payment _ method“.

3) Fenster und Zähler

Fixed window (T = 15m/1h/24h) - einfach, aber grenzempfindlich.
Sliding window - genauer gesagt, zählt nach dem „gleitenden“ Intervall.
Leaky bucket/Token bucket - glätten Sie die Spitzen, setzen Sie eine stabile Bandbreite.
Kombiniert: Burst (kurzer Anstieg) + nachhaltig (langer Fluss).

• „device _ id“: ≤ 3 Autorisierungsversuche in 15 Minuten; ≤ 10 in 24 Stunden.
• „card _ token“: ≤ 2 decline in Folge ohne 3DS; Der dritte ist der obligatorische 3DS.
• 'ip': ≤ 5 einzigartige' card _ token 'in 1 Stunde (ansonsten captcha/block).
• „account _ id“: ≤ 2 stornierte Einlagen in Folge; weiter - kuldown 1 Stunde.

4) Beschränkungsalgorithmen (kurz)

• Initialisieren Sie' capacity 'und' refill _ rate'.
• Vor jedem Versuch 1 Token „herausnehmen“; wenn es keine Token gibt - challenge/decline.

• Die Warteschlange läuft mit konstanter Geschwindigkeit ab; kommende Veranstaltungen überfordern - throttle.

1. Wiederholung: 2-5 Minuten → 2.: 10-20 Minuten → 3.: 1-2 Stunden → Stopp oder Umstellung auf eine alternative Methode.

5) Entscheidungspolitik (decisioning)

• Allow: geringes Risiko, innerhalb der Schwellenwerte.
• Herausforderung: Überschreitung der „weichen“ Schwelle → 3DS/SCA/Captcha/KBA (Fragen).
• Throttle: vorübergehend einschränken (Couldown) mit transparentem UX.
• Decline: grobe Verstöße (massiver Kartenüberschuss, Bot-Pools, Bonus-Missbrauch).
• Reroute: Änderung der PSP/Methode (z. B. A2A) bei einem Anstieg von „91/96“ beim Emittenten.

Mini-Beispielmatrix

'device _ id' versucht, ≥ 3 in 15 Minuten und 'cvv = N' ≥2 → Decline + captcha.
'card _ token' 2 soft-decline in einer Reihe → 3DS-challenge (erforderlich).
'ip' ≥ 5 eindeutige' account _ id 'in 30 min → Throttle 30 min + KYC-check.
'account _ id' Einzahlung-Auszahlung-Einzahlung für 10 min (Karussell) → Challenge oder Limit auf den Betrag.

6) Velocity für Einzahlungen, Retrays und Auszahlungen

• Schützen Sie „Micro-Bullets“ (viele kleine Transaktionen): Mengenlimit und Gesamtumsatz pro T.
• Mit einer Reihe von '05 '/' 14 '/' 54' - stoppen Sie die „Overkill“ von Requisiten, übersetzen Sie in 3DS.

• Trennen Sie CIT und MIT der Warteschlange. Verwenden Sie für MIT die weichen Fenster T + 1/T + 24h.
• Soft-decline' SCA erforderlich '→ sofort 3DS, nicht brennen versuchen.

• Separate Limits für Betrag/Häufigkeit: z.B. ≤ 2 Auszahlungen/24h und ≤ N für Betrag/Woche.
• KYC „Leiter“: Je höher der Check, desto höher die Limits.
• Detail „Zirkulation“: schnelle Einzahlung und sofortige Auszahlung - manuelle Überprüfung/Halten.

7) Anti-Missbrauch Promo und Boni

Per-campaign caps: 'bonus _ id' ≤ X Aktivierungen auf 'device _ id '/' ip '/' payment _ fingerprint'.
„Forks“ (Geldtransfer zwischen Konten): Graphenanalyse gemeinsamer Karten/IP/Geräte.
Cool-off Fenster: nach Bonus-Einzahlung - sofortige Auszahlung Verbot, transparente Regeln in ToS.
Sanktionen nach Stufen: von temporären Sperren bis „für immer“, mit Ursachenmagazin.

8) Architektur: Wo velocity-Regeln zu leben

Real-Time Gateway (im Orchestrator): Lösung ≤ 50-100 ms.
Zählerspeicher: In-Memory (Redis/KeyDB) + Langzeit- „Zusammenfassungen“ (DWH).
Fichester: einheitliche Fenster/Einheiten (15m/1h/24h/7d).
Regelmotor + ML-Scoring: „safety-net“ Regeln über das Modell.
Config-Flaggen: „3DS einschalten“, „strenger in der Region X“, „PSP-A Pause“.
Idempotenz: Schutz vor Duplikaten bei Wiederholungen/Timeouts.

9) Pseudocode der Regeln (Skizze)

pseudo on payment_attempt(ctx):
s = features(ctx) // device/ip/account/bin/score/avs/cvv/history if counter(device, 15m) >= 3 and cvv_fail(device, 15m) >= 2:
return DECLINE(reason="velocity_device_cvv")
if soft_declines(card_token, 1h) >= 2:
return CHALLENGE_3DS()
if uniq_accounts(ip, 30m) >= 5:
return THROTTLE(ttl=30m)
if score > T2 and velocity(account, 1h) > Vmax:
return DECLINE(reason="high_risk_burst")
return ALLOW

10) UX-Muster (ohne die Konvertierung zu brechen)

Klare Botschaften: "Zu viele Versuche in kurzer Zeit. Versuchen Sie es in 15 Minuten oder bestätigen Sie in der Bank".
Taste „Später wiederholen“ mit Timer.
Alternativvorschlag: A2A/lokale Geldbörsen beim Trottling.
Auto-3DS ohne erneute Eingabe der Details bei SCA-soft.
Captcha nur punktuell (per IP/ASN/Bot-Signale), nicht für alle.

11) Compliance und Datenschutz

DSGVO/PII: Halten Sie minimale IDs (Geräte-Hashes, Karten-Token, last4), transparente Richtlinien.
PCI DSS: keine PAN/CVV in den Protokollen; velocity-Ereignisse ohne sensible Daten.
PSD2/SCA: Überschreitungen gegebenenfalls in Herausforderung umrechnen, anstelle von Totalausfällen.

12) Metriken, Alerts, SLO

• Approval Rate (allgemein und wenn Regeln ausgelöst werden).
• False Positive Rate der Velocity-Regeln (Anteil der ehrlichen Blöcke → an der späteren Legitimität).
• Die Anzahl der „Stürme“ von Retrays und die durchschnittliche Erholungszeit.
• Anteil der Übersetzungen von decline → challenge mit erfolgreichem Ergebnis.
• Chargeback Rate in Segmenten, in denen Limits ausgelöst wurden (wir erwarten ↓).

• Spike' 05/14/54'+ Zunahme der Versuche> X in 15 Minuten im BIN/ASN-Cluster.
• Splash '91/96' → Auto-Erhöhung der T1-Schwelle + Routing in PSP-B.
• FP-Rate der Regel> Ziel (z.B. 1. 5 × wöchentlicher Median).

• Die Velocity-Lösung ≤ 100 ms p95.
• Der Anteil der erfolgreichen Zahlungen, die an 3DS übertragen werden, anstatt ≥ Ziel abzulehnen.

13) Anti-Muster

Universelles „Total“ Limit für alle Märkte und Kundentypen.
Sperren durch 'AVS = U/S/G' in Ländern, in denen AVS nicht regulär arbeitet.
Nicht teilen CIT/MIT - bricht Abonnements/Wiederholungen.
Rückzug ohne Jitter und Idempotenz - Doppel und Stürme.
Die Gründe der Absage zu verbergen - wächst sapport und die Giftigkeit.

14) Checkliste Umsetzung

• Entity Map (Scopes) und Fenster (15m/1h/24h/7d).
• Auswahl der Algorithmen: sliding + token bucket für bursts.
• Normalisierung der Retrays: backoff + jitter, getrennt für CIT/MIT.
• Integration mit 3DS/SCA: Auto-Challenge bei weichen Überschreitungen.
• Separate Limits für Abhebungen und Boni; Graph-Überprüfung der Verbindungen.
• Beobachtbarkeit: KPI Dashboards/Alerts/Regelprüfung.
• UX-Meldungsvorlagen und alternative Methoden.
• PCI/GDPR-Richtlinien: Token, Maskierung, PII-Minimierung.
• A/B-Tests von Schwellenwerten nach Märkten/BIN/ASN und Kundenprofilen.
• Incident playbooks: Emittent/PSP degradation, Bots surge.

15) Zusammenfassung

Effektive Velocity-Limits sind mehrstufige Fenster und Zähler für verschiedene Entitäten, Glättungsalgorithmen (Token/Leaky Bucket), intelligente Retrays und eine enge Verbindung zu 3DS/SCA und Scoring. Eine solche Schaltung reduziert Betrug und Missbrauch, erstickt die Konvertierung nicht und hilft, die Monetarisierung bei der Volatilität von Emittenten und Verkehr stabil zu halten.