Cardholder Verification in EMV

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:

  1. The bank is who we think it is.
  2. The cardholder is the person to whom the card was issued.
  3. 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 SmartwatchesSmart homesMedicalsRobotics, RetailPubs and brewerySecurity 

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.

References:-

https://www.eftlabs.com/post/cardholder-verification-in-emv

Card Action Analysis
Chip card transactions faster than a New York minute