Cardholder Verification in EMV


EMVCo

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’s currency used in the cardholder verification rules.

4 bytes

Binary

Y

An amount in the application’s currency 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!

 

 

 

BP-Tools

BP-Tools is a set of freeware applications for EFT testing, benchmarking and transaction service development.

See more...

Download...

Download Flyer...

BP-Sim

The Babylon Payments Simulator (BP-Sim) is a family of highly efficient regression and stress testing tools, designed for deployment in development and pre-production environments. BP-Sim allows users to perform an extensive range of tests across the chain of payment services.

See more...

Download Flyer...

BP-Processing

The Babylon Payments Processing Suite(BP-Processing) is a suite of EFTlab's products for realtime payment transaction processing and authorisation.

See more...