Limites Velocity et anti-abyse

1) Qu'est-ce que la velocité et pourquoi il est nécessaire

• réduire la frod et l'exploitation des bonus/promos,
• protéger l'infrastructure de paiement contre les « tempêtes » rétrogrades,
• maintenir une conversion saine en traduisant les tentatives douteuses en challenge (3DS/SCA) au lieu de « refus dur » lorsque c'est possible.

Les contrôles Velocity complètent le scoring, AVS/CVV, 3DS2/SCA et smart routing.

2) Quelles entités limiter (scopes)

• Entités de paiement : 'card _ token' (vault/network), 'bin', 'issuer', 'psp _ route'.
• Personnalisé : 'account _ id', 'kyc _ level', 'email/phone'.
• Technique : 'device _ id' (fingerprint/SDK), 'ip', 'asn', 'session _ id'.
• Contexte d'affaires : 'bonus _ id', 'campagne _ id', 'country', 'mcc 7995' sous-type (dépôt/retrait).
• Financier : 'amount _ bucket' (micro/moyen/grand), 'currency', 'payment _ method'.

3) Fenêtres et compteurs

Fenêtre fixe (T = 15m/1h/24h) - simple, mais sensible aux limites.
Sliding Window - plus précisément, compte sur un intervalle « glissant ».
Leaky bucket/Token bucket - lisser les surtensions, définir une bande passante stable.
Combiné : burst (sursaut court) + sustained (long flux).

• "device _ id' : ≤ 3 tentatives d'autorisation en 15 minutes ; ≤ 10 en 24 heures.
• 'card _ token' : ≤ 2 declines consécutives sans 3DS ; la troisième est la 3DS obligatoire.
• 'ip' : ≤ 5 uniques 'card _ token' à 1 heure (sinon captcha/block).
• 'Compte _ id' : ≤ 2 dépôts annulés consécutifs ; ensuite - couldown 1 heure.

4) Algorithmes de restriction (court)

• Initialisez 'capacity' et 'refill _ rate'.
• Avant chaque tentative « retirer » 1 jeton ; s'il n'y a pas de tokens, challenge/decline.

• La file d'attente se déplace à une vitesse constante ; les événements qui arrivent débordent - throttle.

• 1ère répétition : 2-5 min → 2ème : 10-20 min → 3ème : 1-2 h → stop, ou conversion en méthode alternative.

5) Politiques de décision (decisioning)

• Allow : faible risque, dans les seuils.
• Challenge : dépassement du seuil « soft » → 3DS/SCA/captcha/KBA (questions).
• Throttle : limiter temporairement (couldown) avec UX transparent.
• Decline : violations flagrantes (surcharge massive de cartes, bot pool, bonus-abyse).
• Reroute : changement de PSP/méthode (par exemple, A2A) à une surtension de '91/96' chez l'émetteur.

Mini matrice d'exemples

'device _ id'tentatives de ≥ 3 en 15 min et 'cvv = N' ≥2 → Decline + capcha.
'card _ token' 2 soft-decline consécutivement → 3DS-challenge (obligatoire).
'ip' ≥ 5 unique 'compte _ id' en 30 min → Throttle 30 min + contrôle KYC.
'Compte _ id'dépôt-retrait-dépôt 10 min (carrousel) → Challenge ou limite de montant.

6) Velocity pour les dépôts, retraits et retraits

• Protégez les « micro-transactions » (beaucoup de petites transactions) : limite de quantité et chiffre d'affaires total par T.
• À la série « 05 »/« 14 »/« 54 » - arrêter le « dépassement » des détails, traduire en 3DS.

• Espacer le CIT et le MIT de la file d'attente. Pour le MIT, utilisez les fenêtres molles T + 1/T + 24h.
• Soft-decline 'SCA required' → immédiatement 3DS, ne brûlez pas les tentatives.

• Les limites séparées sur la somme/fréquence : par ex., ≤ 2 conclusions/24h et ≤ N selon la somme/semaine.
• « Échelle » KYC : plus la vérification est élevée, plus les limites sont élevées.
• Detect « circling » : dépôt rapide et retrait instantané - manual review/hold.

7) Promo anti-abyse et bonus

Caps par campagne : 'bonus _ id' ≤ X activations sur 'device _ id '/' ip '/' payment _ fingerprint'.
« Fourchettes » (transfert d'argent entre les comptes) : analyse graphique des cartes/IP/appareils partagés.
Windows cool-off : après le dépôt de bonus - interdiction de retrait instantané, règles transparentes dans ToS.
Sanctions par niveau : des blocages temporaires à « pour toujours », avec un journal des causes.

8) Architecture : Où vivre les règles de velocity

Passerelle temps réel (dans l'orchestrateur) : solution ≤ 50-100 ms.
Stockage de compteurs : In-memory (Redis/KeyDB) + résumés à long terme (DWH).
Fichestor : fenêtres uniques/agrégats (15m/1h/24h/7d).
Rule engine + ML scoring : « safety-net » règles sur le modèle.
Drapeaux Config : « inclure 3DS », « plus strict dans la région X », « pause PSP-A ».
Idempotence : protection contre les doublons lors des répétitions/temporisations.

9) Pseudo-code de règles (croquis)

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) modèles UX (sans casser la conversion)

Des messages clairs : "Trop de tentatives en peu de temps. Essayez dans 15 minutes ou confirmez à la banque".
Bouton Répéter plus tard avec minuterie.
Offre d'alternatives : A2A/porte-monnaie local lors de la trottinette.
Auto-3DS sans réintroduire les détails avec SCA-soft.
Le captcha n'est que ponctuel (IP/ASN/bot), pas pour tout le monde.

11) Conformité et vie privée

GDPR/PII : stockez des identifiants minimaux (hachages d'appareils, jetons de carte, last4), des politiques transparentes.
PCI DSS : pas de PAN/CVV dans les logs ; évènements velocity sans données sensibles.
PSD2/SCA : traduire les dépassements dans le challenge le cas échéant au lieu des abandons totaux.

12) Métriques, alertes, SLO

• Taux approval (général et lorsque les règles sont déclenchées).
• Faux Taux positif des règles de velocity (proportion de blocs honnêtes → sur la légitimité ultérieure).
• Nombre de « tempêtes » rétrogrades et temps de récupération moyen.
• Part des transferts de decline → challenge avec succès.
• Taux de charge dans les segments où les limites ont fonctionné (en attente de ↓).

• Spike '05/14/54' + croissance des tentatives> X en 15 min dans le cluster BIN/ASN.
• Surtension « 91/96 » → auto-élévation du seuil T1 + itinérance en PSP-B.
• FP-rate règles> cible (par exemple 1. 5 × médiane hebdomadaire).

• Solution velocity ≤ 100 ms p95.
• Proportion de paiements réussis transférés à 3DS au lieu de refuser ≥ cible.

13) Anti-modèles

Limite « totale » universelle pour tous les marchés et types de clients.
Bloquer par 'AVS = U/S/G' dans les pays où AVS ne fonctionne pas à plein temps.
Ne pas séparer CIT/MIT - brise les abonnements/répétitions.
Rétractez sans jitter et idempotence - prises et tempêtes.
Cacher les causes de l'échec - le sapport et la toxicité augmentent.

14) Chèque de mise en œuvre

• Carte des entités (scopes) et fenêtres (15m/1h/24h/7d).
• Choix des algorithmes : sliding + token bucket pour bursts.
• Normalisation des retraits : backoff + jitter, séparément pour le CIT/MIT.
• Intégration avec le 3DS/SCA : auto-challenge pour les dépassements doux.
• Limites distinctes pour les retraits et les primes ; Vérification graphique des liens.
• Observabilité : dashboards KPI/alerte/audit des règles.
• Modèles de messages UX et méthodes alternatives.
• Politiques PCI/GDPR : jetons, masquage, minimisation des PII.
• Tests A/B des seuils par marché/BIN/ASN et par profil client.
• Pleybooks incidents : dégradation de l'émetteur/PSP, surtension des bots.

15) Résumé

Les limites de velocity efficaces sont des fenêtres et des compteurs à plusieurs niveaux sur différentes entités, des algorithmes de lissage (token/leaky bucket), des retraits intelligents et un lien étroit avec le 3DS/SCA et le scoring. Une telle boucle réduit la fronde et l'abyse, n'étouffe pas la conversion, et aide à maintenir une monétisation stable avec la volatilité des émetteurs et du trafic.