CVM List Parser

Structure of tag 8E

The CVM List begins with two four-byte amounts, X and Y, both in the minor units of the application currency. After those comes a sequence of two-byte rules, each pairing a cardholder verification method with the condition under which it applies.

In each rule, the first byte holds the CVM code in bits 6-1. Bit 7 is the important one: when set, it means "if this CVM fails, try the next rule". When clear, a failure of this CVM ends cardholder verification unsuccessfully — no fallback. Bit 8 is reserved.

The second byte is the condition code, and X and Y are what conditions 06 through 09 test against.

How the terminal walks the list

Top to bottom, in order. For each rule the terminal asks two questions: does the condition hold for this transaction, and do I support this CVM according to my own Terminal Capabilities (tag 9F33)? The first rule that passes both is the one performed. If none do, cardholder verification fails and TVR byte 3 bit 8 gets set.

This is why the order of the list, not just its contents, determines whether you get a PIN prompt. A card that lists offline PIN before signature behaves very differently from one that lists them the other way round, on identical hardware.

Reading the result

What actually happened is recorded in tag 9F34, CVM Results — three bytes giving the method performed, the condition it matched, and whether it succeeded. Byte 3 is the one people want: 02 means successful.

Two frequent surprises. "No CVM required" (1F) is a legitimate CVM and shows as a success, not an absence. And online PIN always reports as inconclusive at the terminal, because only the issuer can verify it — the terminal just forwards the PIN block.