Velocity Check

A velocity check is a test applied to a transaction that asks how often something has happened recently. It counts events linked to a particular data element, such as a card number, email address, device or shipping address, over a window of time, and compares the count with a limit. Five payment attempts on one card in a minute, or ten different cards used from one device in an hour, would fail a typical check.

The technique is one of the oldest and most widely used tools in payment fraud prevention, and the practice as a whole is described under velocity checking. It works because fraud at scale tends to be repetitive. A criminal with a list of stolen cards, or a script that automates purchases, produces bursts of activity that ordinary customers do not. A velocity check is usually written as a fraud rule inside a rules engine.

Every velocity check is defined by four choices.

• The element tracked. Card number, account, customer, email, phone number, device identifier from device fingerprinting, IP address, billing or delivery address.
• What is counted. The number of attempts, the number of declines, the total amount, or the number of distinct values of a second element, such as how many different cards have been used with one email.
• The time window. Seconds and minutes catch automated attacks. Hours, days and weeks catch slower abuse.
• The threshold and action. The level above which the transaction is declined, sent for review, challenged with step-up authentication or simply scored as higher risk.

Checks that count one element against another are particularly useful. Many cards on one device suggests a fraudster working through stolen details. Many devices or addresses on one card suggests the card details have been shared or sold.

The classic target is card testing fraud, in which criminals run large numbers of small authorizations to discover which stolen card numbers are live. The same pattern, repeated attempts with slightly different numbers, expiry dates or security codes, appears when attackers try to guess card details by enumeration. Both generate high counts of attempts and declines from a small set of devices, addresses or merchant accounts, and both are part of the wider practice of carding.

Velocity checks also help against account takeover, where a compromised account suddenly makes many purchases or transfers. They flag credential stuffing at login, shown by many failed sign-ins from one source. They catch abuse of promotions through multiple sign-ups from one device, and repeated refund or payout requests. Deliberate attempts to stay under limits by spreading activity are described as velocity abuse.

In anti-money laundering, the same counting logic appears in transaction monitoring scenarios that look for a rapid series of deposits and withdrawals, many small transfers to one recipient, or repeated transactions just under a reporting threshold, the pattern known as structuring.

The system must keep running counts for a very large number of keys and answer within the few milliseconds available during a payment authorization. Implementations use in-memory data stores that increment a counter for each key as events arrive and expire old entries as the window moves on. Sliding windows, which count back from the present moment, are more accurate than fixed calendar intervals, since they cannot be defeated by timing a burst across a boundary.

Merchants see only their own traffic, so their checks cover activity on their own site. Payment processors and card networks can count across many merchants, which reveals a card being tested at several places at once. Issuers count across everything a cardholder does. The related issuer-side control that caps a card's own usage is a velocity limit. Infrastructure-level rate limiting applies the same principle to requests per client, before any payment logic is reached.

A threshold that is too tight blocks good customers. Legitimate reasons for repeated attempts are common: a shopper mistypes a security code twice, a family shares one device and several cards, an office or university sends many customers through one network address, or a business buyer places many orders in a day. Analysts therefore study the normal distribution of each count before setting a limit, and often vary limits by customer segment, product or region.

Thresholds are tuned by measuring how many transactions each check stops and what share of those were actually fraudulent. Checks can feed a score instead of making a hard decision, so that a moderately high count contributes to risk without blocking on its own.

Velocity checks are simple, which is both their strength and their weakness. Attackers adapt by spreading activity across many devices, addresses and accounts, by using networks of compromised computers, and by slowing down to stay under known limits. A bot attack that rotates every tracked element can pass each individual check.

For these reasons velocity counts are used as inputs to broader systems as well as standalone rules. A machine learning fraud model typically includes dozens of velocity features calculated over different windows, combined with device, behavioral and network signals. The counts remain valuable because they are cheap to compute, easy to explain and effective against the high-volume attacks that cause sudden spikes in declines and processing fees.