Dear Readers,
This article has been written to provide a brief introduction to cardholder verification with EMV and the challenges posed by different verification methods. One objective of EMV was to drive down fraud; to do this we need to prove three things:
- The bank is who we think it is.
- The cardholder is the person to whom the card was issued.
- The terminal (or card reading device) is who it should be.
To achieve proving the cardholder identity one of the items of data retrieved from the card is the cardholder verification method (CVM) list. This ordered list contains one or more ways in which we should try to prove the cardholder is who they say they are. Please note that not all cards support cardholder verification as indicated by the Application Interchange Profile (AIP).
The Cardholder Verification Method (CVM) List
The CVM list comes back from the card in response to a read data request for tag 0x8E as follows:
Field Name | Field Description | Field Length | Encoding |
X | An amount in the application’scurrency used in the cardholder verification rules. | 4 bytes | Binary |
Y | An amount in the application’scurrency used in the cardholder verification rules. | 4 bytes | Binary |
CVRule1
. . CVRuleZ |
A variable number of cardholder verification rules each 2 bytes long. | 2*Z bytes | Binary |
The following logic is then applied to process the list:
Processing a Cardholder Verification Rule
The most important part of the process is actually processing the cardholder verification rules; a cardholder verification rule is formed of two bytes where byte 1 is the CVM code and byte 2 is the conditions under which one may then apply the CVM code in byte 1 (where it is supported):
Byte | Bits(s) | Value | Meaning |
1
(CVM Code) |
1-6 | 0 | Fail CVM processing. |
1 | Offline plaintext PIN. | ||
2 | Online PIN (always enciphered). | ||
3 | Offline plaintext PIN and paper based Signature. | ||
4 | Offline enciphered PIN. | ||
5 | Offline enciphered PIN and paper based Signature. | ||
30 | Paper based Signature only. | ||
31 | Approve CVM processing. | ||
* | Reserved. | ||
7 | 0 | Fail cardholder verification if verification is unsuccessful. | |
7 | 1 | Move to next rule if verification is unsuccessful. | |
8 | 3 | Reserved for future use. | |
2
(CVM Condition Code) |
* | 0x00 | Always try to apply this rule. |
0x01 | Only try to apply this rule where this is an unattended cash transaction. | ||
0x02 | If not unattended cash and not manual cash and not purchase with cashback | ||
0x03 | Always try to apply this rule where the CVM code is supported. | ||
0x04 | If this is a manual cash transaction apply this rule. | ||
0x05 | If this is a purchase with cashback apply this rule. | ||
0x06 | If transaction is in the application currency and is under X value (see the description of the CVM List for definition of X) then apply this rule. | ||
0x07 | If transaction is in the application currency and is over X value (see the description of the CVM List for definition of X) then apply this rule. | ||
0x08 | If transaction is in the application currency and is under Y value (see the description of the CVM List for definition of Y) then apply this rule. | ||
0x09 | If transaction is in the application currency and is over Y value (see the description of the CVM List for definition of Y) then apply this rule. | ||
* | Reserved. |
Processing A CVM Code
Once a mutually supported CVM code has been established and is valid under the CVM code’s associated rules the code is applied. Currently one can do a combination of the following things:
- Fail.
- Succeed.
- Online PIN Verification.
- Offline PIN Verification.
- Signature Verification.
Offline PIN is perhaps the most complex scenario where to be successful once entered the PIN must also be verified with the chip, only then is cardholder verification deemed successful.
For online PIN as soon as a PIN has been successfully captured to be sent online (with an ARQC in first generation of the application’s cryptogram) then cardholder verification is deemed successful.
For signature this is perhaps easiest; if the terminal is capable of handling signature then it is deemed successful.
Summary
Generally the most complex scenario for a device handling EMV is the requirement for Offline PIN and Signature as for verification to be successful both the requirements for verification of the offline PIN and the signature support must be met.
We hope this article has shed a little light on verifying a cardholder is who they say they are and the processes that are involved; for more information on this process please see EMV 4.3 Book 3 on the EMVCo website http://www.emvco.com/specifications.aspx?id=223 and of course any comments are welcomed!
About Ambimat Electronics:
With design experience of close to 4 decades of excellence, world-class talent, and innovative breakthroughs, Ambimat Electronics is a single-stop solution enabler to Leading PSUs, private sector companies, and start-ups to deliver design capabilities and develop manufacturing capabilities in various industries and markets. AmbiIoT design services have helped develop Smartwatches, Smart homes, Medicals, Robotics, Retail, Pubs and brewery, Security.
Ambimat Electronics has come a long way to become one of India’s leading IoT(Internet of things) product designers and manufacturers today. We present below some of our solutions that can be implemented and parameterized according to specific business needs. AmbiPay, AmbiPower, AmbiCon, AmbiSecure, AmbiSense, AmbiAutomation.
To know more about us or what Ambimat does, we invite you to follow us on LinkedIn or visit our website.