Cardholder Verification (CVM)

Matching the version numbers of the card and terminal applications
Payment systems assign two-byte version numbers to the card application and terminal application using the Application Version Number data object (Tag ‘9F08’) stored on the card and the Application Version Number data object (Tag ‘9F09’) stored on the terminal.
The terminal checks whether the application version numbers match as follows:
among the data read by the terminal on the card, an object with the Tag field equal to ‘9F08’is searched for;
if no such object is found, the default assumption is that the application versions of the card and the terminal is compatible;
if an object is found, it is compared with a data object that has a Tag field equal to “9F09′;
if the values of the object’s Value fields match, the terminal proceeds to check for the second criterion (.Monitoring app usage);
otherwise, the terminal sets bit 8 “ICC and terminal have different versions” of the second TVR byte to 1 before proceeding to the next test.
Monitoring app usage
Restrictions imposed by the card Issuer on its use are determined by it using the Application Usage Control data object (AUC, Tag ‘9F07’, 2 bytes). This data object is optional and may not be present on the card. In this case, the terminal checks described below are not performed.
The bits of the Value field of the Application Usage Control data object are assigned as follows:
bit 8 of byte 1 is equal to 1: the cash withdrawal operation for domestic transactions is allowed;
bit 7 of byte 1 is equal to 1: the cash withdrawal operation for international transactions is allowed;
bit 6 of byte 1 is equal to 1: the purchase of goods operation for intra – country transactions is allowed;

bit 5 of byte 1 is equal to 1: the purchase of goods operation for international transactions is allowed;
bit 4 of byte 1 is equal to 1: the service purchase operation for intra – country transactions is allowed;
bit 3 of byte 1 is equal to 1: the service purchase operation for international transactions is allowed;
bit 2 of byte 1 is equal to 1: ATM operations are allowed;
bit 1 of byte 1 is equal to 1: operations are allowed in devices other than ATMs;
bit 8 of byte 2 is equal to 1: a cashback purchase operation is allowed for in-country transactions;
bit 7 of byte 2 is equal to 1; the purchase operation with cash withdrawal for international transactions is allowed;
bits 1-6 of byte 2 are reserved for future use.
Note that, in order to determine whether a given
the terminal is an ATM, using the data objects Terminal Tour (Tag ‘9A35’) and Additional Terminal Capabilities (Tag ‘9F40′). A terminal is an ATM if and only if the terminal Tour of the terminal is equal to one of the values ’14’h, ’15Ti,’ 16’h, and bit 8 of byte 1 of the terminal’s Additional Terminal Capabilities is equal to 1.
The following data objects are also used to check restrictions on card usage:
“Transaction Type” (Tag ‘9C’) — defines the type of transaction (cash withdrawal, purchase of goods, services, etc.); the values of the Value field of this data object for various types of transactions are determined by payment systems; the value of the Value field is denoted 1^;
“Issuer Country code” (tag ‘5F28’)— stored on the card and determines the country code of the Issuer in accordance with ISO 3166; the value of the Value field of this data object is denoted by I/;
“Terminal country code” (Tag ‘5F28’) — stored on the terminal and defines the terminal country code in accordance with ISO 3166; the value of the Value field of this data object is designated V3;
“Other transaction amount” (Amount, Other, Tag ‘9F04’) — determines the amount of cash issued to the cardholder when performing a Cashback operation.

The terminal performs the following checks for card usage restrictions (assuming that the AUC object is read by the terminal).
If the terminal used is an ATM, it checks that bit 2 of byte 1 of the AUC is equal to 1.
If the terminal type does not match the ATM, it checks that bit 1 of byte 1 AUC is equal to 1.
If the Issuer Country Code object is read by the terminal, the following checks are performed (if the object is missing, the checks are not performed):
if 1/= “cash Withdrawal” (01=Debit/Cash, 17-19=Debit/
Cash Advance with credit cards), to
if V2 = I/, we check that bit 8 of byte 1 of the AUC is equal to 1;
if I/GF I/, then check that bit 7 of byte 1 AUC is equal to 1;
if 17 = “purchase of goods”, then
if 17, = 1/3, then check that the bit b of byte 1 AUC is equal to 1;
if the PFM is 17z, then we check that bit 5 of byte 1 AUC is equal to 1;
if 17= “purchase of services”, then
if 17?= 1/3, then check that bit 4 of byte 1 of AUC is equal to 1;
if \ / GF is 1/3, then we check that bit 3 of byte 1 of AUC is equal to 1;
if 171= “Purchase of goods/services” and the Amount object, Other
read by the terminal, then
if V2 = 17z, we check that bit 8 of byte 2 of AUC is equal to 1;
if 172 f 17z, then we check that bit 7 of byte 2 AUC is equal to 1.
If at least one check from the above list fails, bit 5 of byte 2 of TVR (“Requested service not allowed for card product”) is set to 1.
Checking the application start/end dates
If the terminal reads the Application Effective Date data object (Tag ‘5F25’) from the card, it compares it with the current date. If the current date is less than the value of the value field of the Application Effective Date object, the terminal sets the bit b of byte 2 of TVR (“Application not yet effective”) to 1.
If the terminal reads the Application Expiration Date data object (Tag ‘5F24’) from the card, it compares it with the current date. If

the current date is greater than the value of the value field of the Application Effective Date object, then the terminal sets bit 7 of byte 2 of TVR (“Expired application”) to 1.
Verification of the card holder
Verification of the cardholder is performed in order to establish the identity of the person who received the card from its Issuer with the person presenting the card for the transaction. This stage of transaction processing can be performed at any time between the moment when the terminal finishes reading the card data and the moment when the terminal finishes analyzing the results of its risk management procedures.
Methods of verification
The EMV standard allows for various methods of verification of the cardholder (Cardholder Verification Method, or CVM). Each method is encoded in a sequence of 6 bits in accordance with Appendix C of Book 3 of the EMV 4.1 standard.
No CVM required (‘ollll’b). This method means that verification of the cardholder is not required. This method is relevant if you need to ensure high speed of transaction execution, possibly at the expense of its security. Examples include paying with a toll road card, paying at fast food restaurants (often using contactless IPCS), and so on.for small transaction sizes, a reduction in transaction security due to the lack of verification of the cardholder may be considered acceptable.
Fail CVM processing (‘OOOOOH). This method is used to artificially initialize the failure of the cardholder verification terminal in order for the terminal to make a decision on authorization of the operation in real time.
Signature (‘011110’b). This method consists of verifying the cardholder’s signature on the back of the card-
you, with the customer’s signature on the receipt. This verification method is saved in EMV, because in some countries legislation requires the client’s signature as proof of the transaction.
Enciphered PIN verified online (y000010’b)— a method for verifying the PIN code of a cardholder by its Issuer during a real-time transaction. At the same time, according to the requirements of payment systems, the PIN code is encrypted almost from the moment it is entered on the terminal until the end of verification in a special cryptographic module of the Issuer’s host and, thus, is not available to fraudsters. This method of cardholder verification was abandoned when using the IPC (and not replaced by the offline PIN verification procedure) for several reasons. The first reason is that many issuers consider it possible to apply the PIN verification procedure offline only if the PIN code is transferred from the terminal to the card in closed form (in Germany, this requirement follows from the country’s legislation). To implement this PIN code transfer to the card, the terminal must have a cryptographic device capable of supporting the RSA algorithm. The presence of such a cryptographic device is still a problem for a number of terminals, such as ATMs. Therefore, the need for online processing of the PIN code by the Issuer remains.
Another reason has a common root with the first one and consists in the Issuer’s distrust of the security of PIN-code transmission to the IPC. For example, the PIN code is encrypted using the RSA algorithm, but not in a cryptographic module, as required by payment systems, but using the terminal software. There are other subtleties in implementing PIN encryption using an asymmetric cryptographic algorithm that affect the safety of the PIN code and the security of the operation. Therefore, some issuers have more confidence in the proven long-used method of online PIN verification.
Plaintext PIN verification performed by ICC (‘000001’b) — verification by the card application of the PIN code transmitted to the MPC in open format. In this case, the PIN code is transmitted to the card in plain text after it is entered on the terminal. Since the transfer of a PIN code to a card does not exceed the limits of the “card-terminal” system, the probability of fraudulent interception of the PIN code is considered to be approximately the same as in the case of using a secure PIN block transfer. Analysts believe that the PIN code is compromised at the stage of its transfer to the card is low (there are many other ways of compromising, which are also relevant when transmitting the PIN code in a protected form).
Plaintext PIN verification performed by ICC and signature (‘Ooooll’b) — verification by the card application of the PIN code transmitted to the IPC in open form, plus the client’s signature on the terminal receipt.
Enciphered PIN verification performed by ICC (‘000100’b) — verification by the card application of the PIN code transmitted to the IPC in encrypted form. As already noted, the implementation of this verification method requires support from the card and terminal.
Enciphered PIN verification performed by ICC and signature (‘000101’b)-verification by the card application of the PIN code transmitted to the IPC in encrypted form, plus the client’s signature on the terminal receipt.
Other values of verification method codes are reserved by EMV for the following use:
‘OOOllO’- ‘ Olllol’b – for biometric cardholder verification methods;
‘UOOO’- ‘ UIN ‘ — for use by payment systems;
‘NOOO’- ‘ ISHO — – for use by individual issuers (for example, the method of applying one-time passwords).
Each terminal must support verification methods specified by the second byte of the “Terminal Capabilities” data object (Tag ‘9F33’), and recognize the “No CVM required” and “Fail CVM Processing” codes that can be contained in the CVM List object.
The key data object for cardholder verification is the Cardholder Verification Method List (CVM List, Tag ‘8E’) object. This data object is stored on the card. The value field of the CVM List object consists of:
multiple Card Verification Rule (CVER) entries (rules), each of which is a 2-byte binary sequence;
two values X and Y that have a binary format and a size of 4 bytes each (the values X and Y are set in the first 8 bytes of the CVM List).
The first byte of the CVER element is called Cardholder Verification Method Code (CVM Code) and is used to encode the verification method. The second cver byte is called Cardholder Verification Method Condition Code (CVM Condition Code) and defines the conditions under which the verification method can be used.
The values X and Y are expressed in the currency of the card application (Application Currency Code, Tag ‘9F42’) with an implicit decimal point defined by the application currency. The purpose of the values X and Y will be explained later.
The structure of the CVM code byte is described below:
bit 8 is reserved for future use and takes the value 0;
bit 7=1 means that the terminal should go to the next verification method in the CVM List, if there is one, and the current verification method failed (note that it failed, not failed!);
bit 7=0 means that the terminal completes the cardholder verification procedure if the current verification method was unsuccessful;
bits 1-6 encode the verification method as described above.
The second byte of CVER (CVM Condition Code) encodes the following conditions for implementing the CVM verification method:
Wh: the CVM method can be used under any transaction execution conditions without any restrictions;
‘Ol’h: the CVM method can always be used when the transaction type is associated with cash withdrawal (ATM cash withdrawal, Cash Advance and Cashback operations);
’02’h: the CVM method can always be used when the transaction type is not associated with cash withdrawal, i.e. the opposite condition to the previous one;
’03’h: the CVM method can be used if the terminal supports it. For example, the Plaintext PIN verification method can be used if the terminal has a PIN pad for entering the PIN code and the terminal application supports entering the PIN code to the card;
‘(K’- ‘ OS’h: these values are reserved for future use;
’06’h: the CVM method is used if the transaction currency (Transaction Currency Code, Tag ‘F2A’) matches the currency of the card application Application Currency Code and the transaction size is no larger than X;
’07’h: the CVM method is used if the transaction currency is the same as the card application currency and the transaction size is greater than X;
’08’h: the CVM method is used if the transaction currency matches the currency of the card application and the transaction size is no larger than Y;
’09’h: the CVM method is used if the transaction currency is the same as the card application currency and the transaction size is greater than Y;
‘0A’- ‘ 7F’h: reserved for future use;
’80’- ‘ FF’h: reserved for use by payment systems.
The cardholder verification result is stored by the terminal in the CVM Results data object (Tag ‘9F34’), whose Value field is three bytes in size. The first two bytes encode the CVER rule used in the procedure, and the last byte indicates the result of executing the last CVM:
unknown result (for example, for signing or online PIN verification);
The CVM failed, i.e. the verification did not confirm the cardholder’s identity (for example, when checking the PIN code offline);
The CVM was completed successfully, i.e. the verification confirmed the validity of the cardholder (for example, when checking the PIN code offline).
The CVM Results data object is formed by the terminal to send to the Issuer as additional information that the Issuer can use when making a decision on the result of completing the operation.
If bit 5 of byte 1 of the AIP “Cardholder verification is supported” is equal to 1, the terminal begins the cardholder verification procedure. First of all, the terminal checks the presence of the CVM List object (Tag ‘8E’) among the card data it has read.
If the CVM List object is missing from the read data, the terminal completes the verification procedure without setting the value of bit 7 of byte 1 of the TSI “Cardholder verification was performed” to 1. In this case, the terminal sets the value of the first byte of CVM Results to ‘ 3F’h (No CVM performed).
If the CVM List object has been read, the terminal starts sequentially processing the Card Verification Rules entries listed in the object, moving from the first entry in the order they appear in the CVM List, if necessary, to the end of the list.
The procedure for processing each 2-byte cver entry in the CVM List is described below.
Step 1. Checking the second cver byte (CVM Condition Code):
checks whether the terminal understands the CVM Condition Code value. For example, it may happen that the card supports the EMV version that contains the new verification condition values, but the terminal that supports the old version does not understand these values;
checks for the presence of data elements on the terminal that are necessary for checking the condition set using the CVM Condition Code. For example, to check conditions that use x or Y values, the application Currency Code and Amount, Authorized object must be present on the terminal;
checks whether the condition in question is met. If the check of the second cver byte was unsuccessful and the CVM Condition Code in question corresponds to the last CVER entry in the CVM List, the terminal performs the following actions:
bit 8 of byte 3 of the TVR “Cardholder verification was not successful” is set to 1;
the value of the first byte of CVM Results is set to ‘ 3F’h (No CVM performed);
the verification procedure is completed.
If the check of the second cver byte was unsuccessful, but the CVM Condition Code in question corresponds to a cver entry that is not the last in the CVM List, the terminal proceeds to analyze the next cver entry in the CVM List, starting from Step 1.
If all these conditions are met for the current CVER value, the terminal proceeds to Step 2.
Step 2. Check the first byte of the CVER.
First, the fact that the CVM Code (the six rightmost bits of the first byte) is clear to the terminal is checked.
In this case, the terminal sets bytes 1 and 2 of CVM Results equal to the first and second bytes of the CVER record in question, respectively.
If CVM Code=’No CVM required’, the terminal sets byte 3 of CVM Results to ‘ 02’h (Successful) and completes the verification procedure.
If CVM Code= ‘Fail CVM processing’, the terminal sets byte 3 of CVM Results to ‘ Ol’h (Failed), bit 8 of byte 3 of TVR “Cardholder verification was not successful” to 1 (note that setting this bit appeared only in EMV 4.1 specifications; this was done in order to implement online authorization initialization when using this verification method) and completes the verification procedure.
If the CVM Code is not clear to the terminal (for example, because the terminal does not support this verification method), the terminal performs the following actions:
bit 7 of byte 3 of TVR “Unrecognized CVM” is set to 1;
if this CVER entry is the last one in the CVM List then bit 8 of byte 3 of TVR “Cardholder verification
was not successful” is set to 1 and the verification procedure is completed;
— if this CVER entry is not the last one in the CVM List, the terminal moves to the next CVER entry in the CVM List and starts processing it from Step 1.
C. If the CVM Code is clear to the terminal, the terminal performs the corresponding CVM verification method. C1. If the terminal successfully performs the verification procedure according to the selected CVM method, then bit 7 of byte 1 of TSI “Cardholder verification was performed” is set to 1, byte 3 of CVM Results is set according to the cardholder verification result, and the procedure is completed.
C2. If the verification procedure according to the selected CVM method fails, then:
if bit 7 of CVM Code is 0, then bit 8 of byte 3 of TVR “Cardholder verification was not successful” is set to 1 and the verification procedure is completed;
if bit 7 of the CVM Code is equal to 1, then:
if the CVER entry is the last one in the CVM List, then bit 8 of byte 3 of TVR “Cardholder verification was not successful” is set to 1 and the verification procedure is completed;
if the CVER entry is not the last one in the CVM List, the terminal moves to the next CVER entry in the CVM List and starts processing it from Step 1.
Let’s briefly discuss the PIN verification procedures. They are possible methods of verification of the cardholder and are becoming more common due to their reliability and effectiveness. Some PIN verification results are reflected in the bit values of the third byte of the TVR object, thus having a formal impact on the risk management procedures performed by the terminal. The results of PIN verification are also included in the Card Verification Results data object, which records the results of risk management procedures performed by the card.