9F34 CVM Results
| Tag | 9F34 |
|---|---|
| Name | CVM Results |
| Format and length | b 3 |
| Source | Terminal |
| Where you see it | Set during cardholder verification; sent online in field 55 and often in CDOL1 |
The CVM Results are three bytes the terminal sets at the end of cardholder verification. They record which CVM was performed, which condition applied and whether it worked. The issuer receives them in the authorisation message and often in the cryptogram input, so it knows how the cardholder was verified.
The three bytes
- Byte 1, CVM performed: the method byte of the CVM List rule that was used, including bit 7.
3Fmeans no CVM was performed. - Byte 2, CVM condition: the condition byte of that rule.
- Byte 3, result:
00unknown,01failed,02successful.
Examples
9F34 03 42 03 00: enciphered PIN online, condition "if terminal supports the CVM", result unknown. This is correct for online PIN: only the issuer can verify it, so the terminal cannot know the result.9F34 03 1E 03 00: signature. The result is also unknown, because the terminal cannot check a signature.9F34 03 01 03 02: plaintext PIN verified by the card, successful.9F34 03 3F 00 01: no CVM performed, typically when no rule could be applied, and cardholder verification failed.
Contactless
Contactless kernels fill in CVM Results too, but the values depend on the kernel. A transaction under the CVM required limit usually shows "No CVM required". A phone payment with consumer device CVM uses a code defined by the kernel or scheme, so decode those values with the relevant specification.
Common mistakes
- Expecting
02successful for online PIN. Unknown is the correct result. - Setting byte 1 without bit 7 from the rule, so the value no longer matches the card's CVM List.
- Sending default or stale CVM Results when cardholder verification was skipped.
Decode a value
Related
Bit definitions follow EMV Book 3 for the contact kernel unless stated otherwise. Always check the EMVCo and payment scheme specifications that apply to your project.