A thousand tiny charges before the big one
Before fraudsters spend a stolen card, they test it — thousands of micro-authorizations probing which numbers are live. Caught early, you stop the loss before it starts.
What we're seeing
Stolen and computer-generated card numbers are worthless until they're validated. So fraudsters run 'card testing': firing high volumes of tiny authorizations or low-value charges across merchants to discover which cards are live and which expiry/CVV combinations work.
It usually surfaces first wherever checkout is easiest — a donation form, a small e-commerce store, a SaaS signup. The tells are in the velocity and the pattern, never in any single transaction.
Why your current stack misses it
- Each authorization is tiny and individually unremarkable — a $0.50 charge trips no amount-based rule.
- A single-merchant view can't see that one actor is spraying sequential card numbers across dozens of merchants at machine speed.
The signal pattern
- Spikes of low-value authorizations or declines in rapid succession from one source.
- Sequential or patterned card numbers within shared BIN ranges, probed in bursts.
- Abnormal decline-to-approval ratios, then a few 'good' cards singled out.
- Repetition across many merchants or accounts that no single merchant can see alone.
What you'd do Monday morning
- Add velocity and pattern-repetition checks at the BIN / IP / device level, not just per-transaction amount.
- Throttle or challenge bursts of small authorizations from a single source.
- Correlate testing behavior across merchants so the network catches what one merchant can't.
Spot the Fraud
Read the case. Make the call. See how you score against The PreCogs.
A small nonprofit's donation form suddenly sees a burst of tiny authorizations overnight. Most decline; a few approve. Each charge is under a dollar. Clear it, or hold it?