A CVV velocity check is a fraud rule that counts how many times a card verification value is submitted for the same card, customer, device, or IP address inside a set time window. When the count crosses a threshold, the processor declines or flags the transaction even if the card number and CVV are correct. The control exists because a single valid CVV proves little; a pattern of repeated attempts is the stronger signal.
Why a correct CVV is not proof of a legitimate buyer
The CVV is a three- or four-digit value printed on the card and never stored by the merchant after authorization. A fraudster who holds stolen card data will often submit the same number across many orders, or test several CVV guesses against one card, until a charge approves. Velocity checks catch that repetition before the loss lands. They do not verify identity; they limit exposure.
What a velocity rule counts
- Authorization attempts per card number, usually on a hashed token rather than the raw PAN
- CVV mismatch attempts per card within a rolling window
- Orders or attempts per IP address and per device fingerprint
- Attempts per email address, phone number, or billing address
- Attempts per card BIN range, which catches bulk testing across a portfolio
How thresholds get set
Thresholds come from three inputs: your baseline approval volume, your chargeback rate by segment, and the issuer's own limits. A subscription merchant with repeat customers needs a wider window than a one-time retail seller. Most teams start with a hard block at three CVV failures on one card in 24 hours, plus a soft review trigger at two. BIN-level rules belong at a higher count, since a single BIN covers thousands of legitimate cards.
Configuring the rule
- Pull twelve months of authorization logs and segment them by card token, IP, device, and email.
- Measure the 99th percentile of attempts per segment per day to find your normal ceiling.
- Write the rule to block at that ceiling and to flag one step below it.
- Set the window length: 1 hour for card testing, 24 hours for account takeover, 7 days for resale fraud.
- Route flagged attempts to manual review instead of an automatic decline when order value is high.
- Log the rule version and the outcome so you can measure false positives after 30 days.
- Re-tune quarterly, or after any campaign that shifts your traffic mix.
Reducing false declines
Cardholders mistype CVVs, and family members share devices and IP addresses. Exempt verified customers with a clean order history from the card-level rule, keep the device-level rule active, and use issuer step-up authentication instead of a flat decline when the bank supports it. Track decline reasons by code so a velocity block is never confused with an insufficient-funds decline.
Compliance notes
PCI DSS prohibits storing the CVV after authorization in any form, including encrypted. Velocity rules must therefore key on a token or hash, not on the value itself. Counters that persist the CVV to compare later violate the standard and create a breach liability far larger than the fraud they prevent.