Velocity Check

Velocity checks operate on the principle that most legitimate cardholders make payments at normal human rates, a few transactions per day, using a consistent set of billing addresses, devices, and email accounts. Fraudulent activity often involves abnormally high transaction rates as attackers attempt to use stolen card data before it is detected and blocked.

A velocity rule specifies an identifier type (card, BIN, IP, email, device ID), an event (authorisation attempt, decline, successful transaction), a count threshold, and a time window. When the count exceeds the threshold within the window, the rule fires, either declining the transaction, flagging it for review, or adding the identifier to a block list.

Attackers adapt to naive velocity rules. A rule blocking a card after 5 attempts in 10 minutes is easily circumvented by distributing attempts across multiple cards, IPs, and time windows. Effective velocity monitoring uses combinations of identifiers, flagging when a single IP submits 50 different cards, or when a single device produces transactions to multiple merchant accounts, to detect distributed attacks that circumvent single-identifier thresholds.

Time window selection affects rule performance: short windows (1 minute) catch burst attacks but miss slow-rolling enumeration. Longer windows (24 hours) catch sustained attacks but may generate more false positives on legitimate high-frequency users such as corporate travel bookers or marketplace platforms with many repeat purchasers.

Velocity rules are the primary defense against card testing: attackers who gain access to card data typically test validity with small-value transactions before using the card for high-value fraud. Velocity rules on authorisation attempts per card and per BIN range are the first line of detection.

False positive risk is significant on high-frequency merchant types: velocity thresholds appropriate for a general retailer may generate high false positive rates for a travel booking platform where the same corporate card books multiple flights in sequence. Thresholds should be calibrated to the merchant's legitimate transaction patterns.

Multi-identifier velocity is more effective than single-identifier: an attacker using one card number per session but operating from the same IP subnet or using the same device fingerprint will evade card-level velocity rules. Cross-referencing velocity across multiple identifiers closes these evasion paths.

Velocity data feeds into fraud score models: velocity signals are high-value inputs to ML-based fraud scoring. Velocity check infrastructure that produces clean, queryable velocity data by identifier enhances model performance beyond what static threshold rules achieve alone.