Velocity limits and anti-abuse

1) What is velocity and why it is needed

• reduce fraud and exploitation of bonuses/promos,
• protect payment infrastructure from "storms" of retrays,
• keep a healthy conversion by converting dubious attempts to challenge (3DS/SCA) instead of "hard failure" where possible.

Velocity controls complement scoring, AVS/CVV, 3DS2/SCA, and smart routing.

2) Which entities to limit (scopes)

• Payment entities: 'card _ token' (vault/network), 'bin', 'issuer', 'psp _ route'.
• Custom: 'account _ id', 'kyc _ level', 'email/phone'.
• Technical: 'device _ id' (fingerprint/SDK), 'ip', 'asn', 'session _ id'.
• Business context: 'bonus _ id', 'campaign _ id', 'country', 'mcc 7995' subtype (deposit/output).
• Financial: 'amount _ bucket' (micro/medium/large), 'currency', 'payment _ method'.

3) Windows and counters

Fixed window (T = 15m/1h/24h) - simple, but sensitive to boundaries.
Sliding window - more precisely, counts at a "sliding" interval.
Leaky bucket/Token bucket - smooth out bursts, set stable bandwidth.
Combined: burst (short burst) + sustained (long stream).

• 'device _ id ': ≤ 3 authorization attempts in 15 minutes, ≤ 10 in 24 hours.
• 'card _ token ': ≤ 2 consecutive decline without 3DS; the third is mandatory 3DS.
• 'ip ': ≤ 5 unique'card _ token' per hour (aka captcha/block).
• 'account _ id ': ≤ 2 cancelled deposits in a row; further - kuldown 1 hour.

4) Constraint algorithms (short)

• Initialize 'capacity' and 'refill _ rate'.
• Before each attempt, "take out" 1 token; if there are no tokens - challenge/decline.

• The queue leaks at a constant rate; incoming events overflow - throttle.

• 1st repeat: 2-5 min → 2nd: 10-20 min → 3rd: 1-2 h → stop, or transfer to an alternative method.

5) Decision policies

• Allow: low risk, within thresholds.
• Challenge: exceeded the "soft" threshold → 3DS/SCA/captcha/KBA (questions).
• Throttle: Temporarily restrict (cooldown) with transparent UX.
• Decline: gross violations (mass search of cards, bot pools, bonus abuse).
• Reroute: change of PSP/method (e.g. A2A) with '91/96' spike at issuer.

Mini-matrix of examples

'device _ id'attempts to ≥ 3 in 15 minutes and'cvv = N' ≥2 → Decline + captcha.
'card _ token '2 soft-decline → 3DS-challenge (required).
'ip '≥ 5 unique'account _ id' in 30 minutes → Throttle 30 minutes + KYC check.
'account _ id'deposit-withdrawal-deposit in 10 minutes (carousel) → Challenge or amount limit.

6) Velocity for deposits, retreats and withdrawals

• Protect "micro-stuffing" (many small transactions): limit on quantity and total turnover per T.
• With the sequence '05 '/' 14 '/' 54' - stop the "search" of details, translate to 3DS.

• Post the CIT and MIT queues. For MIT, use soft T + 1/T + 24h windows.
• Soft-decline 'SCA required' → immediately 3DS, do not burn attempts.

• Individual limits for amount/frequency: e.g. ≤ 2 outputs/24h and ≤ N per amount/week.
• KYC "ladder": the higher the check, the higher the limits.
• Detection "circling": quick deposit and instant withdrawal - manual review/hold.

7) Anti-abuse promo and bonuses

Per-campaign caps: 'bonus _ id' ≤ X activations on 'device _ id '/' ip '/' payment _ fingerprint'.
"Plugs" (money transfer between accounts): graph analysis of common cards/IP/devices.
Cool-off windows: after a bonus deposit - prohibition of instant output, transparent rules in ToS.
Sanctions by level: from temporary locks to "forever," with a log of reasons.

8) Architecture: where to live velocity-rules

Real-time gateway (in orchestrator): solution ≤ 50-100 ms.
Counter storage: in-memory (Redis/KeyDB) + long-term "summaries" (DWH).
Fichestor: single windows/aggregates (15m/1h/24h/7d).
Rule engine + ML scoring: "safety-net" rules on top of the model.

Config flags: "turn on 3DS," "stricter in region X," "pause PSP-A."

Idempotence: protection against duplicates at repetitions/timeouts.

9) Pseudo code of rules (sketch)

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 patterns (not breaking conversion)

Clear messages: "Too many attempts in a short time. Please try in 15 minutes or confirm with the bank.
Repeat Later button with timer.
Offering alternatives: A2A/local wallets when throttling.
Auto-3DS without re-entering details with SCA-soft.
Captcha only pointwise (by IP/ASN/bot signals), not to all.

11) Compliance and privacy

GDPR/PII: store minimum identifiers (device hashes, card tokens, last4), transparent policies.
PCI DSS: no PAN/CVV in the logs; velocity events without sensitive data.
PSD2/SCA: convert excesses to challenge where appropriate, instead of total failures.

12) Metrics, alerts, SLO

• Approval Rate (general and when the rules are triggered).
• False Positive Rate of velocity rules (share of honest blocks of → by subsequent legitimacy).
• The number of "storms" of retreats and the average recovery time.
• Percentage of decline → challenge transfers with success.
• Chargeback rate in segments where limits have worked (we expect ↓).

• Spike '05/14/54' + increase in attempts> X in 15 min in BIN/ASN cluster.
• Burst '91/96' → auto-raising T1 threshold + routing in PSP-B.
• FP-rate rules> target (for example, 1. 5 × weekly median).

• Velocity solution ≤ 100ms p95.
• Percentage of successful payments transferred to 3DS instead of failing ≥ target.

13) Anti-patterns

Universal "total" limit for all markets and customer types.
Block by'AVS = U/S/G'in countries where AVS does not work normally.
Do not separate CIT/MIT - breaks subscriptions/repeats.
Retrain without jitter and idempotence - takes and storms.
Hide the reasons for refusal - support and toxicity are growing.

14) Implementation checklist

• Entity map (scopes) and windows (15m/1h/24h/7d).
• Algorithm selection: sliding + token bucket for bursts.
• Return normalization: backoff + jitter, separate for CIT/MIT.
• Integration with 3DS/SCA: auto-challenge for soft overclocks.
• Separate limits for conclusions and bonuses; graph-checking relationships.
• Observability: KPI/alert/rule audit dashboards.
• UX message templates and alternative methods.
• PCI/GDPR policies: tokens, masking, PII minimization.
• A/B thresholds tests by market/BIN/ASN and customer profiles.
• Incident playbooks: Issuer/PSP degradation, bot spike.

15) Summary

Effective velocity limits are multi-level windows and counters for various entities, anti-aliasing algorithms (token/leaky bucket), smart retrays and tight communication with 3DS/SCA and scoring. Such a circuit reduces fraud and abuse, does not stifle conversion, and helps to keep stable monetization with volatility of issuers and traffic.