ARPC verification in the EMV standard

The CCD application uses parameters called non – velocity checking indicator (NVI) in the CVR):
Issuer Authentication Failed (authentication of the Issuer failed);
Last Online Transaction not completed (the last online transaction was not completed, i.e. the ARQC was sent to the Issuer, but no response was received from the card Issuer);
Issue Script Processing Failed (Script Processing failed);
Go Online on Next Transaction was set (a flag indicating that the next transaction should be performed in online authorization mode).
These parameters take the values 0 or 1.
Obviously, the logic for resetting these parameters is the same as for the VCC and HONEYCOMB parameters. In particular, if the authorization response does not contain the issue Authentication Data element, to reset the NVI parameters and the counter of the Script Processing procedure commands processed by the card, the CCD application must specify that:
successful transaction execution is possible without performing the Issuer authentication procedure;
resetting counters is possible without performing the Issuer authentication procedure.
A fragment of transaction processing that includes a scheme for resetting the card parameters.

Setting parameters for the Card Verification Results object
Let’s start by describing the procedure for setting parameter values for the CVR data object after the first and second GENERATE AC commands.
Application Cryptogram Type Returned in Second GENERATE AC (bits 8 and 7 of the first byte of the CVR). After the first GENERATE AC command, bits 8 and 7 of the first CVR byte must be set to 1 and 0, respectively, which corresponds to the value of Second GENERATE AC not requested. After the second GENERATE AC command, these bits must be equal to bits 8 and 7 of the Cryptogram Information Data object returned in the response to the second GENERATE AC command, respectively.

Application Cryptogram Type Returned in First GENERATE AC (bits 6 and 5 of the first byte of the CVR). After the first and second GENERATE AC commands, these bits must be equal to bits 8 and 7, respectively, of the Cryptogram Information Data object returned in response to the first GENERATE AC command of the current transaction.
CDA Performed (bit 4 of byte 1 CVR). After the first and second GENERATE AC commands, this bit is set to 1 if and only if the response to the first GENERATE AC command contains a Signed Dynamic Application Data object.
Offline DDA Performed (bit 3 bytes 1 CVR). After the first and second GENERATE AC commands, this bit is set to 1 if and only if the response to the INTERNAL AUTHENTICATE command contains a Signed Dynamic Application Data object.
Issuer Authentication not performed (bit 2 of byte 1 CVR). After the second GENERATE AC command, this bit is set to 1 if and only if the card application does not receive the Issuer Authentication Data element from the Issuer. This can happen either because the terminal cannot send the transaction to the Issuer for authorization, or because the Issuer did not send the Issuer Authentication Data element in the authorization response.
After the first GENERATE AC command, this bit has the value that was assigned to it after the last executed card of the second GENERATE AC command.
Issue Authentication failed (bit 1 of byte 1 of CVR). This bit is set to 1 after the second GENERATE command, if and only if the Issuer authentication was performed and failed.
After the first GENERATE AC command, this bit specifies the value set in the CVR before the current transaction is processed. After the second GENERATE AC command, this bit is equal to 1 if it was set in the current transaction or during the execution of one of the previous transactions and has not been reinstalled since.
After setting the issue Authentication failed bit to 1, it changes its value only if:
or successful Issuer authentication has been performed,
or all of the following conditions are met:
— the transaction was successfully sent for authorization to the Issuer (this means that the authorization received by the card

Response Code does not indicate that the transaction could not be sent for authorization to the Issuer);

• Issuer authentication was not performed;
  — The CCD application does not require authentication of the Issuer in order to be considered a successful transaction;
  — The CCD application does not require Issuer authentication to reset the value of the NVI parameters.
  Low Order Nibble of PIN Try Counter (bits 8-5 of byte 2 of the CVR). After the first and second GENERATE AC commands, these bits are set to bits 4-1 of the remaining attempts to enter the PIN correctly PIN Try Counter.
  Offline PIN Verification Performed (bit 4 of byte 2 of the CVR). After the first and second GENERATE AC commands, this bit is set to 1 if and only if the card performed PIN verification during the current transaction.
  Offline PIN Verification Performed and PIN not successfully verified (bit 3 of byte 2 of the CVR). After the first and second GENERATE AC commands, this bit is set to 1 if and only if the card performed PIN verification during the transaction being processed and this verification failed.
  PIN Try Limit exceeded (bit 2 of byte 2 of the CVR). After the first and second GENERATE AC commands, this bit is set to 1 if and only if the PIN Try Counter is 0.
  Last Online Transaction not completed (bit 1 of byte 2 of the CVR). After the first GENERATE AC command, this bit specifies the value set in the CVR before the current transaction is processed.
  After the second GENERATE AC command, this bit is equal to 1 if it was set either during the execution of the current transaction or during the processing of one of the previous transactions and has not been reinstalled since. During the current transaction, this bit is set to 1 if and only if the card requested online authorization (sent to the arqc Issuer), but did not receive the second GENERATE AC command from the terminal.
  After setting the bit to 1, it changes its value only if:
  or successful authentication of the Issuer has been performed,
  or all of the following conditions are met:
  the transaction was successfully sent for authorization to the Issuer (this means that the Authorization Response Code received by the card does not indicate that the transaction could not be sent for authorization to the Issuer);
  Issuer authentication was not performed;
  — The CCD application does not require authentication of the Issuer in order to be considered a successful transaction;
  — The CCD application does not require Issuer authentication to reset the value of the NVI parameters.
  Lower Offline Transaction Count Limit Exceeded (bit 8 of byte 3 of the CVR). After the first and second GENERATE AC commands, this bit is equal to 1 if the VCC counter exceeds the Lower Offline Transaction Count Limit. This bit can also be reset as a result of changing the card data according to the value of the Card Status Information element received from the Issuer.
  Upper Offline Transaction Count Limit Exceeded (bit 7 of byte 3 of the CVR). After the first and second GENERATE AC commands, this bit is equal to 1 if the VCC counter exceeds the Upper Offline Transaction Count Limit. This bit can also be reset as a result of changing the card data according to the value of the Card Status Information element received from the Issuer.
  Lower Cumulative Offline Amount Limit Exceeded (bit b byte 3 of the CVR). After the first and second GENERATE AC commands, this bit is equal to 1 if the cumulative offline transaction amount counter exceeds the Lower Cumulative Offline Amount Limit value. This bit can also be reset as a result of changing the card data according to the value of the Card Status Information element received from the Issuer.
  Upper Cumulative Offline Amount Limit Exceeded (bit 5 of byte 3 of the CVR). After the first and second GENERATE AC commands, this bit is equal to 1 if the cumulative offline transaction amount counter exceeds the Upper Cumulative Offline Amount Limit value. This bit can also be reset as a result of changing the card data according to the value of the Card Status Information element received from the Issuer.
  Issuer-discretionary bit 1 — Issuer-discretionary bit 4 (bits 4-1 of byte 3 of the CVR). After the first and second GENERATE AC commands, these bits are set at the Issuer’s discretion.
  Number of Issuer Script Commands Containing Secure Messaging Processed (bits 8-5 of byte 4 of the CVR).
  After the first and second GENERATE AC commands, these bits are set to equal the number of Issuer commands processed by the card and transmitted to the card in secure data transfer mode.
  Issuer Script Processing failed (bit 4 of byte 4 of the CVR). After the first and second GENERATE AC commands, this bit is set to 1 if and only if a Script Processing command fails.
  After setting the bit to 1, it changes its value only if:
  or successful Issuer authentication has been performed,
  or all of the following conditions are met:
  the transaction was successfully sent for authorization to the Issuer (this means that the Authorization Response Code received by the card does not indicate that the transaction could not be sent for authorization to the Issuer);
  Issuer authentication was not performed;
  — The CCD application does not require authentication of the Issuer in order to be considered a successful transaction;
  — The CCD application does not require Issuer authentication to reset the value of the NVI parameters.
  Offline Data Authentication failed on Previous Transaction (bit 3 of byte 4 of the CVR). After the first and second GENERATE AC commands, this bit is equal to 1 if and only if the TVR element received by the card during one of the last transactions indicates that one of the events occurred:
  SDA failed;
  DDA failed;
  The DDA failed and it was not reinstalled after that.
  After setting the bit to 1 it does not change its value until
  until either the transaction was sent for authorization to the Issuer, or it was approved in offline authorization mode.
  Go Online on Next Transaction was set (bit 2 of byte 4 of the CVR). After the first and second GENERATE AC commands, this bit is set to 1 if and only if:
  the ‘Set Go Online on Next Transaction’ bit is set in the Card Status Update element;
  during card personalization, the Issuer set the value of bit 1 for the new card in the CVR.
  After setting the bit to 1, it changes its value only if:
  or successful authentication of the Issuer has been performed,
  or all of the following conditions are met:
  the transaction was successfully sent for authorization to the Issuer (this means that the Authorization Response Code received by the card does not indicate that the transaction could not be sent for authorization to the Issuer);
  Issuer authentication was not performed;
  — The CCD application does not require authentication of the Issuer in order to be considered a successful transaction;
  — The CCD application does not require Issuer authentication to reset the value of the NVI parameters.
  Unable to to Online (bit 1 of byte 4 of the CVR). After the second GENERATE AC command, this bit is set to 1 if and only if the authorization Response Code (Tag ‘8A’) received from the terminal indicates that the authorization request cannot be passed to the Issuer (i.e. the authorization Response Code takes one of two values — 73′ or 73′).
  The decision-making process card (Card Action Analysis)
  The CCD card application is subject to a number of mandatory restrictions related to the implementation of certain decisions about how to process a transaction. List them.
  If the ‘issue Authentication not Performed’ bit is set to 1 in the CVR, the CCD application must be able to
  in the case of an online terminal, send the transaction to the Issuer for authorization.
  In addition, if it is impossible to send an authorization request to the Issuer (for example, an offline terminal is used), the Issuer must be able to determine on the card the decision to reject or approve the transaction.
  If the issue Authentication Failed’ bit is set to 1 in the CVR, the CCD application should be able to send the transaction to the Issuer for authorization in the case of an online terminal.
  In addition, if it is not possible to send an authorization request to the Issuer, the Issuer must be able to determine on the card the decision to reject or approve the transaction.
  If the ‘PIN Try Limit Exceeded’ bit is set to 1 in the CVR, the Issuer of the CCD application should be able to reject the transaction offline.
  In addition to this solution, in this case, the Issuer should be able to configure the card to send the transaction for authorization to the Issuer, if the terminal is able to process the transaction online. If the terminal cannot send an authorization request to the Issuer (for example, an offline terminal is used), the Issuer must be able to determine on the card the decision to reject or approve the transaction. The CCD application should not block itself or the card if the ‘PIN Try Limit Exceeded’ bit is set to 1. For example, in VIS 1.4 applications.x the application can be blocked if the PTL limit is exceeded.
  If the CVR bit ‘Last Online Transaction Not Completed’ is set to 1, the CCD application should be able to send the transaction to the Issuer for authorization in the case of an online terminal.
  In addition, if it is not possible to send an authorization request to the Issuer, the Issuer must be able to determine on the card the decision to reject or approve the transaction.
  If the ‘Upper Offline Transaction Count Limit Exceeded’ bit is set to 1 in the CVR, the CCD application must reject the transaction if the offline terminal or the Issuer cannot send an authorization request. The CCD application must be able to circumvent this solution for terminals of the Terminal Type= ‘ 26Tt (i.e., for an unattended offline only terminal, or otherwise a SATZ terminal).
  If the CVR bit ‘Lower Offline Transaction Count Limit Exceeded’ is set to 1, the CCD application must send the transaction to the Issuer for authorization in the case of an online terminal.
  If the CVR bit ‘Lower Cumulative Offline Amount Limit Exceeded’ is set to 1, the CCD application must send the transaction to the Issuer for authorization in the case of an offline terminal.
  If the ‘Upper Offline Transaction Count Limit Exceeded’ bit is set to 1 in the CVR, the CCD application must reject the transaction if the offline terminal or the Issuer cannot send an authorization request. The CCD application must be able to circumvent this solution for terminal type=’26’h.
  If the CVR bit ‘Issuer Script Processing failed’ is set to 1, the CCD application must send the transaction to the Issuer for authorization in the case of an online terminal.
  If the CVR bit ‘Go Online on Next Transaction was sef is set to 1, then in case of using an offline terminal or inability to send an authorization request, the Issuer should be able to determine on the card the decision to refuse authorization or approve the transaction.
  Note that all these requirements can be implemented by the card application using three objects: Card Issuer Action Code-Decline (CIAC-Decline), Card Issuer Action Code – Online (CIAC-Online), and Card Issuer Action Code— Offline (CIAC – Offline). The structure of each of the listed objects is completely equivalent to the CVR structure (bits with the same bit number and byte have the same semantic content).
  Note that the term Card Issuer Action Code came from the m/Chip applications of the MasterCard payment system, and the CIAC objects mentioned above are not used in VISA payment system applications. Instead, the VIS specifications use the Application Default Action data object (Tag ‘9F52’, 2 bytes), which defines the actions that the card should initiate when certain conditions are met, mainly fixed in the CVR object. In accordance with the Application DefauLt Action (ADA), the card can reject a transaction, force it to process it in real time, and prepare a notification (advice message) for the card Issuer. Here is an example of an ADA object taken from the VIS 1.4 specifications.x:
  Byte 1:
  bit 8: 1=if the Issuer authentication failed, the next transaction must be processed online;
  6it7:1=if the Issuer authentication failed, the transaction must be rejected;
  bit 6: 1=if Issuer authentication is required, but the ARPC element was not received, the transaction must be rejected;
  bit 5:1=if the transaction is rejected offline, you need to prepare a notification to the Issuer;
  bit 4: 1=if the PTL limit is exceeded during the current transaction, you need to prepare a notification to the Issuer;
  Bitz: 1=if a transaction is rejected due to a failure of Issuer authentication or failure to authenticate the Issuer, you must prepare a notification to the Issuer;
  bit 2:1=if the card is new, the transaction must be processed online;
  bit 1: 1=if the card is new and the terminal cannot send an authorization request to the Issuer, the transaction must be rejected.
  Byte 2:
  bit 8: 1=if the PTL limit is exceeded during the current transaction, the card application must be blocked;
  Bit7:1=if the PTL limit is exceeded during the previous transaction, the transaction must be rejected;
  bitb:1=if the PTL limit is exceeded during the previous transaction, the transaction must be processed online; Bit5:1=if the PTL limit is exceeded during the previous transaction and the transaction cannot be processed online, the operation must be rejected;
  bit 4: 1=if the Issuer Script Processing procedure failed during the previous transaction, the transaction must be processed online; Bitz:1=if the PTL limit is exceeded during the previous transaction, the current transaction must be rejected and the card application blocked; bit 2-1: reserved for future use.
  The ADA object is used if the card supports the Issuer authentication procedure (ARPC verification is optional in the EMV standard).
  Now let’s describe how the card uses CIAC objects to analyze CVR data and make its decision on how to continue processing the transaction after receiving the first GENERATE AC command. A possible scheme for the card to make a decision on how to continue the transaction (TC, ARQC, AAC, note that the AAR cryptogram for the CCD card is not used) is shown in Fig. 4.7.
  From Fig. 4.7 it can be seen that if the terminal requests an AAC cryptogram from the card, the card generates the requested cryptogram without analyzing the CVR object.
  If the terminal requests a vehicle cryptogram from the card, CIAC objects are used according to the algorithm described below.
  Step1. The card selects all equal T bits of CVR (single bits). Then, for each such CVR bit, the terminal checks the values of the same bits for it (the CVR and CIAC bits are called the same type if the bit number and byte number are the same) in the CIAC-DecLine object. If the same bit in CIAC – Decline is equal to 1 for a single CVR bit, the transaction must be rejected without attempting online authorization, and the terminal requests the AAC cryptogram from the card. Otherwise (for all single CVR bits, the same type of bits in CIAC-Decline are equal to 0), the card goes to Step 2 if the terminal is able to perform a transaction in real time, and to Step 3 otherwise.
  Step 2. Similarly to Step 1, the card checks the CVR against the CIAC-Online object. If, as a result, for a single CVR bit, the same type of bit in CIAC-Online is equal to 1, the card considers that the transaction should be sent for authorization to the Issuer and generates an ARQC cryptogram. Otherwise (for all single CVR bits, the same type of bits in CIAC-Online are equal to 0), the card considers that the transaction needs to be approved offline, and generates a cryptogram of the vehicle.
  Step Z. similarly to Step 1, the card checks the CVR against the CIAC-Offline object. If, as a result, for some single CVR bit, the same type of bit in CIAC-Offline is equal to 1, the transaction must be rejected, and the card forms an AAC cryptogram. Otherwise (for all single CVR bits, the same type of bits in CIAC-Offline are equal to 0), the card offers to approve the transaction in offline mode and generates a cryptogram of the vehicle.
  If the terminal requests the ARQC cryptogram from the card, the transaction is processed as follows. In the case of an offline terminal, the transaction is rejected, and the card forms an AAS cryptogram. If the terminal is online, the card can check whether it agrees with the terminal’s decision and whether the transaction should be rejected without the Issuer’s authorization. This verification is usually performed using two data elements: Card TVR Action Code and CIAC-Denial. The Card TVR Action Code object exactly follows the TVR structure and expresses the card’s “view” of when a transaction should be processed online. Sometimes this card view is designed in place of the IAC element, sometimes in addition to it. In this case, the TVR is checked against the Card TVR Action Code and if a match is found in the corresponding bits of the specified data elements, the transaction is sent for additional verification. Otherwise, the transaction is sent to the card Issuer for authorization.
  An additional check consists of finding a match between the CVR and CIAC-Denial elements. If a match is found, the transaction is rejected by the card offline without authorization from the Issuer. If not found, the transaction is sent to the Issuer for authorization.
  If the terminal requests a vehicle in the second GENERATE AC command, the card uses only the CIAC-Offline object when making a decision. The card checks the CVR against the CIAC-Offline object. If, as a result, for a single CVR bit, the same type of bit in CIAC-Offline is equal to 1, the transaction is rejected and the card forms an AAC cryptogram. Otherwise (for all single CVR bits, the same type of bits in CIAC-Offline are equal to 0), the card approves the transaction in offline mode and generates a cryptogram of the vehicle.
  Schematically, the process of making a decision by the card after receiving the second GENERATE AC command.