What a velocity check does
A velocity check counts how often one identifier appears inside a set time window, then compares that count to a limit you define. Identifiers include card number, IP address, device fingerprint, email address, billing address, phone number, and card BIN. When a count crosses the limit, the rule blocks the attempt, flags it, or sends it to manual review. In card testing, the card number is the identifier that carries the most weight, because an attacker runs many numbers through one checkout page and needs each attempt to resemble a normal purchase.
Why card testing appears in velocity data
Card testing is the practice of submitting small authorizations to learn which stolen card numbers are still live. The attacker does not care about the goods. The goal is a yes or no answer from the issuer. That goal creates a signature in your logs: short intervals between attempts, a narrow pool of IP addresses and devices, low order values, a high decline rate, and a spike in attempts against cards you have never seen before. A single merchant may see hundreds of attempts in minutes. Velocity rules exist to catch that shape before the authorization requests reach the issuer.
Counters worth tracking
- Authorization attempts per card number, per hour and per day
- Distinct card numbers per IP address, per hour
- Declines per device fingerprint, per day
- Orders per email address and per shipping address, per week
- Share of attempts coming from one card BIN range
- Attempts per customer account, per session
How to set and tune thresholds
- Pull 90 days of transaction logs and separate confirmed fraud from legitimate orders.
- Chart each counter above against both groups so you can see where the two distributions split.
- Pick a starting limit that sits above the 99th percentile of legitimate traffic for that counter.
- Choose a window length. Short windows catch burst attacks; long windows catch slow, spread-out testing.
- Tier the response instead of blocking on the first breach. Flag at a low count, challenge at a mid count, block at a high count.
- Review every flagged order for a week and record how many were genuine customers.
- Adjust one threshold at a time and note the effect on approval rate and fraud rate.
- Document the rule set, the owner, and the last review date.
Pairing velocity rules with other checks
Velocity alone produces false positives, especially during promotions when real customers buy in bursts. Combine counters with checks that cost little to run: CVV verification results, AVS match codes, 3-D Secure authentication outcomes, and mismatches between billing country, IP country, and shipping country. A rule that requires two weak signals to fire together catches more fraud than a single hard threshold, and it keeps your approval rate steady.
Gaps that leave a merchant exposed
- Counting only by IP address, which attackers rotate through proxy pools
- Setting thresholds so high that a test run of 50 cards passes unnoticed
- Ignoring declined attempts, which carry the strongest card testing signal
- Never revisiting limits after a product launch changes normal buying behavior
- Failing to log rule decisions, which makes disputes and issuer inquiries harder to answer