Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
4.10.1. Card Verification Results Data Object
In fig. 4.5 shows a diagram of the transaction authorization process, starting from the moment of making a decision on the method of completion of the operation (TC, ARQC, AAC) by the terminal and ending with making a decision on the method of continuing the transaction processing by the card. The authorization process involves the terminal, the card and the card issuer.
An important role in the decision-making process is assigned to the card, to which the issuer delegates functions related to making a decision on how to complete the transaction. The card, like the terminal, carries out its own risk management procedures (Card Risk Management, or CRM). Further, based on the performed checks, the CRM card analyzes the results obtained and makes a decision (more precisely, the issuer's decision) on how to complete the transaction.
Let us dwell in more detail on the risk management procedures performed by the card. By analogy with the terminal, the results of their checks
Rice. 4.5. Diagram of the process of making a decision by a card to authorize a transaction
the card writes to a special data object called Card Verification Results (CVR). This data object is used only by the card and the issuer to make decisions about the results of transaction processing. Therefore, in general, the format, content and processing rules of the CVR object should be determined by the card issuer. However, payment systems offer their own options for the format and method of processing the CVR object in order to unify it for IPC manufacturers. In this case, the CVR object in the VISA and MasterCard specifications has a different format (for example, in the VIS 1.4.x specifications, the size of its Value field is 4 bytes, including the first byte of the Length Indicator encoding the value '03'h, in the M / Chip 4-6 specifications bytes, and in the CPA specifications - 5 bytes).
The results of CVR checks can be passed to the issuer as a component of the Issuer Application Data object if the card supports this data object in response to the AC GENERATE command. For example, a card conforming to the Common Core Definitions must support the transmission of a CVR in the Issuer Application Data object of the response to the AC GENERATE command. The value of the Value field of the CVR object is transferred to the Issuer Application Data of all known EMV applications - VSDC, M / Chip 4, CPA.
An important difference between CVR and TVR is that the CVR stores part of the history associated with the use of the card. The card not only records the results of its current checks in the CVR, but also stores the individual CVR data, the values of which were determined during previous operations. Before each new transaction, the card, in contrast to the terminal, which resets the value of the data field of the TVR object, does not reset the values of all CVR bits, but uses a more complex algorithm for this, which will be described in clause 4.10.2.
The card performs CRM procedures after receiving the AC GENERATE command. The checks performed by the card can be divided into the following types:
Note that the CCD card allows only three possible solutions in response to the AC GENERATE command: TC, ARQC, AAC. Card-initiated alternate AAR authorization is not supported (note that the AAR cryptogram is also not supported by the M / Chip 4 and VSDC applications).
Tab. 4.19. Byte 1 CVR (leftmost)
Tab. 4.20. Byte 2 CVR
Tab. 4.21. Byte 3 CVR
Let us describe the algorithm by which the values of the CVR bits change after the CCD card receives the first and second GENERATE AC commands. However, before that, let's make a final note regarding the processing of the transaction in real time and changing the value of the CVR bits after the card receives the second GENERATE AC command.
MasterCa to "EN
Tab. 4.22. Byte 4 CVR
Meaning
Number of Issuer Script Commands Containing Secure Messaging Processed
Issuer Script Processing failed Offline Data Authentication failed on Previous Transaction
Go Online on Next Transaction (the next transaction must be processed online by authorization)
Unable to go Online (the terminal failed to send a transaction for authorization to the issuer)
Tab. 4.23. Byte 5 CVR (rightmost)
It is clear that, having received the second GENERATE AC command, the card must first check the Issuer Authentication Data element received from the issuer. In the case of a CCD card, ARPC generation method 2 (see 3.14) is used, which uses the Card Status Update Data Item (CSU) to compute the cryptogram.
If the ARPC check on the received Issuer Authentication Data item fails, then the CCD card should reject the operation. Indeed, the card receives instructions on how to complete the operation and, possibly, on changing its parameters from some source, the authenticity of which is not just not proven, but it is proved that the source of the information received is false.
However, the question arises of what to do if the card did not receive the Issuer Authentication Data element in response from the issuer and, therefore, the issuer was not authenticated. In this case, the issuer of the CCD card must determine in the card configuration whether it needs to be authenticated in order to be able to recognize the online transaction as successful, or whether the issuer is not required to authenticate.
It is obvious that authorizing a transaction without issuer authentication increases the risk of fraud, but allows so-called "magnetic" issuers (partial grade issuers) to issue IPCs without supporting chip related data processing on their host. In particular, such issuers are not able to verify the ARQC cryptogram and generate an ARPC for the authorization response. In this case, the payment system converts the chip data of the authorization request of the servicing bank into the data of the magnetic card.
There are also service banks that are unable to send IPC-related data to the network, including a partial grade acquirer (ARQC) cryptogram. Therefore, authorization of a transaction without issuer authentication increases the risk of fraud, but expands the card's "range".
To manage risks when using offline authorization mode, the issuer can put the following parameters on the card:
In general, payment systems distinguish between domestic (domestic) and international (non-domestic) transactions. A transaction is considered in-country if the following conditions are met at the same time:
Terminal Country Code = Issuer Country Code;
Transaction Currency Code - Application Currency Code.
Then the VCC parameter checks are performed using the analysis of inequalities ATC - LATC> LCOL / NDCF and ATC - LATC> UCOL / NDCF, where NDCF (Non-Domestic Control Factor) = 1 for domestic transactions and NDCF> 1 for international transactions.
When checking the COTA parameter, it may happen that the Transaction Currency Code is not equal to the Application Currency Code. In this case, the EMV standard provides for the possibility of converting the AA transaction size in the transaction currency into the AA1 transaction size in the Application Currency. To do this, the card must support the Reference Currency to Application Currency Conversion Rate for the transaction currency. The exchange rate is multiplied by the transaction size in the transaction currency in order to obtain the AA1 transaction size in the application currency. Further, the SOTA parameter is checked by analyzing the inequalities LCOTA - SOTA <AA1 and UCOTA - SOTA <AA1.
It should be noted that the limits described above, as well as the NDCF ratio, are specific to M / Chip applications. The VSDC application uses different limits on the number of offline transactions and the amount of money spent on them. These limits include:
Obviously, the VCC and SOTA parameters must be reset periodically. Reinstallation occurs during transaction processing and is only possible if the issuer requires the transaction to be approved. If the transaction should be rejected by the issuer's decision, then the parameters on the card should not be reset. Indeed, one of the reasons for processing a transaction in the online authorization mode is to enable the issuer to periodically estimate the offline costs of the card and, in accordance with these costs and the state of the cardholder's account, make a decision on the authorization result of the current transaction. If the transaction is rejected, and the VCC and SOTA parameters are reset to zero, then the next operation can be performed offline again. Thus, an unscrupulous cardholder has a good way of fraud: initiate an expensive purchase (as a result, an authorization request is sent with a large transaction size), knowingly receiving a refusal of authorization from the issuer, but resetting the VCC and SOTA card counters. At the same time, next time such a cardholder will be able to successfully complete an operation for a small amount in offline authorization mode.
To reset the parameters, it is important that the issuer is successfully authenticated with the card. If the issuer authentication fails, you should not reset the parameters, since the authorization response could come from a third party falsely posing as the card issuer.
As noted earlier, it is possible that the card has not received the Issuer Authentication Data from the issuer. If it is established on the card that the issuer authentication is required for successful authorization of the transaction, then the transaction is rejected in this case. If issuer authentication is optional, then the issuer must determine if issuer authentication is a prerequisite for modifying the VCC and SOTA parameters.
The CCD application uses parameters in CVR called non-velocity checking indicator (NVI):
4.10.2. Setting object parameters
Card Verification Results
Let's start by describing the procedure for setting the values of the parameters of 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 CVR). After processing the first GENERATE AC command, bits 8 and 7 of the first byte CVR should be set equal to 1 and 0, respectively, which corresponds to the value of Second GENERATE AC not requested. After processing the second AC GENERATE command, these bits shall be equal, respectively, to bits 8 and 7 of the Cryptogram Information Data object returned in response to the second AC GENERATE command.
Application Cryptogram Type Returned in First GENERATE AC (bits 6 and 5 of the first byte of CVR). After processing the first and second AC GENERATE commands, these bits shall be equal, respectively, to bits 8 and 7 of the Cryptogram Information Data object returned in response to the first AC GENERATE command of the current transaction.
CDA Performed (bit 4 of byte 1 CVR). After processing the first and second AC GENERATE commands, this bit is set to 1 if and only if the response to the first AC GENERATE command contains a Signed Dynamic Application Data object.
Offline DDA Performed (bit 3 byte 1 CVR). After processing the first and second AC GENERATE 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 byte 1 CVR). After processing the second GENERATE AC command, this bit is set to 1 if and only if the card application does not receive an Issuer Authentication Data from the issuer. This can happen either because the terminal cannot send a transaction for authorization to the issuer, or because the issuer did not send the Issuer Authentication Data element in the authorization response.
After the first AC GENERATE command has been processed, this bit has the value it was assigned after the card last executed the second AC GENERATE command.
Issuer Authentication failed (bit 1 of byte 1 CVR). This bit is set to 1 after the second AC GENERATE command is processed if and only if the issuer authentication has been performed and has failed.
After the first GENERATE AC command, this bit indicates the value set in CVR prior to starting the current transaction. After the second GENERATE AC command, this bit is 1 if it was set during the processing of the current transaction or during the execution of one of the previous transactions and has not been reset since then.
After setting the Issuer Authentication failed bit to 1, it changes its value only if:
Offline PIN Verification Performed (bit 4 of Byte 2 CVR). After processing the first and second GENERATE AC commands, this bit is set to 1 if and only if, during the processing of the current transaction, the card performed a PIN check.
Offline PIN Verification Performed and PIN not successfully verified (bit 3 of Byte 2 CVR). After processing the first and second GENERATE AC commands, this bit is set to 1 if and only if, during the processing of the current transaction, the card performed a PIN check and this check failed.
PIN Try Limit exceeded (bit 2 byte 2 CVR). After processing the first and second GENERATE AC commands, this bit is set to 1 if and only if the value of the PIN Try Counter is 0.
Last Online Transaction not completed (bit 1 of byte 2 CVR). After the first AC GENERATE command has been processed, this bit indicates the value set in CVR prior to starting the current transaction.
After processing the second GENERATE AC command, this bit is 1 if it was set either during the current transaction or during the processing of one of the previous transactions and has not been reset since. During the execution of the current transaction, this bit is set equal to 1 if and only if the card requested online authorization (sent to the issuer ARQC), but the AC did not receive the second GENERATE command from the terminal.
After setting a bit equal to 1, it changes its value only if:
Upper Offline Transaction Count Limit Exceeded (bit 7 of Byte 3 CVR). After the first and second AC GENERATE commands have been processed, this bit is 1 if the VCC counter has exceeded the Upper Offline Transaction Count Limit. This bit can also be reset by changing the card data according to the Card Status Information received from the issuer.
Lower Cumulative Offline Amount Limit Exceeded (bit 6 of Byte 3 CVR). After processing the first and second GENERATE AC commands, this bit is 1 if the value of the Cumulative Offline Transaction Amount counter has exceeded the value of the Lower Cumulative Offline Amount Limit. This bit can also be reset by changing the card data according to the Card Status Information received from the issuer.
Upper Cumulative Offline Amount Limit Exceeded (Bit 5 of Byte 3 CVR). After processing the first and second GENERATE AC commands, this bit is 1 if the value of the Cumulative Offline Transaction Amount counter has exceeded the Upper Cumulative Offline Amount Limit. This bit can also be reset by changing the card data according to the Card Status Information received from the issuer.
Issuer-discretionary bit 1 - Issuer-discretionary bit 4 (bits 4-1 byte 3 CVR). After processing the first and second GENERATE AC commands, these bits are set at the discretion of the issuer.
Number of Issuer Script Commands Containing Secure Messaging Processed (bits 8-5 of byte 4 CVR).
After processing the first and second GENERATE AC commands, these bits are set equal to the number of issuer commands processed by the card, transmitted to the card in the secure data transmission mode (see clause 3.15).
Issuer Script Processing failed (bit 4 of byte 4 CVR). After processing the first and second GENERATE AC commands, this bit is set equal to 1 when at least one command of the Script Processing procedure has failed.
After setting a bit equal to 1, it changes its value only if:
After setting the bit equal to 1, it does not change its value until either the transaction has been sent for authorization to the issuer, or has been approved in offline authorization mode.
Go Online on Next Transaction was set (bit 2 byte 4 CVR). After processing the first and second GENERATE AC commands, this bit is set to 1 when:
In fig. 4.5 shows a diagram of the transaction authorization process, starting from the moment of making a decision on the method of completion of the operation (TC, ARQC, AAC) by the terminal and ending with making a decision on the method of continuing the transaction processing by the card. The authorization process involves the terminal, the card and the card issuer.
An important role in the decision-making process is assigned to the card, to which the issuer delegates functions related to making a decision on how to complete the transaction. The card, like the terminal, carries out its own risk management procedures (Card Risk Management, or CRM). Further, based on the performed checks, the CRM card analyzes the results obtained and makes a decision (more precisely, the issuer's decision) on how to complete the transaction.
Let us dwell in more detail on the risk management procedures performed by the card. By analogy with the terminal, the results of their checks
Rice. 4.5. Diagram of the process of making a decision by a card to authorize a transaction
the card writes to a special data object called Card Verification Results (CVR). This data object is used only by the card and the issuer to make decisions about the results of transaction processing. Therefore, in general, the format, content and processing rules of the CVR object should be determined by the card issuer. However, payment systems offer their own options for the format and method of processing the CVR object in order to unify it for IPC manufacturers. In this case, the CVR object in the VISA and MasterCard specifications has a different format (for example, in the VIS 1.4.x specifications, the size of its Value field is 4 bytes, including the first byte of the Length Indicator encoding the value '03'h, in the M / Chip 4-6 specifications bytes, and in the CPA specifications - 5 bytes).
The results of CVR checks can be passed to the issuer as a component of the Issuer Application Data object if the card supports this data object in response to the AC GENERATE command. For example, a card conforming to the Common Core Definitions must support the transmission of a CVR in the Issuer Application Data object of the response to the AC GENERATE command. The value of the Value field of the CVR object is transferred to the Issuer Application Data of all known EMV applications - VSDC, M / Chip 4, CPA.
An important difference between CVR and TVR is that the CVR stores part of the history associated with the use of the card. The card not only records the results of its current checks in the CVR, but also stores the individual CVR data, the values of which were determined during previous operations. Before each new transaction, the card, in contrast to the terminal, which resets the value of the data field of the TVR object, does not reset the values of all CVR bits, but uses a more complex algorithm for this, which will be described in clause 4.10.2.
The card performs CRM procedures after receiving the AC GENERATE command. The checks performed by the card can be divided into the following types:
- offline check of the PIN-code and the status of the PIN-code check (whether the check was carried out, whether it was successfully completed);
- verification of the fact of card authentication (whether the data signed by the card was returned to the terminal);
- authentication of the card issuer and the status of the issuer authentication procedure (whether the procedure was performed);
- analysis of the results of the previous transaction;
- checking offline limits that limit the number of offline transactions performed by the card in succession;
- checking offline limits that limit the amount of funds spent in sequentially executed offline transactions;
- checking the status and results of the Issuer Script Processing procedures;
- checking the special conditions for servicing the card (for example, during the previous operation it was determined that the current operation should be serviced in real time, special checks of the data received by the card from the GENERATE AC command using the Additional Check Table, determining the fact that card has not yet been used for real-time authorization, etc.).
Note that the CCD card allows only three possible solutions in response to the AC GENERATE command: TC, ARQC, AAC. Card-initiated alternate AAR authorization is not supported (note that the AAR cryptogram is also not supported by the M / Chip 4 and VSDC applications).
Tab. 4.19. Byte 1 CVR (leftmost)
| B8 | B7 | B6 | b3 | b4 | b3 | b2Ы | Meaning | ||
| X | X | Application Cryptogram Type Returned in Second GENERATE AC (type of cryptogram returned after the 2nd GENERATE AC command) | |||
| 0 | 0 | AAS | |||
| 0 | 1 | TS | |||
| 1 | 0 | Second GENERATE AC not requested | |||
| 1 | 1 | Reserved for use | |||
| X | X | Application Cryptogram Type Returned in First GENERATE AC | |||
| 0 | 0 | AAS | |||
| 0 | 1 | TS | |||
| 1 | 0 | ARQC | |||
| 1 | 1 | Reserved for use | |||
| 1 | CDA Performed (the CDA card was authenticated) | ||||
| 1 | Offline DDA Performed (DDA card was authenticated) | ||||
| 1 | Issuer Authentication not performed | ||||
| 1 | Issuer Authentication failed |
Tab. 4.20. Byte 2 CVR
| B8 | B7 | B6 | B5 | B4 b3 | B2 | NS | Meaning |
| X | X | X | X | Low Order Nibble of PIN Try Counter | |||
| 1 | Offline PIN Verification Performed | ||||||
| 1 | Offline PIN Verification Performed and PIN not Successfully Verified | ||||||
| 1 | PIN Try Limit Exceeded | ||||||
| 1 | Last Online Transaction not completed |
Tab. 4.21. Byte 3 CVR
| B8 | B7 | B6 | B5 | B4 | B3 | B2 | NS | Meaning |
| 1 | Lower Offline Transaction Count Limit exceeded | |||||||
| 1 | Upper Offline Transaction Count Limit exceeded | |||||||
| 1 | Lower Cumulative Offline Amount Limit exceeded | |||||||
| 1 | Upper Cumulative Offline Amount Limit exceeded | |||||||
| 1 | Issuer-discretionary bit 1 (issuer data) | |||||||
| 1 | Issuer-discretionary bit 2 (issuer data) | |||||||
| 1 | Issuer-discretionary bit 3 (issuer data) | |||||||
| 1 | Issuer-discretionary bit 4 (issuer data) |
Let us describe the algorithm by which the values of the CVR bits change after the CCD card receives the first and second GENERATE AC commands. However, before that, let's make a final note regarding the processing of the transaction in real time and changing the value of the CVR bits after the card receives the second GENERATE AC command.
MasterCa to "EN
Tab. 4.22. Byte 4 CVR
Meaning
Number of Issuer Script Commands Containing Secure Messaging Processed
Issuer Script Processing failed Offline Data Authentication failed on Previous Transaction
Go Online on Next Transaction (the next transaction must be processed online by authorization)
Unable to go Online (the terminal failed to send a transaction for authorization to the issuer)
Tab. 4.23. Byte 5 CVR (rightmost)
| B8 | B7 | B6 | B5 | B4 | bs | B2 | bl | Meaning |
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Reserved for use |
It is clear that, having received the second GENERATE AC command, the card must first check the Issuer Authentication Data element received from the issuer. In the case of a CCD card, ARPC generation method 2 (see 3.14) is used, which uses the Card Status Update Data Item (CSU) to compute the cryptogram.
If the ARPC check on the received Issuer Authentication Data item fails, then the CCD card should reject the operation. Indeed, the card receives instructions on how to complete the operation and, possibly, on changing its parameters from some source, the authenticity of which is not just not proven, but it is proved that the source of the information received is false.
However, the question arises of what to do if the card did not receive the Issuer Authentication Data element in response from the issuer and, therefore, the issuer was not authenticated. In this case, the issuer of the CCD card must determine in the card configuration whether it needs to be authenticated in order to be able to recognize the online transaction as successful, or whether the issuer is not required to authenticate.
It is obvious that authorizing a transaction without issuer authentication increases the risk of fraud, but allows so-called "magnetic" issuers (partial grade issuers) to issue IPCs without supporting chip related data processing on their host. In particular, such issuers are not able to verify the ARQC cryptogram and generate an ARPC for the authorization response. In this case, the payment system converts the chip data of the authorization request of the servicing bank into the data of the magnetic card.
There are also service banks that are unable to send IPC-related data to the network, including a partial grade acquirer (ARQC) cryptogram. Therefore, authorization of a transaction without issuer authentication increases the risk of fraud, but expands the card's "range".
To manage risks when using offline authorization mode, the issuer can put the following parameters on the card:
- Lower Consecutive Offline Limit (LCOL, Tag '9F14', 1 byte) - defines the maximum number of sequential offline operations that a card can perform on a terminal capable of processing a transaction in real time;
- Upper Consecutive Offline Limit (UCOL, Tag '9F23', 1 byte) - defines the maximum number of sequential offline operations that a card can perform on a terminal that is unable to process a transaction in real time;
- Lower Cumulative Offline Transaction Amount (LCOTA) - defines the maximum amount of funds expressed in Application Currency Code (Tag '9F42') that the issuer allows the cardholder to spend in consecutive offline transactions on a terminal capable of processing a transaction in real time;
- Upper Cumulative Offline Transaction Amount (UCOTA) - defines the maximum amount of funds expressed in Application Currency Code (Tag '9F42') that the issuer allows the card to spend in consecutive offline transactions on a terminal that is unable to process the transaction in real time.
In general, payment systems distinguish between domestic (domestic) and international (non-domestic) transactions. A transaction is considered in-country if the following conditions are met at the same time:
Terminal Country Code = Issuer Country Code;
Transaction Currency Code - Application Currency Code.
Then the VCC parameter checks are performed using the analysis of inequalities ATC - LATC> LCOL / NDCF and ATC - LATC> UCOL / NDCF, where NDCF (Non-Domestic Control Factor) = 1 for domestic transactions and NDCF> 1 for international transactions.
When checking the COTA parameter, it may happen that the Transaction Currency Code is not equal to the Application Currency Code. In this case, the EMV standard provides for the possibility of converting the AA transaction size in the transaction currency into the AA1 transaction size in the Application Currency. To do this, the card must support the Reference Currency to Application Currency Conversion Rate for the transaction currency. The exchange rate is multiplied by the transaction size in the transaction currency in order to obtain the AA1 transaction size in the application currency. Further, the SOTA parameter is checked by analyzing the inequalities LCOTA - SOTA <AA1 and UCOTA - SOTA <AA1.
It should be noted that the limits described above, as well as the NDCF ratio, are specific to M / Chip applications. The VSDC application uses different limits on the number of offline transactions and the amount of money spent on them. These limits include:
- Consecutive Transaction Limit (International) - the maximum number of consecutive offline transactions in which the transaction currency code differs from the card currency code (Application Currency Code);
- Consecutive Transaction Limit (International- Country) - the maximum number of consecutive offline transactions in which the Issuer Country Code differs from the Terminal Country Code;
- Cumulative Total Transaction Amount Limit - the maximum amount of funds that can be spent in sequential offline transactions, the amount of which is expressed in the Application Currency Code;
- Cumulative Total Transaction Amount Limit (Dual Currency) - the maximum amount of funds that can be spent in consecutive offline transactions, the amount of which is expressed in the currency of the Application Currency Code or any other currency selected by the issuer (the size of transactions in another currency is converted into the size of transactions in Application Currency Code).
Obviously, the VCC and SOTA parameters must be reset periodically. Reinstallation occurs during transaction processing and is only possible if the issuer requires the transaction to be approved. If the transaction should be rejected by the issuer's decision, then the parameters on the card should not be reset. Indeed, one of the reasons for processing a transaction in the online authorization mode is to enable the issuer to periodically estimate the offline costs of the card and, in accordance with these costs and the state of the cardholder's account, make a decision on the authorization result of the current transaction. If the transaction is rejected, and the VCC and SOTA parameters are reset to zero, then the next operation can be performed offline again. Thus, an unscrupulous cardholder has a good way of fraud: initiate an expensive purchase (as a result, an authorization request is sent with a large transaction size), knowingly receiving a refusal of authorization from the issuer, but resetting the VCC and SOTA card counters. At the same time, next time such a cardholder will be able to successfully complete an operation for a small amount in offline authorization mode.
To reset the parameters, it is important that the issuer is successfully authenticated with the card. If the issuer authentication fails, you should not reset the parameters, since the authorization response could come from a third party falsely posing as the card issuer.
As noted earlier, it is possible that the card has not received the Issuer Authentication Data from the issuer. If it is established on the card that the issuer authentication is required for successful authorization of the transaction, then the transaction is rejected in this case. If issuer authentication is optional, then the issuer must determine if issuer authentication is a prerequisite for modifying the VCC and SOTA parameters.
The CCD application uses parameters in CVR called non-velocity checking indicator (NVI):
- Issuer Authentication Failed;
- Last Online Transaction not completed (the last online transaction was not completed, that is, the ARQC was sent to the issuer, but no response was received from the card issuer);
- Issuer Script Processing Failed;
- Go Online on Next Transaction was set (a flag indicating that the next transaction should be performed in online authorization mode).
- - successful execution of a transaction is possible without issuer authentication;
- - reinstallation of meters is possible without issuer authentication.
4.10.2. Setting object parameters
Card Verification Results
Let's start by describing the procedure for setting the values of the parameters of 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 CVR). After processing the first GENERATE AC command, bits 8 and 7 of the first byte CVR should be set equal to 1 and 0, respectively, which corresponds to the value of Second GENERATE AC not requested. After processing the second AC GENERATE command, these bits shall be equal, respectively, to bits 8 and 7 of the Cryptogram Information Data object returned in response to the second AC GENERATE command.
Application Cryptogram Type Returned in First GENERATE AC (bits 6 and 5 of the first byte of CVR). After processing the first and second AC GENERATE commands, these bits shall be equal, respectively, to bits 8 and 7 of the Cryptogram Information Data object returned in response to the first AC GENERATE command of the current transaction.
CDA Performed (bit 4 of byte 1 CVR). After processing the first and second AC GENERATE commands, this bit is set to 1 if and only if the response to the first AC GENERATE command contains a Signed Dynamic Application Data object.
Offline DDA Performed (bit 3 byte 1 CVR). After processing the first and second AC GENERATE 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 byte 1 CVR). After processing the second GENERATE AC command, this bit is set to 1 if and only if the card application does not receive an Issuer Authentication Data from the issuer. This can happen either because the terminal cannot send a transaction for authorization to the issuer, or because the issuer did not send the Issuer Authentication Data element in the authorization response.
After the first AC GENERATE command has been processed, this bit has the value it was assigned after the card last executed the second AC GENERATE command.
Issuer Authentication failed (bit 1 of byte 1 CVR). This bit is set to 1 after the second AC GENERATE command is processed if and only if the issuer authentication has been performed and has failed.
After the first GENERATE AC command, this bit indicates the value set in CVR prior to starting the current transaction. After the second GENERATE AC command, this bit is 1 if it was set during the processing of the current transaction or during the execution of one of the previous transactions and has not been reset since then.
After setting the Issuer Authentication failed bit to 1, it changes its value only if:
- 1) either the issuer has been successfully authenticated,
- 2) either the following conditions are met simultaneously:
- - 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);
- - the issuer has not been authenticated;
- - The CCD application does not require issuer authentication to be recognized as a successful transaction;
- - The CCD application does not require issuer authentication to reset the NVI parameter value.
Offline PIN Verification Performed (bit 4 of Byte 2 CVR). After processing the first and second GENERATE AC commands, this bit is set to 1 if and only if, during the processing of the current transaction, the card performed a PIN check.
Offline PIN Verification Performed and PIN not successfully verified (bit 3 of Byte 2 CVR). After processing the first and second GENERATE AC commands, this bit is set to 1 if and only if, during the processing of the current transaction, the card performed a PIN check and this check failed.
PIN Try Limit exceeded (bit 2 byte 2 CVR). After processing the first and second GENERATE AC commands, this bit is set to 1 if and only if the value of the PIN Try Counter is 0.
Last Online Transaction not completed (bit 1 of byte 2 CVR). After the first AC GENERATE command has been processed, this bit indicates the value set in CVR prior to starting the current transaction.
After processing the second GENERATE AC command, this bit is 1 if it was set either during the current transaction or during the processing of one of the previous transactions and has not been reset since. During the execution of the current transaction, this bit is set equal to 1 if and only if the card requested online authorization (sent to the issuer ARQC), but the AC did not receive the second GENERATE command from the terminal.
After setting a bit equal to 1, it changes its value only if:
- 1) either the issuer has been successfully authenticated,
- 2) either the following conditions are met simultaneously:
- - 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);
- - the issuer has not been authenticated;
- - The CCD application does not require issuer authentication to be recognized as a successful transaction;
- - The CCD application does not require issuer authentication to reset the NVI parameter value.
Upper Offline Transaction Count Limit Exceeded (bit 7 of Byte 3 CVR). After the first and second AC GENERATE commands have been processed, this bit is 1 if the VCC counter has exceeded the Upper Offline Transaction Count Limit. This bit can also be reset by changing the card data according to the Card Status Information received from the issuer.
Lower Cumulative Offline Amount Limit Exceeded (bit 6 of Byte 3 CVR). After processing the first and second GENERATE AC commands, this bit is 1 if the value of the Cumulative Offline Transaction Amount counter has exceeded the value of the Lower Cumulative Offline Amount Limit. This bit can also be reset by changing the card data according to the Card Status Information received from the issuer.
Upper Cumulative Offline Amount Limit Exceeded (Bit 5 of Byte 3 CVR). After processing the first and second GENERATE AC commands, this bit is 1 if the value of the Cumulative Offline Transaction Amount counter has exceeded the Upper Cumulative Offline Amount Limit. This bit can also be reset by changing the card data according to the Card Status Information received from the issuer.
Issuer-discretionary bit 1 - Issuer-discretionary bit 4 (bits 4-1 byte 3 CVR). After processing the first and second GENERATE AC commands, these bits are set at the discretion of the issuer.
Number of Issuer Script Commands Containing Secure Messaging Processed (bits 8-5 of byte 4 CVR).
After processing the first and second GENERATE AC commands, these bits are set equal to the number of issuer commands processed by the card, transmitted to the card in the secure data transmission mode (see clause 3.15).
Issuer Script Processing failed (bit 4 of byte 4 CVR). After processing the first and second GENERATE AC commands, this bit is set equal to 1 when at least one command of the Script Processing procedure has failed.
After setting a bit equal to 1, it changes its value only if:
- 1) either the issuer has been successfully authenticated,
- 2) either the following conditions are met simultaneously:
- - 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);
- - the issuer has not been authenticated;
- - The CCD application does not require issuer authentication to be recognized as a successful transaction;
- - The CCD application does not require issuer authentication to reset the NVI parameter value.
- SDA failed;
- DDA failed;
- CDA has failed,
After setting the bit equal to 1, it does not change its value until either the transaction has been sent for authorization to the issuer, or has been approved in offline authorization mode.
Go Online on Next Transaction was set (bit 2 byte 4 CVR). After processing the first and second GENERATE AC commands, this bit is set to 1 when:
- the 'Set Go Online on Next Transaction' bit is set when the card is performing the risk management procedure;
- the 'Set Go Online on Next Transaction' bit is set in the Card Status Update element;
- the issuer, during card personalization, set bit 1 for the new card in CVR.
- 1) either the issuer has been successfully authenticated,
- 2) either the following conditions are met simultaneously:
- - 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);
- - the issuer has not been authenticated;
- - The CCD application does not require issuer authentication to be recognized as a successful transaction;
- - The CCD application does not require issuer authentication to reset the NVI parameter value.
