Card Not Present: A Thirty-Year Fraud Arms Race

Part II · Cards (Chapters 4–8) Builds on: Chapter 6 (interchange; card-not-present rates run higher), Chapter 7 (authorization, chargebacks, ISO 8583) New concepts in this chapter: card-not-present, liability shift, CVV, AVS, 3DS, tokenization, network tokens, DPAN

1. The Question the Previous Chapter Left Open¶

The previous chapter ended here: everything rests on two premises — the card is present, and the person is present. Buy something online and both vanish at once, so the question becomes: who proves the transaction was made by the cardholder? And when it can't be proven and fraud happens, whose loss is it?

First, give the scenario its name: card-not-present — CNP for short — meaning the merchant never touches the physical card and never sees the person; all it gets is a card number.

Its counterpart is card-present: card in the reader, chip running a round of cryptographic verification, person standing at the counter.

2. The heart of the problem: a card number is a string of digits that can be copied¶

A physical card's chip generates a fresh, single-use cryptogram for every transaction; there is nothing to copy. A card-not-present transaction needs just three things: the card number, the expiry date, and the three digits on the back.

All three are printed on the card. All three can be written down, photographed, or carried off by the millions in one database breach.

A string of digits that can be copied can never serve as proof of identity. Thirty years of technical evolution have all been answering the same question: if the card number can't be trusted, what can?

3. The networks' tool is not technology — it's rules¶

This is the most important point in the chapter, and the one people from an engineering background are most likely to miss.

When Visa and Mastercard want a new technology adopted, they cannot order thousands of banks and tens of millions of merchants to upgrade their systems. They hold exactly one weapon — change the rules, so the loss lands on whichever side didn't upgrade.

The mechanism is called the liability shift:

Whoever failed to adopt the prescribed technology bears the fraud loss.

By default, card-not-present fraud losses fall on the merchant (it failed to verify the cardholder). But if the merchant uses the verification technology the network calls for, the loss shifts to the issuer.

Upgrading then stops being a matter of persuasion and becomes a matter of arithmetic:

Merchants run the numbers themselves. The network never has to force anyone. The four-party model said the networks sell the enforceability of rules; this is the canonical use of it.

4. The chain of fixes: each generation born from the last one's failure¶

Generation one: CVV — prove you're holding the physical card

The three digits on the back (Visa calls it CVV2, Mastercard CVC2) are not encoded in the magnetic stripe, and merchants are forbidden to store them. So leaked databases usually don't contain them.

• What it solved: card numbers stolen from old transaction records or magstripe data are useless without the three digits.
• Where it failed: a phishing site just asks the user to type everything in, three digits included. It guards against database leaks. It cannot guard against users being conned.

Generation two: AVS — check the billing address

The merchant sends the billing address the user entered to the issuer to be checked.

• What it solved: whoever stole the card number doesn't necessarily know where the cardholder lives.
• Where it failed: it works only in the US and a handful of other countries (address formats elsewhere follow no common standard); and it compares only the numeric parts of the street number and ZIP code, so false declines run high — the real cardholder moves house and gets rejected.

Generation three: 3DS 1.0 — let the issuer verify the person directly

3DS is short for 3-D Secure; the "3-D" means three domains — the issuer domain, the acquirer domain, and the interoperability domain the card network provides.

The mechanics: at checkout, a page from the issuer pops up demanding a password or an SMS code. Pass the check and liability shifts to the issuer.

• What it solved: it verifies the person, not the card number. In principle, this was the first real solution to the problem.
• Where it failed: the experience was a disaster. A redirect to a strange-looking page that frequently failed to load, demanding a password the user forgot long ago. The conversion lost far outweighed the fraud saved.

Here is the trade-off most worth remembering in this chapter:

Every added verification step lowers fraud — and lowers conversion. The product's job is not to find the safest option, but the point where the sum of the two losses is smallest.

3DS 1.0 didn't fail as technology; it stood at the wrong spot on that balance. Plenty of merchants preferred eating the fraud losses to turning 3DS 1.0 on.

Generation four: 3DS 2.0 — make verification invisible by default

The thinking changed: instead of putting a checkpoint in front of every transaction, hand the issuer enough information up front to decide for itself which ones to stop.

Concretely, before initiating authorization, the merchant sends the issuer a load of risk signals — device fingerprint, past behavior, shipping address, IP, cart contents; the spec defines over 100 of them.

The overwhelming majority of transactions then take the "frictionless flow" — the user feels nothing, and liability shifts all the same; only the few flagged high-risk get a verification prompt.

The key to this generation is not stronger technology. It reallocated friction from "everyone" to "the suspicious few."

Draw the trade-off from above, and the difference between the two generations is a difference of position:

3DS 1.0 was not a technical failure; it stood too far out on the right side of the curve. 3DS 2.0 did nothing extra — it just moved back left, near the bottom.

Europe's PSD2 (the second Payment Services Directive) requires strong customer authentication for online payments. The rule took effect in September 2019, with country-by-country delays pushing real enforcement to 2020–2022. That is the direct engine behind 3DS 2.0's spread in Europe. Apply the method from interchange — when you see a market difference, look for a rule difference first: 3DS coverage in Europe far exceeds the US because regulation mandates it, not because European merchants love security more.

5. The other road: tokenization solves a different problem entirely¶

3DS and tokenization get lumped together constantly, but they answer two different questions.

How tokenization works: the card network maintains a mapping table and swaps the real card number (the PAN) for a substitute with the same format and no value of its own, called a network token. The merchant stores the token, never the card number.

The crux is that a token comes with conditions of use:

So tokenization, in effect, swaps one master key for a ring of keys that each open a single door.

Apple Pay is this machinery in consumer packaging. What sits in your phone is not your card number but a token bound to that one device, called a DPAN (device PAN). Which explains an everyday fact: lose your phone and you don't replace the card — remotely revoke that DPAN and the physical card keeps working.

Back to the previous chapter: tokenization changed nothing in the ISO 8583 message structure. It only swapped the real card number inside DE2 (the field that carries the card number) for a network token. And the token is itself a perfectly format-valid card number — same length, same check rules as a real one, just resolvable to no real account. That is why the world could adopt it so fast — to every downstream system it looks like an ordinary card number, and not one byte has to change.

6. The Four Technologies Compared¶

They don't replace one another; they stack. A typical e-commerce transaction today may be running all four at once.

7. The Question This Chapter Leaves Open¶

That closes Part II. The card rail is a polished thing: accepted worldwide, authorized in seconds, guaranteed, with a dispute process and a full fraud-control stack.

But it has three properties that cannot be changed out of it:

So a vast set of scenarios sits outside the card's reach: payroll, rent, taxes, invoices between businesses, mortgage payments.

How does that money move? The answer goes back to the bank account system from the three foundation chapters.

But before any specific rail, the word "pull" in that table needs pinning down first — it is the topmost dividing line of this entire course. The next chapter draws it.

8. Self-check questions¶

1. Why do card networks drive new technology by changing rules rather than issuing orders? Explain using the term liability shift.
2. A merchant loses 0.3% of sales to fraud. Turning on 3DS cuts fraud losses to 0.05% but drops checkout conversion by 2%. Its gross margin is 20%. Should it turn 3DS on?
3. A merchant's database is stolen wholesale and every token leaks. What can the attacker do with them?

9. Answers¶

Answer for yourself before reading on.

1. Because the network holds no power to compel — it neither employs the issuers nor manages the merchants. The only thing it can change is the rules, and the rules decide where losses land. Once "fail to upgrade and the fraud loss is yours" is written into the rules, every party runs its own numbers and picks whatever serves it best, and the upgrade happens on its own. This works better than a command, because it needs no enforcement — only participants who are rational.

2. Take sales of 100:

   • Fraud losses move from 0.3% to 0.05%: a saving of 0.25.
   • Conversion falls 2%, sales drop from 100 to 98, and what's forgone is the margin on those sales: 2 × 20% = 0.40.
   • Net effect = 0.25 saved − 0.40 lost = −0.15. Don't turn it on.

   Cross-check: the break-even sits at a conversion loss of 0.25 ÷ 20% = 1.25%. If conversion drops less than 1.25%, adopt; more, and don't. Which is exactly why merchants resisted 3DS 1.0 and broadly adopted 3DS 2.0 — 2.0 pushed the conversion loss below the break-even.

3. Almost nothing. The tokens are bound to that specific merchant (sometimes to a device as well) and won't be accepted anywhere else; the breached merchant simply asks the network to void that batch of tokens, cardholders keep their cards, and other merchants feel nothing. This is precisely what tokenization was designed to do: contain the blast radius of one leak inside a single merchant.

Previous: Chapter 7 · The Three-Phase Life of a Card Transaction Next: Chapter 9 · Push and Pull: The Two Directions Money Moves