CVV fraud rules are the stack of requirements that decide who can see, store, and ask for the three or four digit security code on a payment card, and what happens when it does not match. Three layers stack on top of each other: PCI DSS, the card network operating rules from Visa and Mastercard, and the issuer's own risk logic. A merchant can satisfy one and still fail the other two.
The storage ban is the hard line
The code is Sensitive Authentication Data. PCI DSS Requirement 3.3.1 in v4.0 (it was 3.2 in the older version) says you cannot retain it after authorization, even encrypted. That sounds simple until you follow the data path. The CVV lands in gateway request logs, application debug output, call recordings, chat transcripts, emailed order confirmations, and printed batch reports. Those are the findings that turn a clean assessment into a failed one. If your support team asks a customer to read the code back over the phone and types it into a ticket, you have a storage violation.
You also cannot store it "just for disputes" or keep it in a hash for matching. The only allowed pattern is capture, send, discard, and keep a yes/no match result at most.
Network rules on when you must ask
Visa requires CVV2 validation for most card-not-present transactions, and Mastercard's CVC2 rules run the same way. Skipping the check usually means a worse interchange tier and weaker standing in a dispute. Both networks bar merchants from requiring customers to hand the code over by email or in a written form the merchant keeps. Some merchant categories also face extra scrutiny from the networks' fraud monitoring programs when their card-not-present fraud ratios cross set thresholds.
What the issuer sends back
The authorization response carries a result code for the code check. You will see an N for invalid, U for not verified, P for not processed, and S for not present. Treat N as a strong signal, not a maybe. Issuers score repeated mismatches on the same BIN or device as card testing, and they will start declining the whole neighborhood.
The rules merchants write for themselves
Most of the practical fraud defense is not written by a network. It sits in the gateway or order management system as custom rules. The ones I see doing real work:
- CVV mismatch plus AVS mismatch plus a new device, declined outright.
- Velocity caps per card, per IP, per email domain, and per shipping address.
- Blocking or reviewing high-risk BIN ranges and prepaid cards for high-ticket items.
- Flagging bursts of small authorizations, which is the classic card testing shape.
- Geo mismatch between billing country, IP country, and shipping country.
- Retry limits so a declined card cannot be hammered with variations.
None of these are magic. They work because they force a human look before goods ship.
Liability does not shift on a CVV match alone
A common misconception. In the US, a matching CVV does not move chargeback liability to the issuer. Liability shift comes from a successfully authenticated EMV 3DS transaction, and even then only under specific conditions. A CVV match is evidence, not a shield.
The legal side
Possessing, buying, or selling card account numbers and their verification codes without authorization is a federal crime under access device statutes, and state laws add more. "Valid" does not make it lawful. The rules above exist because issuers, networks, and law enforcement treat the code as an authentication secret. Anyone treating it as a commodity is on the wrong side of every layer described here.