CVV/CVC: the three digits that never survive an authorization

CVV (Visa's term), CVC (Mastercard's), and their equivalents are not random numbers stored on the card and checked against a database — generating one requires no lookup at all. It's the decimalized output of encrypting a short data field (the PAN, the card's expiration date, and a three-digit service code) under a pair of DES keys held only by the issuer, called CVK A and CVK B together forming a double-length 3DES key. Anyone who can recompute that same encryption — meaning only the issuer, or its outsourced HSM provider — can verify a CVV without ever having stored it anywhere.

The 3DES output is 16 hex digits, but a CVV has to be entirely numeric. Decimalization tables handle this: each hex digit 0–9 maps to itself, and each hex digit A–F maps to a fixed digit 0–5 (A→0, B→1, C→2, D→3, E→4, F→5), and the first three (or four) resulting decimal digits become the printed CVV. This is a fixed, public transformation — none of the actual security comes from decimalization being secret; all of it comes from CVK A/B never leaving the issuer's HSM.

CVV1 (encoded in the magnetic stripe's discretionary data), CVV2 (printed on the back of the physical card, used for card-not-present purchases), and iCVV (embedded inside the EMV chip) are computed with the identical formula and the identical CVK pair — the only input that changes between them is the service code. That one difference is entirely deliberate: a CVV2 captured from an online purchase will never validate as a CVV1, so stolen card-not-present data can't be used to encode a working counterfeit magnetic stripe, and a value skimmed from a chip's iCVV can't be replayed as a magstripe CVV1 either. Each version is cryptographically scoped to the channel it's meant to authorize.

The PCI Data Security Standard classifies CVV2 (along with the full magnetic stripe contents and PIN data) as Sensitive Authentication Data: it may be transmitted during authorization but must never be stored afterward — not encrypted, not hashed, not truncated, not at all, by anyone downstream of the authorization step. This is a stricter rule than PAN storage (which PCI DSS allows under strong protections) because CVV2's entire security model depends on the issuer being the only party who can compute it; a merchant's database holding even an encrypted copy would let anyone who later steals both the PAN and that database reconstruct exactly what's needed to commit card-not-present fraud, defeating the reason CVV2 exists in the first place.