CVV Attack IOC Monitoring: Card Testing Detection Guide

Quick answer

A CVV attack is automated card testing. Someone runs thousands of small authorization attempts against stolen card numbers to learn which ones are still live, then sells or uses the survivors. The indicators of compromise are not exotic. They surface as decline-rate spikes, tight velocity clusters per IP or device fingerprint, oddly uniform transaction amounts, and BIN ranges that arrive in numeric order. Watch those four signals together and you catch most campaigns during the probing phase, well before the attacker shifts to high-value purchases.

Why card testing does not look like ordinary fraud

Normal fraud is a small number of expensive transactions. Card testing is the opposite: a large number of cheap ones. Attackers keep amounts low because a $0.50 authorization often clears without a manual review, and because they only need the response code, not the goods. That inversion is what makes detection possible. If you only alert on transaction value, you will miss every one of these campaigns.

The IOCs I alert on

Authorization layer

• Decline rate for a single merchant or endpoint jumping from a stable baseline to double or triple it inside an hour.
• Clusters of identical or near-identical amounts, especially sub-$2 values, repeated across many card numbers.
• Sequential or near-sequential card numbers submitted from the same session or IP block.
• High counts of CVV or AVS mismatch responses with no successful follow-up purchase.
• Card numbers spanning many different BINs, or many cards sharing one BIN, arriving in a compressed time window.
• A single card number tested across multiple merchants or storefronts in minutes.

Session and device layer

• One device fingerprint or cookie tied to dozens of distinct card numbers.
• Checkout sessions with no browsing history, no cart, and no product page views before the payment step.
• Form fill times that are too fast or too uniform to be human.
• Repeated failures followed by an immediate retry with a new card and no other change to the session.
• Billing data that fails to match the card country, or addresses that look generated.

Network layer

• Traffic concentrated through datacenter ASNs, residential proxy pools, VPN ranges, or Tor exit nodes.
• A mismatch between the IP geolocation and the card's issuing country, repeated at scale.
• Headless browser signatures: missing fonts, absent plugins, unusual TLS fingerprints, or user agents that disagree with the rest of the request.
• Requests arriving in machine-regular intervals rather than human-paced bursts.

How I build the monitoring loop

1. Baseline first. Establish what a normal hour looks like for authorization volume, decline rate, and unique card count per merchant. Without a baseline, every threshold is a guess.
2. Write rules on ratios, not raw numbers. A decline rate of 40 percent means nothing for one merchant and everything for another.
3. Correlate the three layers. An IP with high velocity alone is noise. An IP with high velocity, five card numbers, and a 90 percent decline rate is a campaign.
4. Route alerts into the same queue your fraud analysts already use, with the raw authorization records attached. Triage speed matters more than alert elegance.
5. Feed confirmed hits back into blocklists, velocity caps, and your acquirer's fraud desk. Card testing is network-wide, so shared intelligence pays off.

Thresholds and false positives

Legitimate spikes exist. Gift card promotions, flash sales, and subscription retry logic all produce odd authorization patterns. I tune by testing each rule against 30 days of historical traffic and asking how many alerts a week it would have produced and how many were real. Rules that fire constantly get ignored, which is worse than no rule at all. Start loose, tighten as you learn what your own fraud looks like.

What to do when an indicator fires

Rate limit or challenge the source, not the entire merchant. Add the IP range or device fingerprint to a temporary block, enable CAPTCHA or 3D Secure step-up on the affected checkout, and review whether any low-value authorizations were followed by successful high-value orders from the same fingerprint. Notify your acquirer, since a testing wave usually hits several merchants at once. Then write down what you saw in a form your team can reuse, because the next campaign will look almost identical.