Multi-card velocity per device
Counts distinct card fingerprints associated with the same device in 5-minute, 30-minute, and 2-hour rolling windows. The card rotates; the device doesn't. This is the most reliable single signal for card testing.
Card Testing Detection
The attack spans many cards. Your rate limits see only one.
Card testing attackers rotate across hundreds of card numbers and dozens of devices. Per-card rate limits don't fire because no single card exceeds the threshold. Riskgrove scores the cross-card pattern that exposes the attack.
Get a demo
cards_on_device_5min
47
device_decline_rate_1h
0.83
per_card_velocity_5min
1 (below limit)
cross_device_bin_cluster
DETECTED
composite_score
0.97
recommendation
BLOCK
Detection Signals
What Riskgrove reads for card testing
Card testing signals are cross-entity by nature. They only become visible when measured across device fingerprints, BIN ranges, and time windows simultaneously.
Device-level decline rate
Tracks the approval-to-decline ratio across all cards on a given device fingerprint over a rolling 1-hour window. Legitimate users rarely see decline rates above 10%. Card testing operations routinely reach 70-90%.
BIN cluster concentration
Stolen card batches typically come from the same BIN ranges. Riskgrove detects when many transactions from the same device or IP touch a narrow BIN range, a signature of testing a freshly acquired card batch.
Transaction timing regularity
Scripted card testing has a different inter-transaction time distribution than human browsing. Riskgrove measures the coefficient of variation in transaction timing to detect automated submission patterns.
Merchant category targeting
Card testers prefer merchants with low friction and digital goods. Riskgrove maintains a category risk profile and weights MCC codes that correlate with higher testing exposure.
Shared infrastructure clustering
Multiple devices using the same IP subnet, ASN, or residential proxy provider get cross-scored. Attackers spread across devices but rarely spread across ISP infrastructure.
Why Per-Card Rate Limits Fail
The blind spot in your current defense
Rate limits fire per card. Attackers work around them by spreading across cards. Here's the math that makes per-card limits fail against a typical card testing operation.
Scenario
What a per-card rate limit sees
What Riskgrove sees
100 stolen cards, 1 try each in 5 minutes
100 individual transactions, each at velocity 1. Zero cards exceed the rate limit. Zero blocks triggered.
Device has 100 distinct cards in 5 min. Score: 0.98. BLOCK.
50 cards across 20 devices from one ASN
Each device is below the per-device limit. Each card is below the per-card limit. No existing rule fires.
ASN decline cluster detected. BIN concentration identified. Score: 0.94.
500 cards over 2 hours, different IPs
IP-based blocking misses because IPs rotate. Rate limits still see 1 try per card per IP. No signal fires.
BIN clustering + timing regularity detected in the first 20 attempts. Score elevated.
Stop card testing at scale
See what your current rules are missing
We'll run the card testing module against a sample of your historical declines and show you the patterns your current stack didn't surface.