Offline PIN verification on the EMV Software SDK

As previously mentioned, there are two different methods of offline PIN verification (pin verification by card):
checking the PIN code transmitted to the card in plain text (‘000001’));
verification of the PIN code transmitted to the card in encrypted form (‘OOOOOO’).

In some cases, when performing a transaction, there are situations when the client forgot/does not know their PIN code. It may also happen that the terminal does not support offline PIN verification. Sometimes in such cases, in order to increase the availability of the card service for the cardholder, it is necessary to bypass PIN verification. And this possibility is provided for in the EMV standard.
Let’s describe the algorithm for offline PIN verification. In this case, the terminal processes the CVM List CVER entry, in which the CVM Code is equal to either ‘ 000001 ‘OR ‘ OOOOOO’.
If the terminal does not support offline PIN verification, bit 5 of byte 3 of TVR “PIN entry required and PIN pad not present or not working” is set to 1.
If the terminal supports offline PIN verification, then:
if the PIN pad is inoperable, then bit 5 of byte 3 of TVR ‘PIN entry required and PIN pad not present or not working’ is set to 1;
if the PIN pad is functional, but the terminal or cardholder wants to bypass PIN verification, then bit 4 of byte 3 of TVR ‘PIN entry required, PIN pad present, but PIN was not entered’ is set to 1, cardholder verification according to the CVM method is considered unsuccessful, the CVM Results value is not set, and the next cver entry in the CVM List is selected, if any, and bit 7 of CVM Code is set to 1;
— if the terminal supports offline PIN verification, the PIN pad is working normally and the card holder or terminal is not going to bypass the PIN verification, the PIN verification is performed. The rest of this section describes the procedure for offline PIN verification.
Offline PIN verification is performed as follows. First of all, the terminal sends the GET DATA command to the card, the main parameters of which are shown in the table. 4.15.

Parameters of the GET DATA command
Detail Value
CLA ’80’h
INS ‘ CA’h
P1P2 ‘9F17’h (corresponds to PTC)
Lc Is Missing
Data Is Missing
Le ‘ OO’h

This command is used to extract a primitive PIN Try Counter (PTC, Tag ‘9F17’) data object from the card that is not contained in any linear application file. The RTS element shows the current value of the number of remaining attempts to enter the PIN code for the cardholder. When the value becomes 0, the cardholder does not have any attempts to enter the PIN value.
If the received response contains R-APDU SWlSW2= ‘ 9000’h and RTS=0, the terminal performs the following actions:
does not allow the cardholder to enter the PIN value;
sets the value of bit 6 of byte 3 of TVR ‘PIN Try Limit exceeded’ to 1;
does not display any message regarding the PIN status;
does not set the CVM Results byte;

continues the verification procedure from step C2 of the CVR record processing algorithm described in clause 4.7.1. In this case, the verification procedure is considered to have been completed unsuccessfully.
If the received response contains R-APDU SW1SW2 * ‘900Q’h or SWlSW2=’ 9000’h and RTS* 0, the terminal performs the following actions:
gets the value of the cardholder’s PIN code from the cardholder;
generates a PIN block from the PIN code. The format of the PIN block is shown in clause 3. 10;
if the CVM Code indicates that the encrypted PIN verification method is being used (the last 6 bits of the code are equal to ‘OOOOOO’), it sends the GET CHALLENGE command to the card
Parameters of the GET CHALLENGE command
Detail Value
CLA ‘ OO’h
INS ’84’h
P1 ‘ OO’h
P2 ‘ OO’h
Lc Is Missing
Data Is Missing
Le ‘ OO’h

The GET CHALLENGE command is used to get an 8-6-byte random number from the card, an Unpredictable Number (Tag ‘9F37’). As explained in paragraph 3.13, this number is used to diversify the value of the RSA-encrypted PIN block and the corresponding public key of the card.
The terminal sends the VERIFY command to the card, the data field of which contains the open or closed value of the PIN block.
If an open PIN block is passed, 8 bytes of the PIN block are passed in the data field of the VERIFY command
Parameters of the VERIFY command

Detail Value
CLA ‘ OO’h
INS ’20’h
P1 ’00’h
P2 ’80’h (open PIN block)
’88’h (encrypted PIN block)
Lc Variable, depends on P2
Data PIN block Data
Le ‘ OO’h

The card compares the received PIN value with the value stored on the card. If they match, the offline PIN verification is considered successful. Otherwise, it is considered that the verification of the cardholder failed.
Each time the PIN verification fails, the RTS value is reduced by one. When the VERIFY command arrives on the card and RTS=0, the sw1sw2 byte values are ‘6983’h or’ 6984’h.in other cases, the R-APDU response contains a SW1SW2 of the form ’63xx’, where x indicates the current RTS value (x can take the value 0).
The R-APDU response to the VERIFY command implies the following:
if SWlSW2= ‘ 6983’h, ‘6984’h, ’63C0’h, the PIN verification failed, and the terminal sets the value of bit 6 of byte 3 of TVR “PIN Try Limit exceeded” to 1;
if SWlSW2= ‘ 63cx’h, where x>0, the PIN code check failed, but the cardholder still tries to enter the PRA-
e-value of the PIN code, which the terminal notifies the cardholder about;
if SWlSW2= ‘ 9000’h, PIN verification was successful.
It should be noted that the card, as well as the terminal, fixes
the results of its checks and other actions in a special Card Verification Result (CVR) data object. The EMV standard does not define the format of this data object, leaving it to the choice of payment systems. Since the format of the CVR object is different in the leading payment systems, in this book we will refer to the format defined in the EMV specifications, called Common Core Definitions (CCD), which formed the basis of the Common Payment Application (CPA) standard. For a detailed description of the CVR object structure, see section 4.10.1.
Note that after checking the PIN value, the card sets the value of bit 4 of byte 2 of the CVR to 1. If PIN verification fails, the card sets the value of bit 3 of byte 2 of the CVR to 1. If, in addition, the PIN Try Limit was exceeded, bit 2 of byte 2 of the CVR is set to 1.
Online PIN verification
This section describes the method for online verification of the RS code (‘OOOOOO’).
If the terminal does not support online PIN verification, bit 5 of byte 3 of TVR “PIN entry required and PIN pad not present or not working” is set to 1.
If the terminal supports online PIN verification, then:
if the PIN pad is not working, then bit 5 of byte 3 of TVR “PIN entry required and PIN pad not present or not working” is set to 1;
if the PIN pad is functional, but the terminal or cardholder wants to bypass PIN verification, then bit 4 of byte 3 of TVR “PIN entry required, PIN pad, but PIN was not entered” is set to 1, cardholder verification according to this CVM method is considered unsuccessful, the CVM Results value is not set, and the next CVR entry in the CVM List is selected, if any, and bit 7 of CVM Code is set to 1;
— if the terminal supports online verification of the RS code, the PIN pad works correctly and the card holder or the terminal is not going to bypass the PIN code verification, the online PIN code verification is performed. In this case, the terminal sets bit 3 of byte 3 of TVR “On-line PIN entered” to 1. Verification of the cardholder is completed and considered successful.
Risk management procedures performed by the terminal (Terminal Risk Management)
Risk management procedures (Terminal Risk Management or TRM) performed by the terminal are an element of ensuring the security of operations performed using a plastic card. TRM procedures are designed to force certain transactions to be processed in real time, and include three mechanisms to combat card fraud:
controlling the size of operations performed on the card (Floor Limit Checking);
random transaction Selection for online authorization by the Issuer);
checking offline card usage activity (Velocity Checking).
TRM procedures can be performed by the terminal at any time between the end of the card data reading process and the first GENERATE AC command being generated by the card. TRM procedures must be performed when bit 4 of byte 1 of the AIP “Terminal risk management is to be supported” is equal to 1. Otherwise, according to EMV, the terminal must not perform TRM procedures. However, due to the fact that the servicing Bank in the MasterCard and VISA payment systems is responsible for transactions that exceed the International Floor Limit set for this merchant (the maximum transaction size at which the transaction can be processed offline), merchants must perform the TRM procedure regardless of the AIP value.
After executing TRM procedures, bit 4 of byte 1 of the TSI “Terminal risk management was performed” is set to 1.
Regardless of the value of bit 4 of byte 1, the AIP terminal performs a number of other checks (checking the exception file, determining whether the card is new, etc.). The terminal can support an exception file (otherwise known as a blacklist, black list, or stop list) consisting of Application PAN card numbers and possibly Application PAN Sequence Number, which are not allowed to be used. If the terminal detects the number of the used card/ Application PAN Sequence Number in the exception file, bit 5 of byte 1 of TVR “Card appears in exception file” is set to 1.
In addition, regardless of the value of bit 4 of byte 1, the AIP terminal checks the equality of LATC=0. The LATC (Last Account Transaction Counter, Tag ‘9F13’) parameter represents the number of the last online transaction. To get the current value of this parameter, the terminal must send the GET DATA command to the card with the parameters Pl= ‘9F’h and P2 =’ 13’h.
If the LATC=0 bit is equal to 4 bytes 2, the TVR “New Card” is set to 1.
The terminal also has the ability to forcibly force an operation to be performed in real time. To do this, 6it4 bytes of 4 TVR “Merchant forced transaction online” is set to 1.
Controlling the size of operations performed on the card (Floor Limit Checking)
This risk management procedure is designed to control the amount of money that is spent on the card over a certain period of time (for example, per day or during the execution of a single operation).
The terminal can maintain a transaction log file that stores information about operations performed on the terminal. Each record describing a particular transaction consists of at least the Application PAN card number, Application PAN Sequence Number, transaction amount, and transaction date.
The number of transactions that the terminal can support in the log file is not regulated by EMV specifications and is determined only by the terminal’s capabilities.

The new transaction is recorded in the terminal log file. During the processing of the next transaction, the terminal selects entries from the log file with the values Application PAN and Application PAN Sequence Number used in the operation under consideration. The fields corresponding to the transaction amount are summed for the selected records. The received amount is compared with the value of the Terminal Floor Limit set for this terminal by the servicing Bank in accordance with the recommendations of the payment system. If the received amount is greater than or equal to the value of Terminal Floor Limit, the terminal sets bit 8 of byte 4 of TVR “Transaction exceeds floor limit” to 1.
If the log file is not kept on the terminal, the size of the current transaction is compared with the value of Terminal Floor Limit.If the transaction amount is greater than or equal to Terminal Floor Limit, the terminal sets bit 8 of byte 4 of TVR “Transaction exceeds floor limit” to 1.
The MasterCard and VISA payment systems control the size of each transaction performed on the terminal. The payment system is determined for each type of commercial enterprise values of limits, called the International Floor Limit. These limits differ for operations performed using a magnetic stripe and a chip. If the transaction size exceeds the established limit, but the terminal processes the transaction in offline authorization mode, the responsibility for possible fraud lies with the servicing Bank.
Servicing banks can set limits for offline transactions (Terminal Floor Limit) on their terminals below the corresponding International Floor Limit values
A random selection of transactions
In practice, transactions for a small amount are often performed in offline authorization mode. This mode of processing the transaction is less secure compared to online authorization of the transaction by the card Issuer and may contribute to the Commission of card fraud. For example, a stolen/lost / cloned card can be successfully used by fraudsters offline if the card Issuer did not have time to put it on the stop list and the transaction size is less than the Terminal Floor Limit value. To avoid the possibility of performing all transactions for a small amount offline, a random transaction selection procedure is used for online authorization by the Issuer. Procedure random is implemented for terminal type Offline terminal with online capabilities (for terminals like Online only it is meaningless, and for terminal type Offline only is not possible).
On the terminal, this procedure is performed as follows. For each application, the Bank in addition to the Terminal Floor Limit determines the parameters of the Target Percentage (a whole number that varies from 0 to 99) Maximum Target Percentage (a whole number that varies from 0 to 99 and not less than the Target Percentage), Threshold Value (a real number, varying in the range from zero to the Terminal Floor Limit).
For any transaction that is smaller than the Threshold Value, a random selection is made that does not depend on the transaction size and determines how the transaction is authorized. The terminal generates a random integer in the range from 0 to 99. If this random number is less than or equal to the Target Percentage value, the transaction is executed in real time. Otherwise, it is offline.
For a transaction whose size is equal to or greater than the Threshold Value but less than the Terminal Floor Limit, the transaction size is taken into account in such a way that the larger it is, the more likely it is to process the transaction in real time. For such transactions, the terminal must compare the generated random number with the Transaction Target Percentage value, which is calculated using the following formula:
Transaction Target Percentage =
= (Maximum Target Percentage – Target Percentage) x Interpolation
Factor + Target Percentage;
Interpretation Factor =
= (Transaction size-Threshold Value) / (Terminal Floor Limit Threshold Value).

If the generated number is less than or equal to the Transaction Target Percentage, the transaction is executed in real time. Otherwise, it will be offline.
Graph of the probability of selecting a transaction for online authorization, depending on the transaction amount

If the transaction is performed in real time according to the described procedure, the terminal must set bit 5 in byte 4 of the TVR “Transaction Selected randomly for online processing” to 1.

Checking offline card usage activity (Velocity Checking)
The procedure for checking offline card activity by the terminal is designed to combat possible fraud based on the likely offline nature of transactions with a small transaction size value.
If the card was used to perform a certain number of consecutive offline operations, the value of which is defined by the Issuer in the Lower Sequential Offline Limit parameter (Tag ‘9F14’), the terminal must conduct another transaction for this purpose
a real-time card, if, of course, the terminal is able to perform a transaction in real time.
If the terminal for some reason cannot perform an operation in real time (for example, an Offline only terminal), the next transaction, despite exceeding the Lower Sequential Offline Limit, can still be performed offline until the second upper Sequential Offline Limit set by the Issuer (Tag ‘9F23’) is reached. The value of this limit is not less than the value of the Lower Consecutive Offline Limit.
If the number of offline transactions exceeds the Upper Sequential Offline Limit, the terminal must either execute this transaction in real time, or reject it if it is unable to perform the operation online.
After the transaction has been completed in real time, the card will again be able to process subsequent transactions offline until the number of consecutive offline transactions exceeds the Lower Sequential Offline Limit.
In order for the terminal to apply the procedure described above, the lower Sequential Offline Limit and Upper Sequential Offline Limit parameters must be entered on the card during the personalization process and a link to them must be present in the AFL.
The procedure also uses the previously encountered PBX card parameters (Tag ‘9F36’) and LATC (Last Account Transaction Counter, Tag ‘9F13’). The LATC data element represents the number of the last online transaction. To get the current values of these parameters, the terminal must send two GET DATA commands to the card with parameters P1P2 equal to ‘9F36’h (to get the PBX value), and ‘9F13’h (to get the LATC value).
Then the terminal acts according to the following algorithm.
The values of Lower Sequential Offline Limit (Tag ‘9F14’) and Upper Sequential Offline Limit (Tag ‘9F23’) are extracted from data objects read by the terminal. If at least one of the specified objects is missing, the procedure for checking offline card activity is completed.

The terminal sends two GET DATA commands to the card with parameters P1P2 in C-APDU equal to ‘9F36’ (to get the PBX value) and ‘9F13’ (to get the LATC value). If the SW1SW2 value of at least one R-APDU response is not equal to ‘ 9000’h, the following settings are made:
bit 7 of byte 4 of TVR “Lower Sequential Limit Exceeded” is set to 1;
bit b of byte 4 of TVR “Upper Sequential Limit Exceeded” is set to 1.
If the value of SW1SW2 in both R-APDU responses is ‘ 9000’h, z = ATC-LATC is calculated, representing the number of consecutive offline transactions performed since the last online operation, including the transaction being processed.
If Z> Lower Sequential Limit, then bit 7 of byte 4 of TVR “Lower Sequential Limit Exceeded” is set to 1.
If Z> Upper Sequential Limit, then bit 6 of byte 4 of TVR “Upper Sequential Limit Exceeded” is set to 1.
If LATC = 0, then bit 4 of byte 2 of TVR “New Card” is set to 1.
Evaluation of the results of procedures performed by the terminal (Terminal Action Analysis)
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 TVR data object. The next step in processing the transaction is for the terminal to analyze the data received and recorded in the TVR. The purpose of this analysis is to develop a recommendation decision by the terminal on how the transaction processing should be continued from the terminal’s point of view. When we talk about the solution “from the point of view of the terminal”, we mean that in reality the solution is formed based on the rules defined by the servicing Bank/payment system and the card Issuer

There are three possible solutions for the terminal:
the transaction must be approved offline;
the transaction must be sent for EMI authorization
awning;
— the transaction must be rejected offline. The terminal’s decision is of a recommendation nature and can be changed within certain limits by the card/Issuer’s decision. This will be discussed below.
The stage of evaluating the results of the procedures performed by the terminal must be completed before the terminal generates the first GENERATE AC command and begin to run after completing the card authentication procedures listed above, verification of the cardholder, verification of transaction processing restrictions, and risk management procedures performed by the terminal. However, if at some stage of transaction processing some TVR bit is set to 1, the terminal should check whether this means that the transaction should be rejected offline according to the policy of the payment system and the card Issuer.
Security policy of the Issuer and the servicing Bank
IAC-Denial IAC-Online IAC-Default
TAS-Denial TAC-Online and TAC-Default
The terminal’s assessment of the transaction processing results consists of analyzing the TVR data generated by it during the checks. Two sets of data objects are used for analysis, called Issuer Action Codes (IAC) and Terminal Action Codes (TAC). In turn, each of these sets consists of three objects that have a name that consists of the set name (IAC or TAC) and is hyphenated with one of the following suffixes: Denial, Online, and Default. Thus, the following objects are used:
Each of the listed objects has the same format as the TVR object. This means, in particular, that they are all 5 bytes in size.

IAC and TAC objects are optional from the point of view of the EMV standard. At the same time, leading payment systems require their presence on the card and terminal, respectively. Moreover, payment systems often themselves form mandatory TAS objects for use by servicing banks. An example is the MasterCard and VISA systems, which have defined mandatory TAS objects for their banks. These objects generally depend on the type of terminal (ATM, offline POS terminal, POS terminal that can process a transaction in real time, unattended terminal) that serves the card.
IAC objects are determined by the card Issuer and are added to the card during personalization. Payment systems develop their recommendations on IAC values for issuers, but the banks have the last word. IAC objects reflect the Issuer’s security policy for its operations and define the actions that the Issuer requires from the terminal when processing an operation performed on the Issuer’s card.
The IAC-Denial object (Tag ‘9F0E’) defines the conditions formulated by the Issuer under which a transaction should be rejected offline, without attempting to send it for authorization to the Issuer. If the object is not on the card, the terminal considers all bits of the IAC-Denial object’s data field to be 0 by default.
The IAC-Online object (Tag ‘9F0F’) defines the conditions formulated by the Issuer under which a terminal capable of performing an operation in real time should send a transaction for authorization to the Issuer. If an object is not on the card, the terminal assumes by default that all bits of the IAC-Online object’s data field are equal to 1.
The IAC-Default object (Tag ‘9F0D’) defines the conditions formulated by the Issuer under which a terminal that is unable to perform an operation in real time must reject a transaction in offline mode. If the object is not on the card, the terminal assumes by default that all bits of the IAC-Default object’s data field are equal to 1.
TAC objects are defined in the same way.
The TAC-Denial object defines the conditions of the servicing Bank under which a transaction should be rejected without attempting to send it to the Issuer for authorization. If the card item is missing
however, by default, the terminal considers all bits of the data field of the TAC-Denial object to be 0.
The TAC-OnLine object defines the conditions of the servicing Bank, under which a terminal capable of performing an operation in real time must send a transaction for authorization to the Issuer. If an object is not on the card, the terminal assumes by default that all bits of the TAC-OnLine object’s data field are 0.
The TAC-Default object defines the conditions of the servicing Bank, under which the terminal, unable to perform an operation in real time, must reject the transaction in offline mode. If the object is not on the card, the terminal assumes by default that all bits of the TAC-Default object data field are 0.
At the same time, it is recommended that at least the following bits of the first byte of the TAC-Online and TAC-Default objects be defined by the servicing Bank as 1:
8 bit “Offline Data Authentication was not performed»;
bit 7 is “Offline SDA failed»;
bit 4 ” Offline DDA failed»;
bit 3 “Combined DDA/AC Generation failed”.
Here is a description of how the terminal analyzes TVR data and develops its recommendation decision on how to process the transaction.
Step 1. The terminal selects all equal 1 bits of TVR (single bits). Next, for each such bit, the TVR terminal checks the values of the same bits for it (the bits of two different objects are called the same type if they have the same bit number in the byte and the byte number in the object) in the IAC-Denial and TAC-Denial objects. If the same type of bit in IAC-Denial or TAC-Denial is equal to 1 for a single TVR bit, the transaction must be rejected without attempting to perform online authorization, and the terminal requests the card to generate an AAC (Application Authentication Cryptogram). Otherwise (for all single TVR bits, the same type of bits in IAC-Denial and TAC-Denial are equal to 0), the terminal proceeds to Step 2 if the terminal is able to perform a transaction in real time, and to Step 3 otherwise.
Step 2. The terminal checks TVR against IAC-Online and TAC-Online objects in the same way as Step 1. If, as a result, the same type of bit in IAC-Online or TAC-Online is equal to 1 for a single TVR bit, the terminal considers that the transaction should be sent for authorization to the Issuer, and requests the card to generate an ARQC cryptogram (Authorization Request Cryptogram). Otherwise (for all single TVR bits, the same type of bits in IAC-Online and TAC-Online are equal to 0), the terminal offers the card to approve the transaction in offline mode and requests the card to generate a transaction Certificate.
Stepz. The terminal checks TVR against IAC-Default and TAC-Default objects in the same way as Step 1. If, as a result, the same type of bit in IAC-Default or TAC-Default is equal to 1 for a single TVR bit, the transaction must be rejected, and the terminal requests the card to generate an AAC cryptogram. Otherwise (for all single TVR bits, the same type of bits in IAC-Default and TAC-Default are equal to 0), the terminal offers the card to approve the transaction in offline mode and requests the card to generate a cryptogram of the vehicle.
We will demonstrate how the Issuer’s security policy can be implemented at the stage of analyzing the results of terminal checks using IAC objects. Let’s assume that the Issuer decides to send a transaction for authorization to the Issuer if the static authentication of the card failed and the terminal is able to perform the operation in real time. If the terminal is offline, the Issuer decides to reject the transaction if static authentication of the card fails.
To implement this solution, the values of bit 7 of byte 1 “Offline SDA failed” of the three IAC objects must be defined as follows:
— 0 in IAC-Denial, which means that if static card authentication failed, the transaction should not be unconditionally rejected;
1 in IAC-OnLine, which means that if the terminal can perform an operation in real time, the transaction must be sent to the Issuer;
1 in IAC-Default, which means that if the terminal cannot perform an operation in real time, the transaction must be rejected.
The terminal informs the card of its decision on how to continue the transaction in the first command of creating an AC. The card, in turn, performs its own risk management procedures (card risk management) and makes its own decision on how to complete the operation. At the same time, the level of the card solution should not be higher than the level of the decision made by the terminal (changing the well – known proverb – “the terminal assumes, and the card disposes”). The decision levels in descending order from top to bottom are determined by the following sequence: TC, ARQC, and AAC.
In addition to the above-mentioned solutions available to the terminal, the card can make a fourth decision to complete the transaction through the procedure of contacting the Issuer for alternative authorization (via phone call, telex) in order to obtain more information about the cardholder. Referral corresponding to this authorization method, referral request authorization direction (AAR). Thus, EMV distinguishes four types of cryptograms that complete the decision-making stage in the “card— terminal” dialog: TC, ARQC, APS, and AAS.
In this case, when processing a transaction, the following three types of agreement between the terminal and the card may occur.
If the terminal offers the card to complete the transaction with the vehicle cryptogram, the card can choose any of the four cryptograms of the vehicle, ARQC, AAR, and AAS.
If the terminal offers the card to complete the transaction with the ARQC cryptogram, the card can choose any of the three cryptograms ARQC, AAR, and AAC.
If the terminal offers the card to complete the transaction with the AAS cryptogram, the card can only leave the terminal’s choice— the AAS cryptogram.
If the card chooses a solution that does not agree with the terminal’s solution, this indicates that the card application is not working correctly. The terminal should stop processing the transaction if it detects such a fact.
In turn, the terminal can change the card’s decision when using the card authentication method in a transaction and the card authentication failure detected by the terminal after processing the response to the first command to create an AC. In this case, the terminal behaves as follows:
if the card has generated a vehicle cryptogram, the terminal rejects the transaction with the authorization code Z1 (the transaction was rejected by the terminal);
if the card generated an ARQC cryptogram, Z Z1 generate generate generate, requiring it to respond with an AAC cryptogram.
The terminal requests an AAS cryptogram
The terminal sends its decision to the card using the create as command. Let’s first consider the case when the terminal offers the card to reject the transaction. In this case, as described in clause 3.10, the command parameter P1 is set to ‘ 00’h. the terminal’s Decision to reject the operation is mandatory for the card. After receiving the command to create an AC with the P1 parameter equal to VG, the card generates the AAC cryptogram and sets bits 8 and 7 in the single-byte data cryptogram element of The data field of the p-AIU response block to 0.
The return of the AAC cryptogram indicates that either the transaction was rejected due to an unacceptably high risk for the Issuer arising from the characteristics of the transaction (transaction size, transaction type, etc.), or due to certain restrictions on the use of the card by the Issuer (for example, AUC, AUC AUC).
The card in response to the command to create an AC can indicate some reasons for failure. This is done by setting the three lowest bits of the cryptogram information element (reason reason / advice / direction) to the following values:
000—the lack of information;
001-the service requested by the cardholder is not allowed;
010-PT PTL (PIN try Limit-PIN of the PIN code) exceeded;
011-Issuer authentication failed (this value is only possible in the response to the second create as command);
xxx-the remaining values are reserved for future use.
The bit values of the reason/advice/direction of the cryptogram element data can be used by the terminal to display the reason for the authorization refusal in order to provide explanations to the cardholder.
In some exceptional cases, for example, if the PTL value is exceeded, the Issuer may want to receive a notification from the card (this message is a request corresponding to the message type x220 in ISO 8583, see clause 1.4). This notification is sent to the Issuer separately from the authorization request or clearing message. To implement it, the card must inform the terminal that it needs to notify the servicing Bank of the need to send a notification to the card Issuer.
In order for the terminal to learn about the need to generate a special message, bit 4 of the information data cryptogram is set to 1.
When a clearing message containing the AAS cryptogram reaches the Issuer, it becomes a confirmation of the fact that the card took part in the operation for which the refusal was formed.
In conclusion, if the terminal requests the formation of an AAC cryptogram from the card, and the card authentication method was chosen for the card, then the card authentication is not performed (there is no sense, since the decision to reject the transaction has already been made without card authentication). In this case, the card returns the AAC cryptogram in response to the AC creation command without using cryptogram encryption in the application dynamic data signature.