Velocity Check
A velocity check is a fraud rule that counts how often, or how much, something has transacted in a window — a card used five times in ten minutes, a device that opened twelve accounts today, €5,000 through one account in an hour — and blocks, challenges or flags the transaction that crosses the limit. It is the oldest rule in the fraud engine and still among the most effective, because fraud is fast and repetitive.
- Also known as
- Velocity rule, Velocity limit, Frequency check
- Used at
- card authorisation (issuer and merchant side), account opening, login, payouts, and AML transaction monitoring (where the same idea is a structuring rule)
- Binding
- no — a control the firm designs; but scheme rules and regulators expect one, and card testing attacks against merchants without velocity limits are the commonest reason an acquirer terminates a merchant
- Typical keys
- card number, account, device fingerprint, IP address, email, phone, shipping address, BIN, merchant; typical windows: minutes for card testing, hours for account takeover, days for bust-out; typical actions: decline, step-up authentication, review, or a score contribution
- Typical failure
- limits set so low that a family sharing a card or a business buying in bulk is blocked, or so high that a card-testing bot runs a thousand €1 authorisations before the rule fires
- Parties
- the merchant's or payments company's fraud team, the rules engine or vendor, and the genuine customers on the wrong side of a limit
How a velocity check works in practice
A fraudster with a list of stolen card numbers tests them on a merchant's checkout with €1 purchases to see which are live — card testing. A velocity rule keyed on IP address and device sees the fifth attempt in a minute and blocks the rest; without it the merchant pays authorisation fees on a thousand attempts, its decline rate spikes, and its acquirer's monitoring letter follows. A rule keyed on card number stops the same card being used at ten merchants in an hour; one keyed on email stops an account-opening bot; one keyed on payout account stops a compromised platform draining funds. The keys and windows are the design: fraud has a shape in time, and velocity rules draw its outline.
The tuning is the work. Every limit is a trade between the fraud it stops and the customers it blocks: a limit of three transactions an hour per card blocks the parent buying three children's tickets; a limit of thirty catches nothing. Fraud teams set limits from their own data — the distribution of genuine behaviour, with the limit beyond its tail — and pair the rule with a step-up rather than a decline where the cost of a false positive is high. Machine-learning scores now absorb velocity as features, but the explicit rule remains for the attacks that arrive faster than a model retrains.
For an acquirer or a facilitator, velocity limits on merchants — volume per day, ticket size, refunds — are the underwriting caps enforced in real time.
Example
A ticketing merchant with no velocity rules is hit by a card-testing attack: 40,000 authorisation attempts of €1–3 in six hours from 200 IP addresses, 3% approved. Cost: €4,000 in authorisation fees, €1,100 of fraud, a decline rate of 97% for the day, and a letter from its acquirer. Its payments provider adds rules: five attempts per IP per ten minutes, three per device per hour, two per card per hour, a daily cap on €1–5 transactions per BIN, and a CAPTCHA step-up rather than a decline at the first limit. The next attack, a month later, is stopped at 900 attempts. Genuine customers blocked by the new rules: 14 in the month, all offered the step-up and 11 completing. The merchant's fraud team then raises the per-card limit for the on-sale morning of a major event, when genuine customers really do buy four times in an hour.
Common mistakes
- No velocity rules at all, which the card-testing bots find within weeks. - Limits set once and never revisited against genuine behaviour. - Declining at the limit when a step-up would keep the genuine customer. - Keying only on card number, when the attack rotates cards and keeps the device. - Forgetting that a promotion or an on-sale day is a legitimate velocity spike, and blocking the customers it was meant for.