CVM List (Tag 8E): Why One Payment Asks for a PIN and Another Doesn't

Two purchases at the same till: one wants a PIN, the other sails through with no verification at all. Neither the terminal nor the cashier improvised. The card carries a ranked list of verification methods — the CVM List, EMV tag 8E — and the terminal simply walks it from the top until one rule sticks. The code tables tell you what each byte means, but the behaviour you see at the till comes from the traversal — so the walk itself is what this article takes apart, step by step.

Start with a real value

Here is a CVM List the way you meet it in a card profile or a DE55 dump: 000003E8000000001F0642031E031F02. Paste it into the CVM List Decoder and it comes back as two amounts and four rules:

• Amount X = 1000 · amount Y = 0
• Rule 1 — 1F 06: No CVM required, if in application currency and under X
• Rule 2 — 42 03: Enciphered PIN verified online, if terminal supports the CVM — on failure, apply the next rule
• Rule 3 — 1E 03: Signature (paper), if terminal supports the CVM — on failure, fail cardholder verification
• Rule 4 — 1F 02: No CVM required, if not unattended cash, not manual cash, not purchase with cashback

That one value already answers the question in the title. In a two-decimal currency X = 1000 means 10.00: below it, rule 1 fires and nobody is asked for anything; above it, rule 1's condition fails and the PIN pad lights up for rule 2. The rest of the article is how the terminal turns those four lines into that behaviour — keep the decoder open and follow along.

The structure: two amounts, then two-byte rules

Tag 8E has a fixed head and a repeating body. The first four bytes are amount X, the next four are amount Y — plain binary integers (not BCD), expressed in the application currency with its usual implied decimals, so 000003E8 is 1000, i.e. 10.00 with exponent 2. The amounts do nothing by themselves; they exist so that conditions like "under X" or "over Y" have something to compare against. Everything after byte 8 is rules, exactly two bytes each:

• Byte 1 — the method. Bits b6–b1 are the CVM code (02 enciphered PIN online, 1E signature, 1F no CVM…). Bit b7 is the "continue on failure" flag: set, and a failed attempt moves the walk to the next rule; clear, and a failed attempt ends cardholder verification in failure. That is the only difference between 42 and 02. Bit b8 is reserved and should be zero.
• Byte 2 — the condition. When this rule is even eligible: always (00), only if the terminal supports the method (03), only for manual cash (04) or cashback (05), or only in relation to X and Y (06–09).

The layout explains the classic decoding accident: paste a full 8E into something that expects bare rules and the amounts get read as "rules" — you see a run of impossible 00 00 entries before the real ones. The reverse happens with logs that store only the rule bytes. If a decoded list starts with four nonsense rules, you are almost certainly looking at the amounts.

How the terminal walks the list

The selection is a plain loop, top to bottom, first match wins. For each rule:

1. Take the next rule.
2. Is the condition satisfied? The terminal checks the transaction against the condition byte — amount versus X or Y, cash or cashback, and so on. If not satisfied, the rule is skipped: the walk moves on and the failure flag is never consulted. A skipped rule is not a failed rule.
3. Can the terminal perform the method? It compares the CVM code against its own capabilities (tag 9F33). A method it does not support, or does not recognise, counts as a failed attempt.
4. Attempt the CVM. Success ends the walk — the result is recorded in CVM Results (tag 9F34). On failure, bit b7 of the method byte decides: set, take the next rule; clear, cardholder verification fails then and there, and TVR byte 3 records why.
5. Out of rules? If the list is exhausted without a success, verification fails — "cardholder verification was not successful", TVR byte 3 b8.

A failed verification is still not a declined transaction. The failure is written into TVR byte 3, and the Terminal / Issuer Action Codes then decide whether that observation forces a decline, forces the transaction online, or gets waved through. Plenty of signature-preferring cards complete happily every day with "verification unsuccessful" style bits set.

The example, four purchases

Walk the value from the top of the page through four everyday situations:

• 8.00 coffee. 800 < X = 1000, so rule 1's condition is satisfied. "No CVM required" cannot fail; the walk ends at rule 1. No prompt, no signature — and that is the literal, byte-level answer to "why was no PIN prompted?". 9F34 records 1F0602.
• 25.00 groceries. 2500 is not under X, so rule 1 is skipped — skipped, not failed. Rule 2: the terminal supports online enciphered PIN, so it prompts, builds the PIN block into DE52 and sends the transaction online. The terminal itself cannot check an online PIN, so 9F34 typically shows 420300 — result "unknown", the issuer verifies.
• 25.00, cardholder cancels at the PIN prompt. Rule 2 was attempted and failed (TVR byte 3 b4: PIN pad present, PIN not entered). Its method byte is 42 — b7 set — so the walk continues to rule 3 and the receipt grows a signature line. Had the card's issuer encoded 02 03 instead, the same cancelled prompt would have ended verification in failure. One bit, entirely different till experience.
• Unattended kiosk, no PIN pad. Rules 2 and 3 both carry condition 03 "if terminal supports the CVM" — a kiosk with neither PIN pad nor signature slip satisfies neither, so both are skipped without failing. Rule 4 catches the purchase: no CVM, done.

Same card, same sixteen bytes, four different outcomes — all of them deterministic once you read the list as a program rather than a table.

8E is the policy — 9F34 is what actually happened

Tag 8E tells you what could happen; it proves nothing about a specific transaction. The outcome lives in CVM Results, tag 9F34 — three bytes: the CVM code that was applied, the condition it was applied under, and the result (00 unknown, 01 failed, 02 successful; a first byte of 3F means no CVM was performed at all). Look it and its neighbours up in the EMV tag lookup — 8E is the candidate list, 9F34 is the verdict, and they answer different questions.

That distinction settles a familiar dispute. A chargeback lands: the receipt prints "PIN VERIFIED", the cardholder swears no PIN was ever entered. The receipt line is a template printed by the terminal application — it is not evidence. The evidence is in DE55: if 9F34 reads 1F0602, rule 1 of our list was applied and the cardholder is right — the amount was under X and no PIN was ever prompted. If 9F34 reads 420300, a PIN was taken and sent online — and you can corroborate it: the authorisation request carried a PIN block in DE52, and TVR byte 3 shows "online PIN entered".

The same pair works on the acquiring side. A merchant reports that one terminal never asks for PIN: decode the card's 8E and the terminal's 9F33 side by side. If the terminal's capabilities do not claim enciphered PIN support, rule 2's condition is never satisfied, every sale slides to the signature rule, and 9F34 keeps reading 1E03…. The card is executing its policy exactly; the fix is terminal configuration, not a card replacement.

Read next

• CVM List Decoder (Tag 8E) — paste any 8E value and see the rule chain
• TVR Bits Explained: All 5 Bytes of EMV Tag 95 — byte 3 is where CVM failures land
• EMV Chip & DE55 Deep Dive: ARQC / TVR / CVM
• ARQC vs TC vs AAC: Reading EMV Tag 9F27