Risk management cards

Card risk management an Important role in the process of transaction processing is assigned to the card, which is delegated by the Issuer functions related to the decision on how to complete the transaction. The card, like the terminal, performs its own risk management procedures (Card Risk Management-CRM). Based on the performed checks, the card analyzes the results obtained and makes its decision (more precisely, the decision of the Issuer) on the way to complete the transaction.

By analogy with the terminal, the card writes the results of its checks to a data element called Card Verification Results (CVR). This data element is only used by the card (and the issuer1) to make decisions about 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 risk management procedures performed by the card can be divided into the following types:
▪ determining PIN verification status in offline mode
▪ analyzing the results of the previous transaction
▪ checking offline limits that limit the number of consecutive offline transactions performed by the card
▪ checking offline limits that limit the amount of funds, spent in sequentially executed offline cards transactions
▪ checking the status and result of script processing commands
▪ checking the special conditions of service of the card (signs that signal the need to perform the current transaction in online, determining the fact that the card has never been authorized by the Issuer, etc.)

As 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, which are 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 making decisions by the card. Therefore, only the CVR bits that inform the results are defined in CIAC

The CVR is passed to the Issuer as a component of the Issuer Application Data object.

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 indication
the Issuer of the features that determine the decision of the card, in special objects recorded in the
payment application during its personalization. But for a very large number of payment
application apply the logic of the CVR and CIAC.

Complete the previous transaction and exceptional situations recorded for the current transaction. The card’s decision to process the transaction includes the following steps:

  • 1. If the terminal requests an AAC cryptogram from the card, the card does not analyze the CVR and generates the requested cryptogram.
  • 2. If the terminal requests an ARQC cryptogram from the card, the card’s actions depend on the type of terminal. When a terminal is able to perform a transaction online, the terminal agrees to 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.
  • 3. When the terminal requests a TC cryptogram from the card and the CVR has the bits that match CIAC-Denial2, the transaction is rejected, the card generates 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.
  • 4. 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 believes that the transaction needs to be approved offline, and generates a TC cryptogram.
  • 5. If the CVR has bits that match CIACDefault, the transaction is rejected and the card generates an AAC cryptogram. Otherwise, the card offers to approve the transaction offline, and generates a TC cryptogram. Consider how the Issuer can control the card’s decision to process a transaction using the features set in CIAC, for example, offline counters. In most payment applications there are two types of counters: