ISO 8583 Parser
Free · Decoder · Updated 2026-08-09
online lookup

EMV CVM List (Tag 8E) Cardholder Verification Method Decoder

The CVM List is the card's verification policy: try this method under this condition, and if it fails, either move to the next rule or give up. Paste tag 8E and read it as ordered rules instead of hex pairs.

Examples:

The structure: two amounts, then rules

A full tag 8E starts with two 4-byte binary amounts, X and Y, expressed in the application currency. They exist for the conditions: rules can be scoped to “under X” or “over Y”, which is how a card says “no CVM below 50, PIN above it”. After the amounts come the rules, two bytes each: a method byte and a condition byte.

This matters for pasting: decode a full tag as if it were rules and the first four “rules” are fragments of the amounts — usually a string of impossible 00 00 entries. This tool parses inputs of 10 bytes or more as the standard structure and shorter even-length inputs as bare rules, and says which it did.

Code (b6–b1)Method
00Fail CVM processing
01Plaintext PIN verified by ICC
02Enciphered PIN verified online
03Plaintext PIN verified by ICC + signature
04Enciphered PIN verified by ICC
05Enciphered PIN verified by ICC + signature
1ESignature (paper)
1FNo CVM required
ConditionRule applies…
00Always
01If unattended cash
02If not unattended cash, not manual cash, not purchase with cashback
03If terminal supports the CVM
04If manual cash
05If purchase with cashback
06If in application currency and under X
07If in application currency and over X
08If in application currency and under Y
09If in application currency and over Y

How the terminal walks the list

Top to bottom, first match wins. A rule is attempted when its condition is satisfied and the terminal supports the method (terminal capabilities, tag 9F33). Bit b7 of the method byte decides what a failure means: set, the terminal moves to the next rule; clear, cardholder verification fails then and there. 42 and 02 are both “enciphered PIN online” — they differ only in what happens if the PIN can't be taken.

Whatever happened is recorded in CVM Results (tag 9F34: which rule was applied and how it ended) and summarised in TVR byte 3. Those two are the outcome; the list here is only the policy.

Reading a real decline

“Why did it ask for a signature instead of PIN?” — walk the list: the PIN rule's condition wasn't met (amount below X, or the terminal reported no PIN pad), so the next rule fired. “Why was there no PIN prompt on a small contactless payment?” — a 1F (no CVM) rule scoped under X. “Why did the transaction die at verification?” — some rule with b7 clear failed, and the walk stopped there. The list plus 9F34 answers all three without guessing.

Worth remembering: the card sets the policy, the terminal only executes it within its capabilities. A terminal cannot invent a CVM the list doesn't offer, and it cannot skip a rule whose condition matches. When merchants report “this card always wants signature”, the answer is in the card's list, not in the terminal's settings.