The Four Things Called the Security Code

13.0 What this chapter gives you#

1. You will be able to name the four values that a card carries under the heading “security code” — CVV1, CVV2, iCVV and dCVV — and say which of the four reading interfaces each one belongs to.
2. You will be able to explain why a criminal who copies every byte out of a chip onto a blank magnetic stripe gets a card that declines, and name the single issuer check that makes it decline.
3. You will be able to say why that same attack nevertheless succeeded against a supermarket group and a Georgia liquor retailer in 2020, and what the issuers concerned had failed to do.
4. You will be able to derive all three static values from the same algorithm, and explain why feeding in a service code of 000 rather than 999 changes every digit of the answer with no pattern connecting them.
5. You will be able to tell a caller that no bank anywhere can look up the printed code and read it back, because nothing is stored and every value is recomputed inside a hardware security module at authorisation time.
6. You will be able to correct the folklore that iCVV is what makes a chip transaction impossible to counterfeit, and name the Application Cryptogram as the actual defence.
7. You will be able to read a POS entry mode field and predict which value the issuer will compute, and so diagnose the decline caused by a terminal that reads a chip and reports a swipe.
8. You will be able to trace the printed code through the authorisation message on both Visa and Mastercard, and interpret the result codes M, N, P, S and U without treating them as the authorisation decision.
9. You will be able to list the places where PCI DSS requirement 3.3.1.2 is most often broken — debug logs, crash dumps, access logs, queues, call recordings, paper and backups — and explain why encrypting a retained code is no defence at all.
10. You will be able to explain why a monthly subscription can never re-present the printed code, and why the merchant must retain the M result instead of the value.

Ask a room of payments people what “the CVV” is and you will get one answer: the three digits on the back of the card. Ask the same room what the issuer’s authorisation host actually checks, and the answers begin to diverge, because there is not one such value on a modern card. There are at least four. They are computed by the same family of algorithm, by the same machine, from mostly the same inputs, and they come out looking identical — three unremarkable decimal digits. They are not interchangeable. Presenting the wrong one at the wrong interface is precisely the event that a large part of card security is designed to detect.

The four are conventionally named CVV1, CVV2, iCVV and dCVV. Three of them are burned into the card once, at personalisation, and never change. One of them is manufactured fresh for every tap. One of them is printed in ink where a human can read it, and is the only one of the four that a merchant is forbidden to keep. The industry uses different names for all of them depending on which scheme’s rulebook is open on the desk, which is why the same value can appear in three different documents as CVV, CVC and CID without anybody being wrong.

This chapter separates them. It explains what each one is a defence against, why removing any one of them would open a specific and historically exploited hole, and — the question that this chapter exists to answer properly — why copying the data off a chip and writing it onto a blank magnetic stripe does not give you a working card, except when an issuer has failed to do the one check that makes it not work.

The plain version#

Imagine a building with four different doors: a front door, a side door, a delivery entrance and a gate at the back that opens onto the car park. All four doors belong to the same building. The same security office issues the passes for all four. But each door has its own pass, and the passes are deliberately different from one another, so that a pass for the delivery entrance is refused at the front door even though it was issued by the same office to the same person on the same morning.

Your bank card is that building. The four doors are the four ways a shop can read it.

The first door is the brown stripe on the back. A machine drags the card through a slot, reads the magnetism, and gets a line of digits.

The second door is the printed code, the three digits on the signature panel. Nobody’s machine reads that. A human reads it, off the card in their hand, and types it into a website or reads it down a telephone.

The third door is the chip, the little gold rectangle. A terminal pushes the card into a slot, the chip wakes up, and the terminal asks it questions.

The fourth door is the tap. The card has an aerial hidden inside the plastic, and holding it near a reader lets the two of them talk by radio for about a fifth of a second.

Four doors, four passes. That is all “the four things called the security code” means.

The pass machine#

The bank has a machine — really a locked box in a data centre, but think of it as a machine — that makes these passes. You feed it three things: your card number, your expiry date, and a three-digit door number. It thinks for a moment and prints out three digits.

The clever part is that the door number goes into the calculation. Change the door number, and every digit of the answer changes completely. There is no pattern connecting them. Knowing the answer for one door tells you nothing at all about the answer for another.

So the bank runs the machine three times for each card it makes. The numbers below are invented for the example — only the bank’s machine knows the real ones — but the shape of what happens is exactly right.

Three passes. One card. Nothing about 561 helps you guess 348 or 907.

Why this stops a thief#

Here is the attack the third row exists to defeat, and it is worth walking through slowly because it is the point of the whole chapter.

A criminal gets hold of a shop’s card terminal, or infects the shop’s till computer with software that watches everything the terminal sends. A customer inserts a chip card. The criminal’s software captures everything the chip said: the card number, the expiry date, and the chip’s pass — 907.

Now the criminal buys a blank plastic card and a stripe-writing machine, both of which are cheap and legal, and writes the stolen data onto the stripe. The card number is right. The expiry is right. The pass written into the stripe is 907, because 907 is what was stolen.

The criminal walks into a shop and swipes it.

The shop’s till sends the card number, the expiry date and the pass it just read — 907 — to the bank. The bank looks at the message and sees that this came in through the stripe door. So it runs its machine with the stripe’s door number, 101, and gets 561.

907 is not 561. Declined.

The criminal has a perfect copy of the card number and it is worthless at the stripe door, because the pass he stole was cut for a different door. That is the entire idea. It is called iCVV — the “i” is for the chip inside — and it is the reason the industry did not simply copy the stripe’s pass into the chip when chips were introduced. Had it done so, every chip terminal in the world would have been a machine for mass-producing stripe clones.

The fourth pass is different#

The tap door does not use a stored pass at all. It makes one up each time.

Inside the chip there is a counter. It starts at 1 when the card is made and goes up by one every single time the card is used. Nobody can wind it back. When you tap, the chip takes the current counter value, mixes it with a random number the reader has just invented, does its sum, and produces a fresh three-digit code that has never existed before and will never be valid again.

Somebody actually recorded this happening. A researcher held the same contactless card against a reader four times in a row and wrote down what came out each time. The card number was identical every time. The expiry date was identical every time. The last stretch of digits was different every time:

...0000072029191
...0000018129281
...0000054629311
...0000099829771

Same card, four seconds apart, four different endings. Copy one of those and try to use it again and the bank sees a counter value it has already seen, and refuses. This is called dCVV, for dynamic — a pass that is only good for one entry.

So why four?#

Because each door is attacked differently.

The stripe is trivially copyable, so its pass exists only to prove that the copier saw a real stripe rather than merely learning a card number from a receipt.

The printed code is not in the card’s data at all, anywhere, in any machine-readable form. That is its whole purpose. If a thief steals a database of card numbers from a shop’s computer, or reads them off a stripe with a skimmer glued inside a cash machine, he does not get the printed code, because the printed code was never in the data. He would have had to physically hold the card and turn it over.

The chip’s pass exists to keep the chip from becoming a stripe-cloning service, as above.

And the tap’s pass exists because radio is broadcast: anyone standing nearby with the right aerial might overhear, so nothing overheard may be worth replaying.

One thing, many names#

Visa calls it CVV, for Card Verification Value. Mastercard calls it CVC, for Card Validation Code. American Express calls it CID, and prints four digits on the front of the card rather than three on the back. Discover also says CID. JCB says CAV. China UnionPay says CVN. They are the same idea. When a specification says “CVC 2” and another says “CVV2”, they mean the printed code, and a system that handles both must simply know that it is being told the same thing twice in two dialects.

The rule to remember#

Of the four, exactly one must never be written down by anybody except the bank: the printed one. A shop is allowed to keep your card number for refunds. A shop is never allowed to keep the printed code — not in a database, not in a spreadsheet, not in a note on an order, not scribbled on a pad by the till. The moment a shop’s payment has gone through, that code must be gone. Its only value is that it is scarce, and a code that thousands of shops are storing is not scarce.

Where the plain version stops being true#

The building-with-four-doors picture gets you to the right conclusion, and it is wrong in four ways that matter to anyone implementing this.

There is no stored pass anywhere, and no lookup#

The plain version implies the bank keeps a list: card 4123..., stripe pass 561, printed pass 348. It does not. Nothing is stored. Each value is recomputed from scratch at authorisation time, inside a hardware security module, from the card number, the expiry date, the service code and a pair of secret keys, and the freshly computed answer is compared with whatever arrived in the message. The keys are the only thing kept.

This has a consequence that surprises people, including bank staff: an issuer cannot look up your CVV2 and tell you what it is. It can only regenerate it. Some issuers’ card-management systems expose that as a function, most deliberately do not, and none of them are reading it out of a column in a table. Similarly, when a call centre says “we can see the last four digits”, they mean the card number; there is no screen anywhere with your printed code on it.

Four is a simplification in one direction and an undercount in the other#

“Four” is a teaching number. In practice the same personalisation run may produce a CVV1 for the stripe, a distinct value for track 1 and track 2 discretionary data if the issuer chooses to differ them, an iCVV for the contact chip, a separate contactless value, a CVV2 for print, and — for issuers who offer it — a rotating code shown in the banking app that changes every few minutes. Card-not-present verification values used inside 3-D Secure are a separate family again, and are not card verification values at all.

Pulling the other way, the four are not equals. CVV1, CVV2 and iCVV are static three-digit numbers. dCVV and its Mastercard equivalent are dynamic. And none of them is what actually secures a chip transaction.

The security code is not why chip transactions cannot be cloned#

This is the correction most worth internalising, because the popular explanation is backwards.

A chip transaction is not made hard to counterfeit by iCVV. It is made hard to counterfeit by the application cryptogram — a message authentication code the chip computes over the transaction amount, currency, date, terminal country, a terminal-supplied random number and its own transaction counter, using a key derived from a master key that the chip will not disclose and cannot be read out of it. Chapter 5 of this volume is entirely about that cryptogram. A criminal holding every byte of static data from a chip still cannot produce a valid cryptogram for tomorrow’s £47.20 purchase in Leeds, because he does not have the key.

iCVV is not the lock on the chip door. iCVV is the thing that stops data taken from the chip door being reused at the stripe door. It is a cross-channel defence, not a chip defence, and it is doing a much narrower job than the folklore suggests.

The codes are only worth anything if somebody checks them, and sometimes nobody does#

All of this assumes the issuer validates. In 2020 researchers at Cyber R&D Labs tested chip card implementations from ten banks across Europe and the United States, harvested data from four of them and produced cloned magnetic stripe cards that were used to place real transactions. In the same period, Gemini Advisory documented what it called EMV-Bypass Cloning in two breaches — a supermarket group where more than 720,000 cards were compromised from 16 January 2020, and a Georgia liquor retailer on 29 June 2020 — in which iCVV harvested from chip transactions was written onto counterfeit stripes and worked, because the issuers concerned were not checking that the value arriving on a stripe transaction was the stripe’s value.

Visa’s own commentary on those events makes the conditionality explicit: the data available from a chip transaction is the account number, iCVV and expiry date, and “provided iCVV is validated properly, the risk of counterfeit fraud was minimal”. Provided. The mechanism is sound. Its deployment is uneven, and it is smaller issuers and processors, not the large ones, where the check has been found missing.

There is a fifth, subtler failure in the same family. The service code is an input to the calculation, but it is also a field that travels in the message. Visa has warned acquirers and issuers that service codes of 000 or 999 should never be encoded on a magnetic stripe, and that it “is aware of scenarios in which either 000 or 999 has been encoded on the magnetic stripe of counterfeit cards, resulting in issuer fraud losses”. The attack is exactly what it sounds like: if an issuer’s validation takes the service code from the incoming track data rather than from its own record of the card, a fraudster can encode 999 on the stripe alongside a stolen iCVV, and the issuer will helpfully compute the chip’s value and find that it matches.

The technical version#

Where each value physically lives#

The magnetic stripe layout is defined by ISO/IEC 7813, which specifies the data structure and content of tracks 1 and 2. Track 1, Structure B, carries up to 79 alphanumeric characters; track 2 carries up to 40 numeric characters at a lower recording density but a more compact character encoding. Track 3, defined separately in ISO/IEC 4909, holds 107 numeric characters and is unused by the card schemes in practice.

The field order on track 2 is: start sentinel ;, primary account number of up to 19 digits, field separator =, expiry date as YYMM, three-digit service code, discretionary data, end sentinel ?, and a longitudinal redundancy check character. Track 1 is the same information plus a format code B, the cardholder name between ^ separators, and its own discretionary data field.

Discretionary data is where CVV1 lives. ISO/IEC 7813 does not say what goes in it; it is left to the issuer. What the schemes put there is the three-digit card verification value, usually followed by a PIN verification key indicator and PIN verification value, and padding.

For the chip, EMV Book 3 defines tag 57, Track 2 Equivalent Data, described as containing “the data elements of track 2 according to ISO/IEC 7813, excluding start sentinel, end sentinel, and Longitudinal Redundancy Check”, packed two digits to a byte with hexadecimal D standing in for the = separator and a trailing F nibble as padding where the length is odd. Tag 9F1F is Track 1 Discretionary Data. Tag 5F30 is the service code, formatted n 3 in two bytes.

The composite picture:

The generation algorithm#

The card verification value algorithm originates with Visa and is implemented identically in every payment HSM. It is not published by the schemes, but it is documented in the command sets of the HSM vendors and in IBM’s cryptographic coprocessor documentation, which describes the Visa CVV as calculated by “the DES-encryption of the PAN, the card expiration date, and the service code using two data-encrypting keys or two MAC keys”. Those two keys are the card verification key pair, conventionally CVK A and CVK B.

The steps are:

1. Concatenate the primary account number, the expiry date and the three-digit service code as decimal digits, left-justify the result in a 128-bit field and pad to the right with binary zeroes.
2. Split the 128-bit field into two 64-bit blocks, Block 1 and Block 2.
3. DES-encrypt Block 1 under CVK A.
4. Exclusive-OR the result with Block 2.
5. Apply the EDE sequence to that: encrypt under CVK A, decrypt under CVK B, encrypt under CVK A. This is Triple DES with a two-key bundle.
6. Decimalise the 16 hexadecimal digits of the result in two passes. The first pass walks left to right and extracts every digit in the range 0 to 9. The second pass walks left to right again and extracts every digit in the range A to F, subtracting 10 from each so that A becomes 0 and F becomes 5. Concatenate the two extracted strings.
7. Take the leftmost three digits. For American Express, which prints four, take four.

Everything about which value you get is decided by step 1. The keys are the same, the arithmetic is the same, the only thing that varies is what you feed in:

Note carefully what this does and does not say. The 999 used to compute iCVV is a value fed into the calculation. It is not a claim about what is encoded in the service code field of tag 57. Whether an issuer also encodes a distinguishing service code in the chip’s Track 2 Equivalent Data is an issuer decision and implementations differ; Visa’s warning about 000 and 999 on counterfeit stripes only makes sense in a world where the encoded field and the calculation input are separable things. Nothing in the algorithm requires the same key pair to be used for all three values either, and an issuer is free to provision a separate card verification key for iCVV; Amazon’s payment cryptography documentation, for one, creates the iCVV key as a card verification key in its own right rather than reusing an existing one.

The output space is three decimal digits, so a thousand possibilities. That is deliberately weak against brute force and deliberately strong against the thing it is for. Guessing a CVV2 for a known card number takes on average 500 attempts, which is why the defence against CVV2 guessing is not the code’s length but the issuer’s velocity controls and the scheme’s rules on repeated declines.

CVV1 and the magnetic stripe path#

When a card is swiped, the terminal sends what it read. In ISO 8583 that is data element 35 for track 2 and data element 45 for track 1, and the schemes overwhelmingly prefer track 2: Visa’s guidance to acquirers is blunt that “Track 1 should not be supported in the authorization message.”

The issuer’s decision about which value to compute is driven by data element 22, POS entry mode. The values that matter here, in Visa’s numbering, are 01 for manual key entry, 02 or 90 for a magnetic stripe read, 05 or 95 for a contact chip read, 07 for contactless using chip data rules and 91 for contactless using magnetic-stripe data rules. A fallback swipe — a chip card at a chip-capable terminal where the chip could not be read — carries its own distinct entry mode so that the issuer can see it happened, which is the basis of every fallback-monitoring rule the schemes operate.

Entry mode is therefore load-bearing in a way that is easy to underestimate. Visa’s own instruction to devices is that “if a transaction is processed as magnetic stripe, the track data used in the transaction is read from the magnetic stripe and correspondingly, if a transaction is processed as chip, the track data used should be read from the chip”, and that the entry mode field “must be accurate to avoid unnecessary declines”. A terminal that reads the chip and reports entry mode 90 will hand the issuer chip-derived track data labelled as a swipe, the issuer will compute CVV1, the iCVV will not match, and the transaction will decline for reasons that will take the merchant’s acquirer several days to work out.

The corresponding rule for chip data is that “the terminal must always transmit the full, unmodified contents of the Track 2 Equivalent Data in the chip to the acquirer including the Issuer Discretionary data”. Terminals that trim, re-pad or normalise the discretionary data destroy the iCVV in the process. This is a real and recurring integration defect, particularly in software stacks that parse tag 57 into fields and then reassemble it.

CVV2 and the card-not-present path#

CVV2 is printed, never encoded. On Visa, Mastercard and Discover it is three digits in or beside the signature panel on the reverse. On American Express it is four digits printed on the front, above and to the right of the embossed account number, and Amex calls it the Card Identification Number.

Its carriage in the authorisation message is scheme-specific and this is one of the places where a generic integration goes wrong. In VisaNet the value travels in Field 126, usage 10, CVV2 Authorization Request Data, and the result comes back in Field 44, usage 10. In Mastercard’s Authorization Request/0100 the value goes in data element 48, Additional Data — Private Use, subelement 92, and the result returns in DE 48 subelement 87, Card Validation Code Result.

The result codes are common across both:

Two operational points follow. First, the CVV2 result is not the authorisation decision. An issuer may return an approval with a result of N. Whether the merchant proceeds is the merchant’s risk decision, and a great many merchants approve transactions their own issuer has told them did not match. Second, the result is durable evidence. Mastercard’s chargeback rules for recurring transactions accept, as part of the merchant’s defence, that the CVC 2 was provided in the initial Authorization Request/0100 and that DE 48 subelement 87 came back with a value of M. The result code may be retained. The code itself may not.

iCVV and the chip#

At personalisation the issuer computes the value with service code input 999 and writes it into the discretionary data portion of tag 57, and into 9F1F where track 1 equivalent data is personalised. From that moment the chip’s static track data and the stripe’s track data carry the same PAN, the same expiry and different verification values.

At authorisation the issuer sees entry mode 05, 95 or 07, takes the discretionary data out of the chip track data in DE 35 or from the ICC data in DE 55, recomputes with 999, and compares.

What this defeats, precisely: the conversion of chip-sourced static data into a working magnetic stripe. Gemini Advisory’s name for the attack — EMV-Bypass Cloning — captures it exactly, since it “leverages information from one technology (EMV chips) and converts it into another less-secure technology (magstripe)”. The countermeasure is a single comparison, and its failure mode is silent.

Why cloning a stripe does not give you a working chip transaction#

The reverse direction is where the asymmetry is total, and it is worth being exact about why, because it is the reason the entire EMV migration was worth its cost.

A chip transaction requires the card to produce an Application Cryptogram, EMV tag 9F26, in response to a GENERATE AC command. The cryptogram is a MAC computed over data the terminal supplies — amount, other amount, terminal country code, terminal verification results, transaction currency, transaction date, transaction type and the Unpredictable Number in tag 9F37 — together with data the card supplies, principally the Application Interchange Profile and the Application Transaction Counter in tag 9F36. The key is an application cryptogram session key derived from a card-unique key, which is itself derived from an issuer master key using the PAN and the PAN Sequence Number in tag 5F34. Tag 9F10, Issuer Application Data, carries the issuer’s own proprietary block, including in most schemes the counters and derivation information the issuer needs to reproduce the calculation.

None of that is present in stripe data. The stripe carries a PAN, an expiry, a service code and three static digits. It carries no key, no counter and no ability to compute anything. A terminal presented with a card that has no chip either declines, or performs a fallback swipe that the issuer can see and refuse.

And a criminal in possession of every static byte from a chip is no better off, because he does not have the card’s key. He can replay a captured cryptogram, and the Application Transaction Counter will be one the issuer has already seen for that card. He can attempt to build a card that generates cryptograms, and he cannot, because the derivation key never leaves the issuer’s HSM or the chip. For cards supporting dynamic data authentication the position is stronger still: the chip holds an RSA private key it will sign challenges with and will not disclose, so even an offline terminal with no network connection can distinguish a genuine card from a copy.

The security codes are three digits of static data. The cryptogram is the actual defence. iCVV exists to make sure that the three digits of static data cannot be smuggled sideways into a channel that has no cryptogram to check.

dCVV, CVC3 and contactless magnetic-stripe mode#

For a period, contactless cards in some markets were deployed in a mode designed to reuse existing magnetic stripe message formats end to end, so that acquirers and issuers needed no message changes at all. This is MSD, magnetic-stripe data mode, and it is where the dynamic values live.

The trick is that the card hands the reader a track image with holes in it, plus instructions for filling the holes. In EMVCo’s Kernel 2 specification — the Mastercard kernel, Book C-2 of the EMV Contactless Specifications for Payment Systems — the relevant data objects are:

The names decode as follows. PCVC3 is a bit map that “indicates to the Kernel the positions in the discretionary data field of the Track 2 Data where the CVC3 (Track2) digits must be copied”. PUNATC is a bit map that “indicates to the Kernel the positions in the discretionary data field of Track 2 Data where the Unpredictable Number (Numeric) digits and Application Transaction Counter digits have to be copied”. NATC “represents the number of digits of the Application Transaction Counter to be included in the discretionary data field of Track 2 Data”.

The sequence at the reader is: select the application, read the static Track 1 and Track 2 Data and the position bit maps, generate a numeric unpredictable number, issue a COMPUTE CRYPTOGRAPHIC CHECKSUM command carrying it, and receive back a two-byte CVC3 for each track. The reader then converts the CVC3 to decimal, overwrites the positions the bit maps identified with the CVC3 digits, the unpredictable number digits and the low-order ATC digits, and sends the resulting track image onwards in an ordinary magnetic-stripe-format authorisation. To every system between the terminal and the issuer, it looks like a swipe. Only the issuer, which knows the card’s CVC3 key and the expected ATC, can tell that it was not.

A published capture of a Mastercard PayPass card makes this concrete. The card returned application identifier A0 00 00 00 04 10 10 and, in its magnetic-stripe record, these values:

9F6C  02  00 01
9F62  06  00 00 00 00 01 C0
9F63  06  00 00 00 00 00 3C
9F64  01  03
9F65  02  00 E0
9F66  02  00 1E
9F67  01  03

9F64 and 9F67 are both 03: three ATC digits go into each track. 9F65 is 00E0 and 9F66 is 001E, two bit maps marking disjoint runs of digit positions in the track 2 discretionary data — three positions for the CVC3, four for the unpredictable number and counter. The static Track 2 Data in 9F6B began ...D 1103 502 0000000..., showing the hexadecimal D separator, an expiry of March 2011, a service code of 502, and a discretionary data field of zeroes waiting to be overwritten.

Read four times in quick succession, the same card produced:

;5XXXXXXXXXXXXXX2=11035020000072029191?
;5XXXXXXXXXXXXXX2=11035020000018129281?
;5XXXXXXXXXXXXXX2=11035020000054629311?
;5XXXXXXXXXXXXXX2=11035020000099829771?

Identical PAN, identical expiry, identical service code, four different discretionary data fields — the CVC3 digits and the counter digits, changing on every read exactly as the bit maps promise. The same capture also shows the contactless interface reporting service code 502 where the physical stripe on the same card carried 101, and substituting SUPPLIED/NOT for the cardholder name, both of which are ordinary personalisation practice and neither of which is a security control.

Visa’s equivalent for the MSD path is dCVV, a three-digit dynamic value derived using the ATC and carried in the track 2 discretionary data. Issuer guidance circulated in the United States is explicit about the obligation: “always validate for Dynamic Card Verification Value (dCVV) on POS entry mode 91 transactions and decline if dCVV fails”, and where the issuer relies on a scheme service to do the validation, “check the authentication result field and decline if authentication fails.”

MSD is a legacy path and is being removed. In the United States and Canada, new point-of-sale terminals have been required since 18 October 2019 to support only EMV mode for contactless, excluding magnetic-stripe mode; Visa set an April 2019 deadline for terminals to retire MSD in favour of qVSDC. The stripe itself is following: Mastercard has said that newly issued credit and debit cards will not be required to carry a magnetic stripe from 2024 in most markets and from 2027 in the United States, that no new Mastercard credit or debit cards will be issued with a stripe from 2029, and that no such cards will have stripes at all from 2033. All of these dates are as of writing and are the kind of commitment that moves.

The naming table#

The dashes are not assertions that the scheme lacks the mechanism; they mark places where the scheme does not publish a distinct public name for it. Generic industry usage covers the printed value with CSC, card security code, and PCI documentation uses “card verification code or value” precisely to avoid choosing a dialect.

Why CVV2 must never be stored#

PCI DSS divides account data into cardholder data and sensitive authentication data. The PCI Security Standards Council defines SAD as “security-related information used to authenticate cardholders and/or authorize payment card transactions”, and states that this “includes, but is not limited to, card verification codes, full track data (from magnetic stripe or equivalent on a chip), PINs, and PIN blocks.”

The operative requirement in PCI DSS v4.0.1 is 3.3.1: “SAD is not retained after authorization, even if encrypted. All SAD is rendered unrecoverable upon completion of the authorization process.” It is broken out into three sub-requirements covering the full contents of any track (3.3.1.1), the card verification code (3.3.1.2 — “The card verification code is not stored upon completion of the authorization process”), and the PIN and PIN block (3.3.1.3). Requirement 3.3.2 permits SAD to exist before authorisation completes only if “stored electronically prior to completion of authorization is encrypted using strong cryptography”, and 3.3.3 carves out the only exception, for issuers and issuer processors, limiting any stored SAD “to that which is needed for a legitimate issuing business need” and requiring it to be encrypted with strong cryptography.

Read that carefully. Encryption is not a defence for retained CVV2. Tokenisation of the PAN is not a defence. There is no retention period, no “we keep it for seven days for chargebacks”, no exception for a merchant with a good reason. There is no good reason, because the value’s only function is to be presented once at the moment of authorisation and its only property of interest is that it is not held anywhere in bulk.

The requirement bites in places that surprise engineers who have only ever thought about the primary database:

• Application logs. A payment request logged at debug level with its full body is a PCI DSS 3.3.1.2 violation, and it is by an enormous margin the most common one.
• Crash dumps and exception reports. A framework that serialises the request object into an error tracker has just posted the code to a third party.
• HTTP access logs and proxies. A card form submitted by GET, or a badly built API that accepts the code as a query parameter, writes it into every log on the path.
• Message queues, replay buffers and event streams. Anything with a retention setting is storage.
• Call recordings. Telephone orders where the cardholder reads the code aloud require pause-and-resume recording or DTMF suppression; the recording is storage.
• Paper. PCI’s own guidance addresses this directly, noting that where “card verification codes are stored on paper media prior to completion of authorization, a method of erasing or covering the codes should prevent them from being read after authorization is complete” — literally, cutting the code out with scissors or blacking it out with an opaque permanent marker.
• Backups and analytics warehouses. A nightly extract that includes the order payload propagates the violation into systems nobody has scoped.

There is one more consequence that catches product teams. Because the code cannot be retained, recurring and merchant-initiated payments cannot resupply it. A subscription billed monthly presents the code once, on the first transaction, and never again. This is why Mastercard’s chargeback rules for recurring transactions let the merchant point back at the original authorisation and the M result stored against it, and why any product design that assumes “we will just re-verify the CVV each month” is not implementable. Store the result. Never the value.

Failure modes, and what each one is telling you#

When these values are wrong in production, the symptom is usually a decline with an unhelpful response code, and the diagnosis lies in matching the interface to the value. This table is the one worth keeping.

Every one of those is a mismatch between an interface and a value that belongs to a different interface. That is the whole subject. Four values, four doors, and a system whose security depends on nobody confusing them — including, and especially, the people building it.

13.98 Common wrong ideas#

Wrong: There is one security code on a card, the three digits on the back. Right: There are at least four values from the same family of algorithm — CVV1 in the stripe, CVV2 in ink, iCVV in the chip, dCVV or CVC3 manufactured per tap — and presenting one at another’s interface is precisely the event the system is built to detect.

Wrong: The bank keeps your CVV2 in a column somewhere and can look it up. Right: Nothing is stored but the keys; each value is recomputed from scratch inside a hardware security module at authorisation time, which is why no issuer can read the printed code back to you and no screen anywhere displays it.

Wrong: iCVV is what stops a chip card being cloned. Right: iCVV stops chip-sourced static data being reused at the stripe door and nothing more; what makes a chip transaction impossible to counterfeit is the Application Cryptogram, computed with a key the chip will not disclose.

Wrong: CVV, CVC and CID are different mechanisms. Right: They are the same idea in different schemes’ dialects — Visa says CVV, Mastercard says CVC, American Express and Discover say CID, JCB says CAV, China UnionPay says CVN — and a system handling several is being told the same thing twice in two languages.

Wrong: A CVV2 result of N means the transaction was declined. Right: The result is not the authorisation decision; an issuer may return an approval with a result of N, and whether to proceed is the merchant’s own risk decision.

Wrong: The printed code may be kept encrypted for a few days to handle chargebacks. Right: PCI DSS 3.3.1 forbids retention after authorisation even if encrypted, with no retention period and no merchant exception; the defence in a recurring-transaction chargeback is the stored M result, never the value.

Wrong: Three digits is far too short to be worth anything. Right: The shortness is deliberate — guessing a code for a known card number takes about five hundred attempts on average — and the defence is the issuer’s velocity controls and the scheme’s rules on repeated declines, not the length.

Wrong: Because iCVV is computed with a service code input of 999, the chip’s track data must carry 999 in its service code field. Right: The 999 is fed into the calculation and is not a claim about what is encoded; Visa’s warning about 000 and 999 appearing on counterfeit stripes only makes sense because the encoded field and the calculation input are separable things.

Wrong: A terminal may safely normalise or re-pad tag 57 before forwarding it. Right: The full unmodified Track 2 Equivalent Data including the issuer discretionary data must be transmitted, and stacks that parse tag 57 into fields and reassemble it destroy the iCVV, which is why every chip transaction from one terminal model can fail at one issuer.

Wrong: A stolen database of card numbers gives a thief everything needed for a card-not-present purchase. Right: The printed code is not in the card’s machine-readable data anywhere, so it is not in the database and not on a skimmed stripe; the thief would have had to hold the card and turn it over.

13.99 Chapter summary in 20 lines#

1. A modern payment card carries at least four values that all look like three unremarkable decimal digits, and they are not interchangeable.
2. They are conventionally CVV1 encoded in the magnetic stripe, CVV2 printed in ink, iCVV stored inside the chip, and dCVV or CVC3 manufactured fresh for every contactless tap.
3. All of them come out of the same algorithm in the same hardware security module, from the primary account number, the expiry date and a three-digit service code.
4. The service code is the only input that varies — the card’s own code for CVV1, 000 for CVV2, 999 for iCVV — and changing it changes every digit of the answer with no pattern connecting the results.
5. Nothing is stored except the key pair, so each value is recomputed and compared at authorisation time, which is why an issuer can regenerate your printed code but cannot look it up.
6. CVV1 lives in the discretionary data of the encoded tracks, and exists to prove that whoever presented the card had seen a real stripe rather than merely learned a number from a receipt.
7. CVV2 is printed and never encoded anywhere in machine-readable form, which is its entire purpose: a stolen database or a skimmed stripe does not contain it.
8. iCVV lives in the discretionary data inside the chip’s Track 2 Equivalent Data, tag 57, and differs from the stripe’s value so that data lifted from a chip fails when written onto a blank stripe.
9. That makes iCVV a cross-channel defence rather than a chip defence, and the popular explanation that it is what secures chip transactions is backwards.
10. What actually secures a chip transaction is the Application Cryptogram, a message authentication code over the amount, currency, date, terminal country, an unpredictable number and the card’s own transaction counter, computed with a key that never leaves the silicon.
11. dCVV and Mastercard’s CVC3 are dynamic: the chip mixes its ever-increasing counter with a number the reader has just invented and produces digits that have never existed before and will never be valid again.
12. In magnetic-stripe data mode the card hands the reader a track image with holes in it plus bit maps saying where to write the fresh digits, so everything downstream of the terminal sees an ordinary swipe.
13. A published capture of one contactless card read four times in a row shows an identical account number, expiry and service code with four different discretionary data fields, which is that mechanism made visible.
14. POS entry mode is load-bearing, because it tells the issuer which value to compute, and a terminal that reads the chip but reports a swipe will have chip data checked against the stripe’s value and decline.
15. Terminals must transmit tag 57 unmodified, and software that trims, re-pads or normalises the discretionary data destroys the iCVV in the process — a real and recurring integration defect.
16. The mechanism is sound but its deployment is uneven, and in 2020 both Cyber R&D Labs and Gemini Advisory documented issuers who were not validating the stripe’s value on stripe transactions, so chip-harvested iCVV worked on counterfeit stripes.
17. A subtler failure in the same family is taking the service code from the incoming track data rather than the issuer’s own record, which lets a fraudster encode 999 on a counterfeit stripe and have the issuer helpfully compute the chip’s value.
18. The printed code travels in scheme-specific fields — Visa Field 126 usage 10, Mastercard DE 48 subelement 92 — and returns a result of M, N, P, S or U, which is durable evidence and not an authorisation decision.
19. PCI DSS classes the printed code as sensitive authentication data and forbids retaining it after authorisation even encrypted, which reaches debug logs, crash dumps, access logs, queues, call recordings, paper and backups, and means a recurring payment can never resupply it.
20. Every production failure in this area has the same shape — an interface presented with a value belonging to a different interface — which is the whole subject of the chapter.

Sources: ISO/IEC 7813:2006 track structures; EMV 4.x Book 3 tag definitions (57, 5F30, 5F34, 9F1F, 9F10, 9F26, 9F36, 9F37); EMVCo EMV Contactless Specifications for Payment Systems, Book C-2 (Kernel 2) data objects 56, 9F60–9F67, 9F6A–9F6C; PCI SSC glossary and PCI DSS v4.0.1 requirements 3.3.1–3.3.3; Mastercard Switch Rules and Security Rules and Procedures (DE 48 subelements 87 and 92); Visa VisaNet authorisation technical specifications (Fields 44.10 and 126.10) and Visa EMV Chip News, October 2019; IBM cryptographic services documentation on the Visa CVV algorithm; Visa and ICBA issuer guidance on POS entry modes and dCVV validation; Gemini Advisory / Recorded Future, “Cybercriminals Deploy EMV-Bypass Cloning” (2020); Cyber R&D Labs card cloning research as reported by Krebs on Security, July 2020; Mastercard magnetic stripe retirement announcement, 2021; Secure Technology Alliance, “Card Payments Roadmap in the United States”; published contactless card capture data (Ambimat Electronics service code analysis).