The CVM List (8E): How a Card Chooses PIN vs Signature vs Nothing

💡 TL;DR (Too Long; Didn't Read)

The CVM List in 90 seconds:

• Tag 8E is the card's ranked list of how it will verify the cardholder: two 4-byte amount thresholds (X and Y) followed by a sequence of 2-byte CVM Rules.
• Each rule is a CVM code (offline PIN, online PIN, signature, no CVM…) plus a condition code (always, if over X, if unattended cash, if terminal supports it…).
• The terminal walks the rules in order; the first rule whose condition is met and whose method the terminal supports wins.
• Bit 0x40 in the CVM code means "if this method fails, try the next rule" — the fall-through that produces "it asked for a PIN, then accepted a signature."
• The outcome is recorded in CVM Results (9F34): which method, its condition, and pass/fail.

Every debate about "chip and PIN versus chip and signature" is, underneath, a debate about the contents of one data object: the Cardholder Verification Method List, tag 8E. It is the card's ranked ballot — an ordered set of ways it is willing to let the terminal confirm the person holding it, each gated by a condition. The terminal reads it, walks it top to bottom, and picks the first entry that both applies and is supported. Learn to decode 8E and the whole cardholder-verification phase — why one card prompts for a PIN and another does not, why a transaction fell through to signature, why a tap asked for nothing — becomes readable instead of mysterious. This follows EMVCo Book 3; I cite the structure, not the spec text.

The structure of tag 8E

The CVM List has a fixed head and a variable tail:

[ Amount X (4 bytes) ][ Amount Y (4 bytes) ][ CVM Rule 1 (2 bytes) ][ CVM Rule 2 ] ...

The two 4-byte amounts, X and Y, are thresholds the condition codes refer to (both expressed in the application currency's minor units). After them comes a sequence of CVM Rules, each two bytes: the first byte is the CVM Code (the method), the second is the Condition Code (when this rule applies). The list is walked in order, and order is everything — the card ranks its preferences by putting them first.

The CVM Code: which method

The first byte of each rule is the method, and its low six bits name it (EMVCo Book 3):

• 0x00 — fail CVM processing (a deliberate "no method works, stop").
• 0x01 — plaintext offline PIN.
• 0x02 — online PIN (enciphered, sent to the issuer).
• 0x03 — plaintext offline PIN and signature.
• 0x04 — enciphered offline PIN.
• 0x05 — enciphered offline PIN and signature.
• 0x1E — signature.
• 0x1F — no CVM required.

And the bit that catches everyone: bit 7 (0x40) is the "apply succeeding rule if this CVM is unsuccessful" flag. If it is set and the chosen method fails, the terminal does not decline outright — it moves to the next rule in the list. If it is clear and the method fails, CVM processing fails. This single bit is why you see "the terminal asked for a PIN, the PIN pad was broken, and it accepted a signature instead": the offline-PIN rule had 0x40 set, the method could not be performed, and the terminal fell through to a signature rule below it.

The Condition Code: when the rule applies

The second byte says under what circumstances the rule is even eligible. Common condition codes (EMVCo Book 3):

• 0x00 — always.
• 0x01 — if unattended cash.
• 0x02 — if not unattended cash and not manual cash and not purchase with cashback.
• 0x03 — if terminal supports the CVM.
• 0x06 — if transaction is in the application currency and over X.
• 0x07 — if in the application currency and under X.
• 0x08 — if in the application currency and over Y.
• 0x09 — if in the application currency and under Y.

So X and Y turn the list into a tiered policy. A typical card might say: if under X, no CVM required (small tap, no prompt); if over X, online PIN; with a signature fall-through if the pad is absent. The two thresholds let one card express "friction-free below this, PIN above it, and a high ceiling where something stronger kicks in."

Walking the list: a worked example

Suppose tag 8E decodes to X = 25.00, Y = 500.00, and the rules:

1. 1F 07 — no CVM required, if under X (25.00).
2. 42 06 — online PIN with fall-through (0x02 + 0x40), if over X.
3. 1E 03 — signature, if terminal supports it.

Now run three transactions. A 20.00 purchase: rule 1's condition (under 25.00) is met, method is "no CVM," terminal supports it — done, no prompt. An 80.00 purchase at a terminal with a working PIN pad: rule 1 fails (not under X), rule 2's condition (over X) is met, method online PIN is supported — prompt for PIN. The same 80.00 at a terminal whose PIN pad is broken: rule 2 is selected, online PIN cannot be performed, but its 0x40 bit is set, so the terminal falls through to rule 3 and takes a signature. Same card, same amount, different terminal capability, different outcome — all determined by three two-byte rules and one fall-through bit.

The receipt: CVM Results (9F34)

When processing finishes, the terminal records what happened in CVM Results, tag 9F34, three bytes: the CVM performed (byte 1, the code that actually ran), the condition under which it ran (byte 2), and the result (byte 3: unknown, failed, or successful). This is the forensic record. When a dispute or a decline needs explaining, 9F34 tells you which method the card and terminal settled on and whether it succeeded — and it is one of the tags carried in DE 55 so the issuer sees it too.

Battle scars

The 0x40 fall-through bit is the source of "it accepted a signature." When a transaction verifies with a weaker method than you expected, check whether the preferred rule had bit 7 set and its method was unsupported or failed. The list did exactly what it was told; the surprise is in the bit.

A card can list a method the terminal must decline. If no rule's condition is met by a method the terminal supports — for instance a PIN-only card at a signature-only terminal — CVM processing can end in failure, which sets a TVR bit and may push the transaction online or to decline. "CVM failed" is often a capability mismatch, not a wrong PIN.

Contactless uses its own CVM logic. The classic 8E list governs contact and some contactless flows, but modern contactless kernels layer their own CVM decisioning — no-CVM below limit, CDCVM on device, online PIN above limit — as covered in the contactless article. Do not assume the contact 8E walk explains a tap; check the kernel's rules.

Where this fits

The CVM List is Phase 6 of the transaction flow. When it selects offline PIN, the PIN block machinery takes over; when it selects online PIN, that block travels in the ISO 8583 message and its result in DE 55. Resolve 8E (CVM List) and 9F34 (CVM Results) in the tag dictionary as you decode.

Related Reading on gsstk

• What Actually Happens When You Dip a Chip: The EMV Transaction Flow End-to-End — where CVM runs (Phase 6).
• PIN Blocks Explained: ISO 9564 Formats 0 to 4 — what happens when the list picks a PIN.
• Contactless in 300ms: Kernels, the TTQ, and the Tap — the tap's own CVM logic (CDCVM).

Tools: decode 8E (CVM List) and 9F34 (CVM Results) in the EMV Tag Dictionary.

Filed under: EMV · Payments · POS · Acquiring · Card Issuing

This article was human-architected and synthesized with AI assistance under the Athena (AI) persona.