Verified EMV Software with reviews

Terminal Risk Management

The risk management procedures performed by the terminal are an element of ensuring the security of payment transactions and include three mechanisms to combat card fraud:

• control of the size of transactions performed on the card
• random selection of a transaction for its online authorization by the issuer
• verification of offline activity of card use

As the card authentication procedures are performed, transaction processing restrictions are checked, cardholder verification is verified, and risk management is performed, the terminal generates a field with a set of attributes that inform about the results of checks performed by the terminal during the transaction processing, which is called Terminal Verification Results (TVR). After completing all the procedures, the terminal analyzes all the situations recorded in the TVR. The purpose of this analysis is to develop a recommendation decision by the terminal about how the transaction processing should continue from the point of view of the terminal. There are three possible solutions of the terminal:

• the transaction must be approved offline
• the transaction must be sent for authorization to the issuer
• the transaction must be rejected offline

When we talk about the decision “from the point of view of the terminal”, we mean that in reality the decision is formed on the basis of the rules defined by the servicing bank (payment system) and the card issuer. To do this, two sets of data objects are defined in the EMV specifications, called Issuer Action Codes (IAC) and Terminal Action Codes (TAC). In turn, each of these sets consists of three objects with the suffixes Denial, Online, and Default. Thus, the following objects are used.

Each of these objects has the same format as TVR. IAC and TAC are optional in terms of EMV specifications. But the leading payment systems require their presence on the card and in the terminal. TACs are loaded into the terminal by the servicing bank (for example, Visa and MasterCard define mandatory TACs for servicing banks). These objects depend on the type of terminal and on the card product. IACS are determined by the card issuer and are entered on the card during its personalization. These entities define the issuer’s security policy for its operations. The purpose of the objects is explained in the table below (this table uses a synonym for the phrase “servicing bank” acquirer).

Although all bits of the TAC-Online and TAC-Default objects are 0 by default, at the same time, EMVCo strongly recommends that the servicing bank identify at least the following signs:
– offline authentication of card data
– failed offline authentication of card data failed
The terminal forms its decision on how to process the transaction by comparing the bits set in TVR, IAC, and TAC as follows.

If there are single bits in the TVR and the corresponding bits in IAC-Denial and TAC-Denial are also set to 11, then the transaction must be rejected without attempting to perform online authorization. Otherwise, the terminal proceeds to step 2, if the terminal is able to perform the transaction online, or to step 3, when the terminal only works offline.

When the TVR has single bits and the corresponding bits in IAC-Online and TAC-Online are also set to 1, the terminal considers that the transaction should be sent to the issuer for authorization. Otherwise, the terminal offers the card to approve the transaction offline. If there are single bits in the TVR and the corresponding bits in IAC-Default and TAC-Default are also set to 1, then the terminal considers that the transaction should be rejected. Otherwise, the terminal offers the card to approve the transaction offline.

The terminal informs the card in the first GENERATE AC command about the method of processing the transaction. In the first GENERATE AC command, the terminal can request the card to generate one of the following cryptograms.

• AAC (Application Authentication Cryptogram) cryptograms, if the transaction is to be rejected without attempting to perform online authorization.
• ARQC (Authorization Request Cryptogram), when the terminal has decided to send a transaction for authorization to the issuer.
• TC (Transaction Certificate) cryptograms, if the terminal offers the card to approve the transaction in offline mode

An important role in the transaction processing process is assigned to the card, to which the issuer delegates the functions associated with deciding on the method of completing the transaction. The card, like the terminal, performs its own risk management procedures (Card Risk Management – CRM). Based on the checks performed, the card analyzes the results obtained and makes its decision (more precisely, the issuer’s decision) on the method of completing the transaction.
By analogy with the terminal, the card records the results of its checks in a data element called Card Verification Results (CVR). This data element is only used by the card (and the issuer1) to make decisions based on the results of transaction processing. An important difference between CVR and TVR is that CVR often stores not only information about the current state, but also part of the history associated with the use of the card, which may be required by the issuer.

The card receives from the terminal in the GENERATE AC command not only the type of transaction requested by the terminal, but also the data that the card needs to perform its own risk management procedures. The terminal learns about what data the card needs to perform risk management procedures and calculate the cryptogram through the lists of data objects, which are described in the next section.

Card Risk Management

The risk management procedures performed by the card can be divided into the following types:

• determining the PIN verification status in offline mode
• analysis of the results of the preceding transaction
• check offline limits on the number of sequentially executed card offline transaction
• check offline limits on the amount of funds spent in the sequence card offline transactions
• check the status and result of command execution script processing
• check the special conditions of service card (signs that signal the need to implement the current transaction online, the definition of the fact that the card has never been authorized by the Issuer, etc.)

As the risk management procedures are completed, the card generates a CVR. After completing all the procedures, the card analyzes all the situations recorded in the CVR. The purpose of this analysis is to develop a decision on the processing of the transaction by the card. The decision is based on the rules defined by the card issuer. To do this, the payment application defines a set of data objects called Card Issuer Action Codes (CIAC) and consists of three objects with the suffixes Denial, Online, and Default, i.e. CIAC-Denial, CIAC-Online, and CIAC-Default. 2
Each of the CIAC objects has a format similar to the CVR format. As discussed earlier, the CVR stores some information about the current state that is not used in card decision-making. In this regard, only the CVR bits that inform about the results are defined in CIAC

1 The CVR is passed to the issuer as a component of the Issuer Application Data object.
2 Not all payment applications support Card Risk Management logic using CVR and CIAC. For example, the Visa application uses a different algorithm based on the issuer’s indication of the features that determine the card’s decision in special objects recorded in the payment application during its personalization. But for a very large number of payment applications, the CVR and CIAC logic is applied.

The card’s decision to process the transaction includes the following steps:

• If the terminal requests an AAC cryptogram from the card, the card does not analyze the CVR and generates the requested cryptogram.
• If a terminal requests an ARQC cryptogram from the card, the card’s actions depend on the type of terminal. When the terminal is able to execute a transaction online, the terminal agrees with the terminal’s decision and generates an ARQC cryptogram. In the case of an offline terminal, the transaction is rejected and an AAC cryptogram is generated.
• When the terminal requests the TC cryptogram from the card, and the CVR is set to the bits that are matched in CIAC-Denial2, the transaction is rejected, the card forms the AAC cryptogram and returns it to the terminal. Otherwise, the card goes either to step 4, if the terminal is able to perform the transaction online, or to step 5, otherwise.
• The card checks whether the non-zero bits in the CVR match the bits set in CIAC-Online. If such a match is found, the card considers that the transaction should be sent to the issuer for authorization, and generates an ARQC cryptogram. Otherwise, the card considers that the transaction needs to be approved offline, and generates a TC cryptogram.
• If the CVR is set to the bits that are matched in CIAC Default, the transaction is rejected, and the card forms an AAC cryptogram. Otherwise, the card offers to approve the transaction offline, and generates a TC cryptogram.

Let’s look at how the issuer can control the card’s decision to process a transaction using the features set in CIAC, using the example of offline counters. In most payment applications, there are two types of counters: a single-byte counter for the number of consecutive transactions performed offline (Sequential Offline Transaction Number-COTN) Again, there are no rules without exceptions. The result of the previous transactions may not be taken into account (depending on the application). But for some payment applications (for example, those created in accordance with the EMV CCD specifications), this is a prerequisite. I.e., the result of the CVR and CIAC bitwise logical multiplication operation is not equal to 0.

The sum of all consecutive payment transactions performed offline (Consecutive Offline Transaction Amount – COTA). Each of the counters corresponds to two limits determined by the issuer: the lower limit and the upper limit. The card sets signs of exceeding the specified limits in the CVR. Any of the counters can be used to limit the amount of funds spent in consecutive offline transactions performed by the card. For example, the issuer wants to use the number of consecutive operations performed offline for this purpose

The logic of limiting the offline transactions executed sequentially by the card can be described as follows:
if the counter is less than or equal to the lower limit, then the transaction must be executed offline
when the counter is greater than the lower limit, but not higher than the upper limit, the transaction must be authenticated by the issuer on terminals that are able to go online, or must be approved offline if the online operation is not possible because the terminal only works offline, or because the terminal cannot currently perform the transaction online (unable to go online). If the counter exceeds the upper limit, the transaction must be executed online on terminals that are able to go online, or must be rejected if the online operation is not possible.

In order for the card to support this logic of limiting consecutive offline transactions, the issuer must set the CIAC-Online bits “Exceeded the lower limit of offline transactions” and “Exceeded the upper limit of offline transactions”, and the CIAC-Default bit.

Then, if the terminal requests the TC cryptogram, the card increases the counter value by 1, checks its limits, and sets the CVR attribute
“Exceeded the lower limit of offline transactions”, if the counter is greater than the lower limit, and the flag “Exceeded the upper limit of offline transactions”, if the counter is greater than the upper limit. If the CVR does not set any of the signs of exceeding the limit, the card will form a TC cryptogram regardless of the type of terminal. If the CVR is set to exceed the lower limit (but not the upper limit), the online terminal will match the CVR and CIAC-Online signs, and the card will return the ARQC cryptogram, and the TC cryptogram for the offline terminal, since the “Exceeded the lower limit of offline transactions” attribute is not set in CIAC-Default. Finally, if both signs of exceeding the limits are set in the CVR, the card will generate an ARQC cryptogram for the online terminal and an AAC cryptogram for the offline terminal, since the CIAC-Default flag is set
“The upper limit for offline transactions has been exceeded.”

Online transaction processing

The actions performed by the servicing bank or the issuer should not be described in this document. At least because the ECV terminal emulator is not intended for communication with the servicing bank and the issuer. However, for many reasons that will be explained later, it is necessary to explain the logic of processing a transaction online. It should be borne in mind that the following is the most general description, which may not be applicable to a number of payment applications.

If the card in the response to the first GENERATE AC command indicates that the transaction should be sent to the issuer for authorization, the terminal sends a message to the host of the servicing bank that contains information related to the card and the results of processing the transaction. Based on this data, the host of the servicing bank generates an authorization request to the issuer (message x100 of the ISO 8583 standard) containing such data:

• ARQC cryptogram card
• information (PAN, card expiration date, etc.)
• terminal information (ID, type, etc.)
• ATC serial transaction number
• the Issuer Authentication Data element generated by the card

Upon receipt of the authorization request, the issuer checks whether the card used for the transaction is genuine. To do this, the issuer calculates the session key for generating the cryptogram, and then uses it and the transaction data to obtain the cryptogram. The resulting cryptogram is compared with the provided ARQC value. If the values match, the card authentication is considered successful, and the card itself is considered authentic.

Next, the issuer performs standard checks (checking card activity, card usage history, card absence from the list of blocked cards, availability of funds in the card account, etc.). The data received by the issuer in the authorization request allows it to make the correct decision on how to complete the current operation, influence the execution of the next transaction, and correct the card data using script processing commands and / or the Card Status Update (CSU) data element.

After deciding on the result of the operation, the issuer generates the Issuer Authentication Data element. This element contains the issuer’s ARPC cryptogram, which is used by the card to authenticate the issuer, and the Card Status Update (CSU), which indicates whether the transaction is approved or rejected by the issuer, as well as defines the actions that the card should perform from the issuer’s point of view. The authorization response to the servicing bank (message x100 of the ISO 8583 standard) contains the Issuer Authentication Data element, the issuer’s authorization code, and the script processing commands, if they are to be transmitted to the card.
If the terminal did not receive an authorization response or received it too late, the terminal continues to process the transaction, considering that the request cannot be transmitted to the issuer (this situation is usually called “unable to go online”). In any case, the terminal must receive the application cryptogram from the card using the second GENERATE AC command. However, before executing this command, the terminal must pass critical script processing commands to the card, if they are present in the authorization response.

In the second GENERATE AC command, the terminal transmits the data received from the issuer to the card (the issuer’s authorization code, the Issuer element. The CSU and Issuer Authentication Data elements are not required for the payment application. For some applications, only the issuer’s cryptogram is required. Authentication Data and updated data of its checks (TVR). In the second GENERATE AC command, the terminal can request the card to generate one of the following cryptograms. AAC cryptograms if the transaction is to be rejected. TC cryptograms, if the terminal believes that the transaction should be approved. The process of making a decision by the card after receiving the second GENERATE AC command includes the following steps. If the terminal requests an AAC cryptogram, the card generates the requested cryptogram. When the terminal informs about the “unable to go online” situation, the card checks whether the bits set in CIAC-Default do not match the non-zero bits in the CVR. If such a match is found, the transaction is rejected, and the card forms an AAC cryptogram. Otherwise, the card may approve the transaction after performing additional checks. The card authenticates the issuer (checks the value of the ARPC cryptogram in the Issuer Authentication Data element). If the issuer’s authentication is not performed, the transaction is usually rejected (an AAC cryptogram is generated).

If the issuer’s authentication is successful, the card’s further actions are determined by the issuer’s choice, which is defined in the Card Status Update (CSU). The card generates a TC or AAC cryptogram, depending on the issuer’s decision to process the transaction, and performs the actions that the issuer has defined in the CSU (for example, setting a counter for the remaining PIN-count submissions, resetting offline counters, etc.). In addition, the card resets signs of special situations that were recorded during the previous or current transaction.

After the second GENERATE AC command is completed, the terminal must pass the non-critical script processing commands to the card, if they are present in the authorization response. If online processing is not possible (the “unable to go online” situation), the terminal reports this via the issuer’s authorization code (the Issuer Authentication Data element is reset to zero).