Skip to main content

Enforcing and Increasing noCVM Limits

When performing a payment in a Card Present (CP) situation the customer may be required to provide validation of their identity and authorization to perform the payment through use of a Cardholder Verification Method(CVM).  Common CVMs used are the customer signature, entry of a Personal Identification Number (PIN) and biometrics on a mobile device or card.  However, in many situations there is also the opportunity to use ‘noCVM’, where the customer does not need to provide any additional authentication beyond the simple possession and use of the payment mechanism itself.

The use of noCVM is most common in contactless payments where the card is tapped on the payment terminal rather than inserted or swiped as this aligns most closely with the general concept of ‘quick and easy’ that contactless is most often associated with.  However, there is no formal limitation that prevents the use of noCVM on contact transactions as well as contactless.

The determination of what CVM, if any, is to be used for a particular payment can actually be quite complex, involving many different parties.  With an eye to reduce the physical contact that may be involved in payments, many places are now looking at increasing the contactless noCVM limit, and this blog outlines exactly what that means, how it can be achieved and what complexities may be involved in ensuring a consistent and ‘touch free’ customer interaction during contactless payments.

CVM identifiers and verifications

So, what possible CVMs exist?  Well, from EMV Book 3 (Application Specification) we have the following tables of possible CVMs as output from the list provided by the card in tag 8E.  The first table shows that the first two bits of the CVM identifiers returned are either reserved for future use or indicate the action to be taken if the CVM selected is not successful. For example, if there is a selection of online PIN but that fails, is it permitted to fall back to signature to authorize the transaction?  The second table shows the types of CVMs that may be supported. 

Bit8

Bit7

Bit6

Bit5

Bit4

Bit3

Bit2

Bit1

Action to be taken after CVM processing

0

x

x

x

x

x

x

x

Reserved for future use

x

0

x

x

x

x

x

x

Fail cardholder verification if this CVM is unsuccessful

 

Bit8

Bit7

Bit6

Bit5

Bit4

Bit3

Bit2

Bit1

CVM supported

x

x

0

0

0

0

0

1

Plaintext offline PIN verification

x

x

0

0

0

0

1

0

Encrypted online PIN verification

x

x

0

0

0

0

1

1

Plaintext offline PIN and signature

x

x

0

0

0

1

0

0

Encrypted offline PIN verification

x

x

0

0

0

1

0

1

Encrypted offline PIN verification and signature

x

x

0

1

1

1

1

0

Signature

x

x

0

1

1

1

1

1

No CVM

x

x

1

0

x

x

x

x

Reserved for use by payment system / brand

x

x

1

1

x

x

x

x

Reserved for use by card Issuer

x

x

1

1

1

1

1

1

Not available for use

x

x

All other values not listed above

Reserved for future use

 

CVM interoperability challenges

When performing an EMV based transaction, the payment terminal and card must ‘agree’ on an acceptable CVM to use.  The card has a list of possible CVMs that it supports (stored in tag 8E as shown in the tables above) which may be a single list for all possible transaction values or may include different types of CVMs depending on the purchase amount.  The payment terminal will also have types of CVMs that it supports – if there is no PINpad, it cannot support PIN entry for example – and so there may be situations where a terminal and card are unable to come to an agreement on what CVM to use, and the transaction will fail. 

This used to happen quite often to international travelers, when their domestically issued payment card only supports online PIN and a payment terminal in the country they are visiting is only able to support offline PIN. But this scenario is less common these days with the uptake of noCVM.  However, there are now similar situations where a terminal may be able to only support noCVM, for example in a vending or ticketing machine which is unable to accept PIN entry, signature, or biometrics. 

On top of all of this there is also CDCVM – Consumer Device Cardholder Verification Method.  CDCVM relies on the authentication that the cardholder provides to their payment mechanism directly, such as a biometric or PIN on a mobile phone.  When CDCVM is used, this can be indicated in another tag (not necessarily the 8E tag that shows CVM support) and this can then be used by the terminal to decide if further CVM use is required.

CVM purchase amounts

It was noted above that the CVM list provided by the card may indicate different CVMs depending on the purchase amount.  This is done by providing ‘X/Y’ amounts in the CVM list – two different amount values which can be used to determine up to three different sets of CVMs to be used:

When the purchase amount is less than value X

When the purchase amount is more than value X, but less than value Y

When the purchase amount is more than value Y

So, a card may have an X value of €100 and a Y value of €200, for example, and allow for noCVM use for purchase transactions below X but not above this value of €100.  The same card may allow for signature use below the Y value of €200 but require that online PIN be used for all transactions above that amount.

Of course, the terminal must still ‘agree’ on the CVM the card is allowing – a card that permits noCVM below a Y value of €200 may still ask for a PIN if the terminal is configured to require PIN above €100.

Cumulative limits

One of the final complications to changing CVM use is the enforcement of purchase or cumulative amount limits, most usually associated with compliance to the PSD2 directive for Strong Customer Authentication (SCA).  Here, the card or Issuer will track the number of transactions performed between the performance of some higher form of CVM (such as PIN verification) and require that the use of this stronger CVM is used periodically. For PSD2, this limit is 5 transactions or a cumulative purchase amount of €150. 

In such cases even if the terminal and card agree to use noCVM for a transaction, if the cumulative purchase amount since the last use of PIN is more than €150 or there has been use of noCVM for the last five transactions, the Issuer may reject the transaction and require that a stronger form of CVM (such as PIN) is used.

Managing the noCVM transition

Therefore, if you want to change the limit for noCVM, it’s not as easy as simply changing the terminal configuration to allow for higher amounts.  The card must be suitably configured to allow for this, and in fact the Issuer backend and acquirer fraud management systems may have an impact on this as well.  As part of mitigations against recent attacks where the data used to determine a CVM chosen for a transaction was found to be able to be manipulated (as this data is often not authenticated), there have been increased instances where the Issuer is validating the CVM used in a transaction, as reported by the terminal or in the supplied card cryptogram, and any adjustments to the noCVM limits must incorporate adjustments to these checks as well.

So, as we look to moving to increased limits for noCVM use – at least in the (hopefully) short term whilst we try to minimize physical contact during these particularly challenging times – it is likely that solutions will not be perfectly implemented across the board.  Some cards may work with the increased limits, and some may not.  Some terminals may work with increased limits, and some may not.  This new interoperability challenge must be considered and tested for to help make this transition as smooth as possible, and of course to help ensure we achieve the overall goal of keeping everyone as safe as we can during these times.

To get in touch with a UL expert, contact us here.