CVV Fraud Rules: How Card Verification Rules Work

CVV fraud rules are the mix of card network mandates, issuer checks, and merchant risk controls that decide whether a card-not-present transaction is approved, flagged, or reversed. The central rule is narrow: the card verification value printed on the card has to match the value the issuer holds before the transaction settles. Everything around it, from address verification to velocity caps to chargeback monitoring programs, exists to catch the orders where a stolen number arrives without a working code or gets reused too often to be genuine.

What the CVV check validates

The code is a short numeric value that issuers print separately from the account number. On most cards it is three digits on the back near the signature panel; on American Express it is four digits on the front. It is not encoded in the magnetic stripe and it does not appear on a receipt or in a standard transaction record. That separation is the entire point. Someone who copies a card number from a database still needs a different piece of data to pass a card-not-present authorization.

During authorization the merchant sends the code in the payment request. The issuer compares it with the value on file and returns a match, no match, or not processed response. A no match result is a decline on a card-not-present order in nearly every configuration. Repeated mismatches on the same card, device, or merchant account are read as one pattern, not as unrelated events.

Rules that apply before authorization

CVV verification is one control among several, and it is weak on its own because the code travels with the rest of the card data when a site is breached. These checks run before the issuer ever sees the request:

• Address Verification Service compares the billing street number and postal code against issuer records.
• Velocity rules cap how many authorizations a single card, device, IP address, or email can generate in a fixed window.
• Card testing detection looks for clusters of small authorizations, which is the signature of someone validating a list of stolen numbers.
• BIN and geography rules block or step up orders where the card's issuing country does not match the buyer's location or the shipping address.
• Device and behavioral signals flag automation, rapid form fills, and mismatched browser fingerprints.

Rules that apply after authorization

Approval is not the end of the process. When a cardholder disputes a charge, the reason code attached to the chargeback determines who carries the loss, and fraud reason codes are treated differently from service disputes. Card networks also run merchant monitoring programs. A merchant whose dispute ratio crosses a published threshold enters a program that carries monthly fines and remediation requirements, and the thresholds are stricter for card-not-present volume than for card-present.

Storage rules under PCI DSS

PCI DSS classifies the CVV as sensitive authentication data. Merchants and processors may not store it after authorization, and it cannot be retained even in encrypted form. The rule covers paper, logs, call recordings, support tickets, and database columns. An operation that keeps codes to reduce friction is out of compliance, and if it is breached, it has handed attackers the exact data set that the CVV check was meant to require.

Three control stacks compared

CVV verification alone

• Pros: one field, no extra step for the buyer, minimal integration work.
• Cons: useless after a breach that exposed stored codes, no defense against a cardholder who disputes a legitimate charge, high chargeback exposure.

Reasonable only for low-ticket digital goods paired with tight velocity limits.

CVV with AVS and velocity limits

• Pros: inexpensive, catches carding runs quickly, works with existing gateway settings.
• Cons: AVS is not supported in every market, gift orders and moves trigger false declines, still no cardholder authentication.

Best fit for physical goods shipped to an address the issuer can confirm.

CVV with 3-D Secure authentication

• Pros: shifts liability for fraud chargebacks to the issuer when authentication succeeds, adds a real cardholder step.
• Cons: the extra step reduces conversion, coverage varies by region and issuer, low-value transactions are often exempt.

Best fit for high-ticket or cross-border orders where a single loss outweighs the conversion cost.

Where CVV rules do not protect you

• Friendly fraud, where the cardholder authorized the purchase and disputes it afterward.
• Account takeover, where the thief uses the cardholder's own stored credentials.
• Recurring billing abuse, where an initial valid charge hides later unauthorized ones.
• Breaches at merchants that stored codes against the PCI DSS prohibition.

Legal exposure for card data

Trafficking in card numbers and verification codes is a federal crime under 18 U.S.C. Section 1029, which covers unauthorized access devices including account numbers. Buying, selling, or using stolen CVV data carries prison time and restitution, and that exposure is separate from any civil claim an issuer or cardholder files. The rules governing that market are criminal statutes, not payment network policies.

Practical checklist for merchants

1. Send the CVV on every card-not-present authorization and decline on no match.
2. Confirm that no system, log, or script writes the code to storage.
3. Set velocity limits per card, device, IP, and email, and alert on clusters of small authorizations.
4. Turn on AVS and review declines rather than auto-voiding every mismatch.
5. Apply 3-D Secure to high-risk segments instead of the entire catalog.
6. Track your dispute ratio monthly and act before it reaches a network threshold.