CVV attack detection in one paragraph

CVV attack detection finds card-testing traffic inside authorization records. The pattern is a burst of small authorizations across many card numbers, sent from a small set of devices or IP addresses, with a high share of CVV and address verification failures. Detection reads aggregates, not single transactions. One declined CVV check says little. Ninety declines from one IP in ten minutes says a test run.

What a card-testing run looks like

• Amounts cluster at $0.00 to $2.00, then a large purchase follows on a card that passed.
• Decline rate per device or IP sits far above the merchant baseline.
• Card numbers arrive in sequence or in blocks tied to one BIN range.
• CVV response codes repeat as failures while the same card clears other checks.
• Billing country, IP country and BIN country disagree.
• One device fingerprint maps to dozens of card numbers in a day.
• Account creation, address edits and checkout happen in the same session.

Signals ranked by value

Issuer decline codes carry the most weight. A CVV2 or CVC2 mismatch (Visa code N7 and its peers at other networks) is a failed verification, not a funding problem, and a cluster of them from one source is a strong sign. Card-testing tools guess CVV values, so they generate mismatch codes at rates a real customer base does not produce.

Velocity comes second. Count authorizations per IP, per device fingerprint, per email and per BIN in rolling windows of 10 minutes, 1 hour and 24 hours. Compare each count to the merchant baseline for that channel.

Amount clustering comes third. Test runs use small amounts to keep cost low. Flag any source whose median authorization sits below the 5th percentile of the channel.

Geographic mismatch and address verification results add context. None of them stand alone.

Where to instrument

• Authorization request and response logs, including the CVV result field.
• 3-D Secure outcome records.
• Device fingerprint and IP reputation feeds.
• Account and checkout event logs.
• Chargeback and fraud report data, fed back into rules.

Keep raw logs long enough to reconstruct a test run after the fact. Thirty days is a common floor. PCI DSS requires logging and review of activity in cardholder data environments.

Thresholds and response

Set alerts at three levels. A soft alert sends the source to review. A hard alert blocks checkout for that device or IP. A network alert pages the fraud team when the merchant-wide CVV failure rate moves above baseline by a set margin. Review thresholds against false positives each month. A rule that blocks one in four legitimate customers costs more than the fraud it stops.

What detection cannot do

Detection reads logs after the authorization attempt. It does not stop a test run that spreads across thousands of IP addresses and one card per address. Rate limiting, device fingerprinting and 3-D Secure reduce that volume at the front end. Tokenization removes the CVV from storage, which limits the value of a breach but does not change authorization behavior.