Définition
Le Velocity Check — que l'on traduit parfois par « contrôle de fréquence » ou « contrôle de vélocité » — est un mécanisme de détection de fraude qui consiste à surveiller le nombre de tentatives de transaction associées à un même identifiant (numéro de carte, adresse IP, adresse e-mail, numéro de téléphone, device fingerprint) sur une fenêtre de temps donnée.
L'idée est simple : un client légitime passe rarement 12 commandes en 4 minutes avec 6 cartes différentes. Un fraudeur, lui, teste souvent des cartes volées en rafale jusqu'à ce qu'une passe. Le Velocity Check met un compteur sur ces comportements et déclenche une alerte (ou un blocage) dès qu'un seuil est franchi.
Dans l'écosystème DTC et e-commerce français, c'est une brique standard des outils comme Stripe Radar, Adyen RevenueProtect, Shopify Fraud Filter ou Riskified. C'est peu coûteux à implémenter, très efficace contre le card testing, et souvent la première ligne de défense avant les règles plus lourdes (3DS, vérification manuelle, blacklist).
Analogie
Imaginez un videur à l'entrée d'un club parisien. Il ne regarde pas seulement *qui* entre, il regarde combien de fois la même personne essaie d'entrer en 10 minutes. Si quelqu'un se présente 15 fois avec 15 fausses cartes d'invitation, le videur comprend vite que ce n'est pas un client normal : c'est un testeur.
Le Velocity Check, c'est ce videur, mais automatisé, avec un chronomètre et un compteur. Il ne juge pas la validité de la carte (ça, c'est le rôle de la banque), il juge la cadence.
Formule
Le calcul est volontairement simple. Pour chaque identifiant X (carte, IP, e-mail, device), sur une fenêtre glissante T :
Velocity(X, T) = Nombre de transactions impliquant X sur la période T
Règle de décision :
SI Velocity(X, T) > Seuil_T ALORS → flag fraude (review / blocage / 3DS forcé)
Exemples de seuils courants en DTC :
| Identifiant surveillé | Fenêtre T | Seuil typique | Action |
|---|---|---|---|
| Numéro de carte (PAN) | 1 heure | 3 tentatives | Blocage + alerte |
| Adresse IP | 10 minutes | 5 commandes | 3DS forcé |
| Adresse e-mail | 24 heures | 4 commandes | Review manuelle |
| Device fingerprint | 1 heure | 6 tentatives | Blocage |
| Téléphone | 48 heures | 3 comptes créés | Vérification SMS |
Données concrètes observées sur des marchands DTC français :
1. 70 % des attaques de card testing se produisent sur des fenêtres de moins de 15 minutes — un seuil de 5 tentatives/IP sur 10 min bloque la majorité sans impacter les clients normaux.
2. Un marchand de cosmétiques réalisant ~12 000 commandes/mois a réduit ses chargebacks de 38 % en ajoutant un simple Velocity Check sur l'e-mail (seuil : 3 commandes / 24 h).
3. Sur les plateformes de paiement, un taux de fausse alerte (faux positifs) supérieur à 2 % sur un Velocity Check est considéré comme trop agressif : il faut alors élargir la fenêtre ou monter le seuil.
Tableau comparatif : Velocity Check vs autres règles anti-fraude
| Critère | Velocity Check | Blacklist | 3D Secure | Scoring ML |
|---|---|---|---|---|
| Ce qu'il détecte | Fréquence anormale | Identifiants connus frauduleux | Authentification client | Patterns complexes |
| Coût d'implémentation | Très faible | Faible | Moyen | Élevé |
| Faux positifs | Modérés (si seuil mal calibré) | Quasi nuls | Faibles | Faibles |
| Efficace contre card testing | ✅ Excellent | ⚠️ Partiel | ✅ Oui | ✅ Oui |
| Temps réel | Oui | Oui | Oui | Oui |
| Dépendance aux données historiques | Non | Oui | Non | Oui |
| Idéal pour DTC débutant | ✅ Oui | ✅ Oui | ⚠️ Coûteux | ❌ Non |
Le Velocity Check n'est pas un remplacement : c'est la première couche. On le combine généralement avec une blacklist et un 3DS conditionnel.
Applications concrètes en DTC / e-commerce
1. Card testing sur une boutique Shopify
Un bot teste 200 cartes volées en 20 minutes. Sans Velocity Check, chaque tentative part en autorisation bancaire → frais, taux de refus qui explose, risque de voir le PSP suspendre le compte marchand. Avec un seuil à 5 tentatives/IP/10 min, le bot est bloqué après 5 essais.
2. Abus de codes promo
Un même client (même e-mail, même IP) crée 8 comptes pour utiliser 8 fois un code « -20 % première commande ». Un Velocity Check sur l'e-mail + IP + device le détecte immédiatement.
3. Attaque sur un lancement produit
Lors d'une drop limitée, des revendeurs utilisent des scripts pour passer 30 commandes en 2 minutes. Un Velocity Check à 3 commandes/24 h par carte + IP + adresse limite la casse sans bloquer les vrais clients.
4. Fraude au compte (account takeover)
Un attaquant teste des combinaisons e-mail/mot de passe, puis tente des achats. Le Velocity Check sur les tentatives de connexion et sur les commandes dans les minutes qui suivent est un signal fort.
5. Remboursements abusifs
Un client multiplie les commandes puis les retours. Le Velocity Check sur l'historique (ex. : > 5 retours / 30 jours) déclenche une revue manuelle.
Erreurs fréquentes
❌ Seuil trop bas
Bloquer dès 2 commandes/heure par IP bloque les familles, les colocations, les entreprises, les cybercafés, les réseaux mobiles partagés (CGNAT). En France, les IP mobiles sont massivement partagées : une IP Orange ou SFR peut représenter des milliers d'utilisateurs légitimes.
❌ Ignorer le CGNAT et les VPN
Beaucoup de clients légitimes utilisent un VPN (NordVPN, Proton, etc.). Un Velocity Check uniquement basé sur l'IP va générer des faux positifs. Il faut croiser les signaux : IP + device + e-mail + carte.
❌ Fenêtre unique
Utiliser une seule fenêtre (ex. 1 h) laisse passer les attaques lentes (1 tentative toutes les 2 h sur 3 jours). Il faut plusieurs fenêtres : 10 min, 1 h, 24 h, 7 jours.
❌ Pas de logging
Sans historisation des tentatives (même refusées), impossible de calculer la vélocité. Le logging est la fondation : chaque tentative doit être stockée avec timestamp, IP, device, PAN hashé, e-mail.
❌ Confondre Velocity Check et rate limiting
Le rate limiting protège l'infrastructure (API, serveur). Le Velocity Check protège contre la fraude paiement. Les deux sont complémentaires mais ne se substituent pas.
❌ Oublier la conformité
Stocker des PAN en clair est interdit (PCI-DSS). On stocke un hash ou un token. Idem pour les données personnelles : RGPD impose une durée de conservation limitée et une finalité claire (lutte anti-fraude = base légale « intérêt légitime »).
Termes liés
- Card Testing — attaque consistant à tester massivement des cartes volées.
- Rate Limiting — limitation du nombre de requêtes par client/API.
- Device Fingerprinting — identification d'un appareil via ses caractéristiques.
- 3D Secure (3DS2) — authentification forte du porteur (DSP2 / ACPR en France).
- Chargeback — contestation de paiement par le porteur.
- Blacklist / Whitelist — listes d'identifiants bloqués ou autorisés.
- Risk Scoring — score de risque agrégé (ML + règles).
- PSP (Prestataire de Services de Paiement) — Stripe, Adyen, Mollie, Payplug, etc.
- CGNAT — partage d'IP par les opérateurs mobiles, source majeure de faux positifs.
- Friendly Fraud — fraude commise par un client légitime (contestation abusive).