Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
As the card authentication procedures are performed, the restrictions on transaction processing are checked, the cardholder is verified, and the risk is managed, the terminal generates a TVR data object. The next stage of transaction processing is the analysis of the data received and recorded in the TVR by the terminal. The purpose of this analysis is the terminal's development of a recommendatory decision on how, from the point of view of the terminal, the processing of the transaction should be continued. When we talk about a decision “from the point of view of the terminal,” they mean that in reality the decision is formed on the basis of the rules determined by the servicing bank / payment system and the card issuer (for more details, see section 4.9.1).
There are three possible terminal solutions:
The terminal's decision is of a recommendatory nature and can be changed within certain limits by the decision of the card / issuer. 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 must begin after the completion of the above procedures for card authentication, cardholder verification, verification of transaction processing restrictions, risk management procedures performed by the terminal.
4.9.1. Issuer's security policy and servicing bank
The terminal's evaluation of the transaction processing results consists in analyzing the TVR data generated by it during the checks. The analysis uses two sets of data objects called Issuer Action Codes (IAC) and Terminal Action Codes (TAC). In turn, each of these sets consists of three objects that have a name consisting of the set name (IAC or TAC) and one of the following suffixes, written through a hyphen: Denial, Online and Default. Thus, the following objects are used:
IAC-Denial TAC-Denial
IAC-Online TAS-Online
lAC-Default TAC-Default
Each of the listed objects has the same format as the TVR object. Hence, in particular, it follows that they are all 5 bytes in size.
The IAC and TAC objects are optional in terms of the EMV standard. At the same time, leading payment systems require their presence on the card and terminal, respectively. Moreover, payment systems themselves form TAS objects that are mandatory 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, POS terminal, unattended terminal) serving the card, as well as on the card product (for example, Maestro, MasterCard).
IAC objects are defined by the card issuer and entered on the card at the time of card personalization. Payment systems develop their own recommendations on the values of IAC for issuers, but the last word rests with the banks. IAC objects reflect the issuer's security policy for its operations and define the actions that the issuer requires from the terminal when processing a transaction performed on the issuer's card.
The IAC-Denial object (Tag '9F0E') defines the conditions formulated by the issuer, if at least one of which is met, the transaction must be rejected offline, without trying to send it for authorization to the issuer. If there is no object on the card, the terminal by default assumes that all bits of the data field of the IAC-Denial object are equal to 0.
The IAC-Online object (Tag '9F0F') defines the conditions formulated by the issuer, upon fulfillment of at least one of which the terminal capable of servicing the operation in real time must send a transaction for authorization to the issuer. If there is no object on the card, the terminal by default assumes that all bits of the data field of the IAC-Online object are equal to 1.
The IAC-Default object (Tag '9F0D') defines the conditions formulated by the issuer, upon fulfillment of at least one of which the terminal, unable to service the operation in real time, must reject the transaction offline. If there is no object on the card, the terminal by default assumes that all bits of the data field of the IAC-Default object are equal to 1.
TAS objects are defined in a similar way.
The TAC-Denial object defines the conditions of the servicing bank, if at least one of which is fulfilled, the transaction must be rejected without trying to send it for authorization to the issuer. If there is no object on the terminal, the terminal assumes by default that all bits of the data field of the TAC-Denial object are 0.
The TAC-Online object defines the conditions of the servicing bank, if at least one of which is fulfilled, the terminal capable of servicing the operation in real time must send the transaction for authorization to the issuer. If there is no object on the terminal, the terminal assumes by default that all bits of the data field of the TAC-Online object are 0.
The TAC-Default object defines the conditions of the serving bank, if at least one of which is fulfilled, the terminal, which is unable to service the operation in real time, must reject the transaction offline. If there is no object on the terminal, the terminal assumes by default that all bits of the data field of the TAC-Default object 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 set equal to 1 by the serving bank:
Step 1. The terminal selects all equal 1 TVR bits (one bits). Further, for each such bit, the TVR terminal checks the values of bits of the same type for it (bits of two different objects are called the same type if they have the same bit number in a byte and a byte number in an object) in the IAC-Denial and TAC-Denial objects. If for some single bit of TVR the same type of bit in IAC-Denial or TAC-Denial is equal to 1, the transaction should be rejected without attempting to perform online authorization, and the terminal asks the card to generate an AAC (Application Authentication Cryptogram) cryptogram. Otherwise (for all TVR 1 bits, the same bits in IAC-Denial and TAC-Denial are 0), the terminal goes to step 2 if the terminal is capable of performing a real-time transaction, or to step 3 otherwise.
Step 2. The terminal, by analogy with step 1, checks TVR against IAC-Online and TAC-Online objects. If, as a result, for some a single TVR bit, the same bit in IAC-Online or TAC-Online turns out to be 1, the terminal considers that the transaction needs to be sent for authorization to the issuer and asks the card to generate an ARQC (Authorization Request Cryptogram) cryptogram. Otherwise (for all single bits of TVR, 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 asks the card to generate a TS cryptogram (Transaction Certificate).
Step 3. By analogy with step 1, the terminal checks the TVR against the IAC-Default and TAC-Default objects. If, as a result, for some single bit of TVR, the same type of bit in IAC-Default or TAC-Default is equal to 1, the transaction should be rejected, and the terminal requests the card to generate an AAC cryptogram. Otherwise (for all single bits of TVR, 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 asks the card to generate the TS cryptogram.
Let us demonstrate how, at the stage of analyzing the results of terminal checks using IAC objects, the issuer's policy to ensure the security of its operations can be implemented. Suppose that in order to ensure an adequate level of security, the issuer requires mandatory online authorization of transactions during which static card authentication has failed.
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:
In addition to the above solutions available to the terminal, the card can make a fourth decision to complete the transaction through the procedure for contacting the issuer for an alternative authorization (via phone call, telex) in order to obtain more information about the cardholder. The application cryptogram corresponding to this authorization method is called the Application Authorization Referral (AAR). Thus, in EMV there are four types of cryptograms that complete the decision-making stage in the "card-terminal" dialogue: ТС, ARQC, AAR, ААС.
Then, when processing a transaction, the following three types of coordination of decisions between the terminal and the card may occur:
In turn, the terminal can change the decision of the card when using the CDA card authentication method in the transaction and failure of the card authentication detected by the terminal after processing the response to the first GENERATE AC command. In this case, the terminal behaves as follows:
• if the card has generated the TS cryptogram, then the terminal rejects the transaction with the authorization code Z1 (the transaction is rejected by the terminal);
• if the card has formed the ARQC cryptogram, then the terminal rejects the transaction with the Z1 code and sends the second GENERATE AC command to the card, demanding the AAC cryptogram from it in response.
4.9.2. The terminal requests the AAC cryptogram
The terminal informs the card of its decision on how to continue processing the transaction using the GENERATE AC command. Let us 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 transaction is binding on the card. After receiving the GENERATE AC command with parameter P1 equal to '00'h, the card generates the AAC cryptogram and sets bits 8 and 7 in the one-byte Cryptogram Information Data element of the R-APDU response block data field to 0.
In general, the AAC cryptogram can be returned by the card in response to the GENERATE АС command on its initiative (the terminal requests ТС, ARQC, AAR, and the card selects ААС) as a result of performing its own risk management procedures (clause 4.10). In this case, the card, in response to the GENERATE AC command, may indicate some reasons for the refusal. This is done by setting the least significant three bits of the Cryptogram Information Data element (called reason / advice / referral) to the following values:
LLC - lack of information;
The values of the reason / advice / referral bits of the Cryptogram Information Data element can be used by the terminal to display the reason for authorization refusal on the terminal display in order to provide clarification 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 (advice request message, corresponding to the x220 type message in the ISO 8583 standard, see section 1.4). Such 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 about the need to send a notification to the card issuer.
In order for the terminal to learn about the need to generate a special advice request message, bit 4 of the Cryptogram Information Data 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 transaction for which the refusal was generated.
In conclusion, we note that if the terminal asks the card for the formation of the AAC cryptogram, and the CDA method was selected for card authentication, then the card is not authenticated (it makes no sense to carry out, 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 GENERATE AC command without using the encryption of the cryptogram in Signed Dynamic Application Data.
4.9.3. Terminal requests ARQC cryptogram
Let us now consider the case when the terminal offers the card to perform an operation online, giving the right to make a decision to authorize the transaction to the card issuer. Obviously, the online way of executing a transaction is impossible for terminals of the offline only type (in this case, Terminal Toure takes one of the values' 13'h, '23'h,' 16'h, '26'h,' 36'h).
To prompt the card to complete a transaction in real time, the terminal must send the card a GENERATE AC command, requesting the ARQC cryptogram from the card. For this, the terminal sets the values of bits 8 and 7 of the parameter P1 of the AC GENERATE command equal to 1 and 0, respectively. If the terminal also wants to perform a dynamic card authentication procedure using the Combined DDA / AC Generation method, then bit 6 of the P1 parameter is set to 1. In the case when the CDOL1 object contains the Terminal Capabilities data object (Tag '9F33'), the value of bit 6 Pl can remain equal to 0, since in this case the card is able to independently determine that the Combined DDA / AC Generation method will be used. This way of choosing the card authentication method is called the Combined DDA / AC Generation implicit choice.
As a result of performing its own risk management procedures, the card can support the terminal's decision on the online method of processing the transaction and generate the AR.QC cryptogram, or make a decision lower in the hierarchy to generate AAR (alternative authorization) or AAC (transaction rejection).
If the card decides to reject the transaction, the AAC cryptogram is returned to the terminal, and the Cryptogram Information Data element is encoded according to the rules described in clause 3.10.
If the card asks the terminal for an alternate authorization, it returns the AAR cryptogram to the terminal. In this case, bits 8 and 7 of the Cryptogram Information Data element of the R-APDU response block are set equal to 1 each, and bit 4 (notification required) - equal to 0. Bits 3 to 1 are used to indicate the reason why the card asks the terminal to perform alternative authorization.
After receiving the AAR cryptogram value in the response to the AC command GENERATE, the terminal can independently, based on, for example, the reason for alternative authorization (bits 1-3 of Cryptogram Information Data), generate an Authorization Response Code (Tag '8A'), which, in accordance with the application A6 Book 4 of EMV 4.2 is one of the following values:
In the case when the terminal does not independently decide on the completion of the operation, it can use the value of the AAR cryptogram received from the card as the ARQC cryptogram and transmit the cryptogram to the issuer in order to receive a decision on the authorization of the operation from it.
The scheme of processing the alternative authorization initiated by the card is shown in Fig. 4.4.
Note that the leading payment systems, as well as the CCD and CPA specifications, do not use alternative authorization initiated by
Rice. 4.4. Diagram of the algorithm for the implementation of alternative authorization card. Moreover, the possibility of refusal to use the alternative authorization initiated by the card in the EMV standard is being discussed.
If the card agrees with the terminal's decision to authorize the transaction in real time, then it returns the ARQC value to the terminal. In this case, the Cryptogram Information Data element is set to '80'h.
If the terminal receives the ARQC cryptogram from the card, it transmits to the card issuer (via the host of the serving bank) an authorization request (xYO message in ISO 8583 terms). It may happen that the authorization request cannot be transmitted to the issuer (message x100 was sent, but message x110 was not received within the allotted time period). In this case, the terminal independently makes a decision on authorizing the transaction and, depending on the decision made, sends the card the Authorization Response Code equal to Y3 (it is impossible to send a request online, approved offline) or Z3 (it is impossible to send a request online, rejected offline ).
If, after processing the first GENERATE AC command, the card responds with the ARQC cryptogram, the CDA method is used to authenticate the card, and the card authentication has failed, then the terminal rejects the transaction with the ARC code equal to Z1 and sends the second AC GENERATE command to the card, requesting the AAC cryptogram from it. ...
During the processing of the transaction, the terminal can send the GENERATE AC command to the card only once if the transaction is authorized offline, or twice if the transaction is authorized online or when the terminal is unable to transmit the authorization request to the issuer. The second command, GENERATE AC, if transmitted, is the final command from the point of view of the terminal, and therefore only two solutions can be requested in it - TC and AAC. The card should allow no more than two calls to the AC GENERATE command during the processing of one transaction. If the terminal issues more than two GENERATE AC commands, the card should respond with SWlSW2 = '6985'h without returning a cryptogram.
Let's list again the main functions performed by the card based on the data received from the terminal in the GENERATE AC command:
Objects CDOL1 and CDOL2 are a list of tags and lengths of data objects, the values of which must be transferred to the card during the first and second GENERATE AC commands, respectively. After reading this data, the terminal in the GENERATE AC commands transmits only the values of the data fields of the objects listed in CDOL1 and CDOL2.
Note that CDOL1 and CDOL2 objects can contain references to the same object. However, despite this, the data field values of such shared objects are transferred to the card in every AC GENERATE command. This is because the value of some objects changes during the processing of a transaction. An example is the TVR data object. After receiving a response from the issuer, the terminal finds out, for example, whether the issuer authentication procedure was successful (whether the x110 message contains the Issuer Authentication Data value) or whether critical commands of the Issuer Script Processing procedure were successfully processed. Depending on this, the value of the last fifth byte of TVR changes.
The only required (Tag-Length) pair in the CDOL1 list is the Unpredictable Number object reference (Tag '9F37') (for CDOL2 this reference is required only if the card supports the CDA method).
If the data field of the CDOL1 object contains Tag '9F33' corresponding to the Terminal Capabilities object, the card is able to independently determine whether this operation will use the CDA method for dynamic card authentication, regardless of the value of bit 6 of the P1 parameter of the C-APDU block of the GENERATE AC command ...
An approximate list of the Tag-Length references contained in the CDOL1 object is shown in table. 4.18.
Let us explain the purpose of the last reference to the TC Hash Value object in table CDOL1. 4.18. There may be data that the card does not need to perform the risk management procedure, but is important for the formation of the cryptogram, since the cryptogram is the signature of the most critical transaction data. The issuer verifies this signature
Tab. 4.18. Card Risk Management Data Object List-1
cards. Such data are defined by the card issuer in a special object Transaction Certificate Data Object List (TDOL, Tag '97') - the Terminal concatenates all data fields listed in the TDOL object and applies the SHA-1 hash function to the resulting bit string. As a result, the value of the Value field of the TC Hash Value object is obtained, which is passed to the card in the GENERATE AC command. This approach can significantly reduce the amount of data transmitted by the terminal to the card.
If TDOL is absent among the data read by the terminal, the Default TDOL value should be used to form the TC Hash Value (TDOL by default). Since the Default TDOL object must be known at the same time to the serving bank and the card issuer, it can only be specified by the payment system. If Default TDOL is used, the terminal shall set bit 8 of Byte 5 of TVR "Default TDOL used" to 1.
If the Default TDOL is required by the card (via CDOL1 / CDOL2), but its value is not present on the card or in the terminal, the Default TDOL is considered to be an empty list.
When using the second GENERATE AC command during the execution of the transaction, the terminal must re-calculate the TC Hash Value corresponding to the new data values defined in TDOL.
The CDOL1 and CDOL2 data objects may also contain references to some of the data received by the terminal while it is executing risk management (TRM) procedures. Among such data it should be noted:
The list of data objects used by the card to generate a cryptogram is determined by the card issuer (more precisely, by the payment system) and is stored on the card in a form not regulated by the EMV standard.
There are three possible terminal solutions:
- the transaction must be approved offline;
- the transaction must be sent for authorization to the issuer;
- the transaction must be rejected offline.
The terminal's decision is of a recommendatory nature and can be changed within certain limits by the decision of the card / issuer. 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 must begin after the completion of the above procedures for card authentication, cardholder verification, verification of transaction processing restrictions, risk management procedures performed by the terminal.
4.9.1. Issuer's security policy and servicing bank
The terminal's evaluation of the transaction processing results consists in analyzing the TVR data generated by it during the checks. The analysis uses two sets of data objects called Issuer Action Codes (IAC) and Terminal Action Codes (TAC). In turn, each of these sets consists of three objects that have a name consisting of the set name (IAC or TAC) and one of the following suffixes, written through a hyphen: Denial, Online and Default. Thus, the following objects are used:
IAC-Denial TAC-Denial
IAC-Online TAS-Online
lAC-Default TAC-Default
Each of the listed objects has the same format as the TVR object. Hence, in particular, it follows that they are all 5 bytes in size.
The IAC and TAC objects are optional in terms of the EMV standard. At the same time, leading payment systems require their presence on the card and terminal, respectively. Moreover, payment systems themselves form TAS objects that are mandatory 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, POS terminal, unattended terminal) serving the card, as well as on the card product (for example, Maestro, MasterCard).
IAC objects are defined by the card issuer and entered on the card at the time of card personalization. Payment systems develop their own recommendations on the values of IAC for issuers, but the last word rests with the banks. IAC objects reflect the issuer's security policy for its operations and define the actions that the issuer requires from the terminal when processing a transaction performed on the issuer's card.
The IAC-Denial object (Tag '9F0E') defines the conditions formulated by the issuer, if at least one of which is met, the transaction must be rejected offline, without trying to send it for authorization to the issuer. If there is no object on the card, the terminal by default assumes that all bits of the data field of the IAC-Denial object are equal to 0.
The IAC-Online object (Tag '9F0F') defines the conditions formulated by the issuer, upon fulfillment of at least one of which the terminal capable of servicing the operation in real time must send a transaction for authorization to the issuer. If there is no object on the card, the terminal by default assumes that all bits of the data field of the IAC-Online object are equal to 1.
The IAC-Default object (Tag '9F0D') defines the conditions formulated by the issuer, upon fulfillment of at least one of which the terminal, unable to service the operation in real time, must reject the transaction offline. If there is no object on the card, the terminal by default assumes that all bits of the data field of the IAC-Default object are equal to 1.
TAS objects are defined in a similar way.
The TAC-Denial object defines the conditions of the servicing bank, if at least one of which is fulfilled, the transaction must be rejected without trying to send it for authorization to the issuer. If there is no object on the terminal, the terminal assumes by default that all bits of the data field of the TAC-Denial object are 0.
The TAC-Online object defines the conditions of the servicing bank, if at least one of which is fulfilled, the terminal capable of servicing the operation in real time must send the transaction for authorization to the issuer. If there is no object on the terminal, the terminal assumes by default that all bits of the data field of the TAC-Online object are 0.
The TAC-Default object defines the conditions of the serving bank, if at least one of which is fulfilled, the terminal, which is unable to service the operation in real time, must reject the transaction offline. If there is no object on the terminal, the terminal assumes by default that all bits of the data field of the TAC-Default object 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 set equal to 1 by the serving bank:
- bit 8 "Offline Data Authentication was not performed";
- bit 7 "Offline SDA failed";
- bit 4 "Offline DDA failed";
- bit 3 "Combined DDA / AC Generation failed".
Step 1. The terminal selects all equal 1 TVR bits (one bits). Further, for each such bit, the TVR terminal checks the values of bits of the same type for it (bits of two different objects are called the same type if they have the same bit number in a byte and a byte number in an object) in the IAC-Denial and TAC-Denial objects. If for some single bit of TVR the same type of bit in IAC-Denial or TAC-Denial is equal to 1, the transaction should be rejected without attempting to perform online authorization, and the terminal asks the card to generate an AAC (Application Authentication Cryptogram) cryptogram. Otherwise (for all TVR 1 bits, the same bits in IAC-Denial and TAC-Denial are 0), the terminal goes to step 2 if the terminal is capable of performing a real-time transaction, or to step 3 otherwise.
Step 2. The terminal, by analogy with step 1, checks TVR against IAC-Online and TAC-Online objects. If, as a result, for some a single TVR bit, the same bit in IAC-Online or TAC-Online turns out to be 1, the terminal considers that the transaction needs to be sent for authorization to the issuer and asks the card to generate an ARQC (Authorization Request Cryptogram) cryptogram. Otherwise (for all single bits of TVR, 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 asks the card to generate a TS cryptogram (Transaction Certificate).
Step 3. By analogy with step 1, the terminal checks the TVR against the IAC-Default and TAC-Default objects. If, as a result, for some single bit of TVR, the same type of bit in IAC-Default or TAC-Default is equal to 1, the transaction should be rejected, and the terminal requests the card to generate an AAC cryptogram. Otherwise (for all single bits of TVR, 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 asks the card to generate the TS cryptogram.
Let us demonstrate how, at the stage of analyzing the results of terminal checks using IAC objects, the issuer's policy to ensure the security of its operations can be implemented. Suppose that in order to ensure an adequate level of security, the issuer requires mandatory online authorization of transactions during which static card authentication has failed.
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 fails, then the transaction should not be unconditionally rejected;
- 1 in IAC-Online, which means that if the terminal can conduct a transaction in real time, the transaction must be sent to the issuer;
- 1 in IAC-Default, which means that if the terminal cannot perform the transaction in real time, the transaction must be rejected offline.
In addition to the above solutions available to the terminal, the card can make a fourth decision to complete the transaction through the procedure for contacting the issuer for an alternative authorization (via phone call, telex) in order to obtain more information about the cardholder. The application cryptogram corresponding to this authorization method is called the Application Authorization Referral (AAR). Thus, in EMV there are four types of cryptograms that complete the decision-making stage in the "card-terminal" dialogue: ТС, ARQC, AAR, ААС.
Then, when processing a transaction, the following three types of coordination of decisions between the terminal and the card may occur:
- 1) if the terminal offers the card to complete the transaction with the TC cryptogram, then the card can choose any of the four TC cryptograms, ARQC, AAR, AAC;
- 2) if the terminal offers the card to complete the transaction with the ARQC cryptogram, then the card can choose any of the three ARQC, AAR, AAC cryptograms;
- 3) if the terminal offers the card to complete the transaction with the AAC cryptogram, then the card can only leave the choice of the terminal - the AAC cryptogram.
In turn, the terminal can change the decision of the card when using the CDA card authentication method in the transaction and failure of the card authentication detected by the terminal after processing the response to the first GENERATE AC command. In this case, the terminal behaves as follows:
• if the card has generated the TS cryptogram, then the terminal rejects the transaction with the authorization code Z1 (the transaction is rejected by the terminal);
• if the card has formed the ARQC cryptogram, then the terminal rejects the transaction with the Z1 code and sends the second GENERATE AC command to the card, demanding the AAC cryptogram from it in response.
4.9.2. The terminal requests the AAC cryptogram
The terminal informs the card of its decision on how to continue processing the transaction using the GENERATE AC command. Let us 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 transaction is binding on the card. After receiving the GENERATE AC command with parameter P1 equal to '00'h, the card generates the AAC cryptogram and sets bits 8 and 7 in the one-byte Cryptogram Information Data element of the R-APDU response block data field to 0.
In general, the AAC cryptogram can be returned by the card in response to the GENERATE АС command on its initiative (the terminal requests ТС, ARQC, AAR, and the card selects ААС) as a result of performing its own risk management procedures (clause 4.10). In this case, the card, in response to the GENERATE AC command, may indicate some reasons for the refusal. This is done by setting the least significant three bits of the Cryptogram Information Data element (called reason / advice / referral) to the following values:
LLC - lack of information;
- 001 - the service requested by the cardholder is not allowed;
- 010 - the PTL parameter (PIN Try Limit - the maximum number of attempts to enter the PIN code value) has been exceeded;
- 011 - issuer authentication failed (this value is possible only in response to the second AC GENERATE command);
The values of the reason / advice / referral bits of the Cryptogram Information Data element can be used by the terminal to display the reason for authorization refusal on the terminal display in order to provide clarification 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 (advice request message, corresponding to the x220 type message in the ISO 8583 standard, see section 1.4). Such 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 about the need to send a notification to the card issuer.
In order for the terminal to learn about the need to generate a special advice request message, bit 4 of the Cryptogram Information Data 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 transaction for which the refusal was generated.
In conclusion, we note that if the terminal asks the card for the formation of the AAC cryptogram, and the CDA method was selected for card authentication, then the card is not authenticated (it makes no sense to carry out, 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 GENERATE AC command without using the encryption of the cryptogram in Signed Dynamic Application Data.
4.9.3. Terminal requests ARQC cryptogram
Let us now consider the case when the terminal offers the card to perform an operation online, giving the right to make a decision to authorize the transaction to the card issuer. Obviously, the online way of executing a transaction is impossible for terminals of the offline only type (in this case, Terminal Toure takes one of the values' 13'h, '23'h,' 16'h, '26'h,' 36'h).
To prompt the card to complete a transaction in real time, the terminal must send the card a GENERATE AC command, requesting the ARQC cryptogram from the card. For this, the terminal sets the values of bits 8 and 7 of the parameter P1 of the AC GENERATE command equal to 1 and 0, respectively. If the terminal also wants to perform a dynamic card authentication procedure using the Combined DDA / AC Generation method, then bit 6 of the P1 parameter is set to 1. In the case when the CDOL1 object contains the Terminal Capabilities data object (Tag '9F33'), the value of bit 6 Pl can remain equal to 0, since in this case the card is able to independently determine that the Combined DDA / AC Generation method will be used. This way of choosing the card authentication method is called the Combined DDA / AC Generation implicit choice.
As a result of performing its own risk management procedures, the card can support the terminal's decision on the online method of processing the transaction and generate the AR.QC cryptogram, or make a decision lower in the hierarchy to generate AAR (alternative authorization) or AAC (transaction rejection).
If the card decides to reject the transaction, the AAC cryptogram is returned to the terminal, and the Cryptogram Information Data element is encoded according to the rules described in clause 3.10.
If the card asks the terminal for an alternate authorization, it returns the AAR cryptogram to the terminal. In this case, bits 8 and 7 of the Cryptogram Information Data element of the R-APDU response block are set equal to 1 each, and bit 4 (notification required) - equal to 0. Bits 3 to 1 are used to indicate the reason why the card asks the terminal to perform alternative authorization.
After receiving the AAR cryptogram value in the response to the AC command GENERATE, the terminal can independently, based on, for example, the reason for alternative authorization (bits 1-3 of Cryptogram Information Data), generate an Authorization Response Code (Tag '8A'), which, in accordance with the application A6 Book 4 of EMV 4.2 is one of the following values:
- the transaction is approved offline (Y1) / rejected offline (Z1);
- transaction approved after initiated by AAR (Y2) / declined after initiated by AAR (Z2);
- unable to send authorization request online, transaction approved offline (Y3) / unable to send authorization request online, rejected offline (Z3).
In the case when the terminal does not independently decide on the completion of the operation, it can use the value of the AAR cryptogram received from the card as the ARQC cryptogram and transmit the cryptogram to the issuer in order to receive a decision on the authorization of the operation from it.
The scheme of processing the alternative authorization initiated by the card is shown in Fig. 4.4.
Note that the leading payment systems, as well as the CCD and CPA specifications, do not use alternative authorization initiated by
Rice. 4.4. Diagram of the algorithm for the implementation of alternative authorization card. Moreover, the possibility of refusal to use the alternative authorization initiated by the card in the EMV standard is being discussed.
If the card agrees with the terminal's decision to authorize the transaction in real time, then it returns the ARQC value to the terminal. In this case, the Cryptogram Information Data element is set to '80'h.
If the terminal receives the ARQC cryptogram from the card, it transmits to the card issuer (via the host of the serving bank) an authorization request (xYO message in ISO 8583 terms). It may happen that the authorization request cannot be transmitted to the issuer (message x100 was sent, but message x110 was not received within the allotted time period). In this case, the terminal independently makes a decision on authorizing the transaction and, depending on the decision made, sends the card the Authorization Response Code equal to Y3 (it is impossible to send a request online, approved offline) or Z3 (it is impossible to send a request online, rejected offline ).
If, after processing the first GENERATE AC command, the card responds with the ARQC cryptogram, the CDA method is used to authenticate the card, and the card authentication has failed, then the terminal rejects the transaction with the ARC code equal to Z1 and sends the second AC GENERATE command to the card, requesting the AAC cryptogram from it. ...
During the processing of the transaction, the terminal can send the GENERATE AC command to the card only once if the transaction is authorized offline, or twice if the transaction is authorized online or when the terminal is unable to transmit the authorization request to the issuer. The second command, GENERATE AC, if transmitted, is the final command from the point of view of the terminal, and therefore only two solutions can be requested in it - TC and AAC. The card should allow no more than two calls to the AC GENERATE command during the processing of one transaction. If the terminal issues more than two GENERATE AC commands, the card should respond with SWlSW2 = '6985'h without returning a cryptogram.
Let's list again the main functions performed by the card based on the data received from the terminal in the GENERATE AC command:
- risk management and decision-making on how to complete the transaction;
- calculation of the cryptogram.
Objects CDOL1 and CDOL2 are a list of tags and lengths of data objects, the values of which must be transferred to the card during the first and second GENERATE AC commands, respectively. After reading this data, the terminal in the GENERATE AC commands transmits only the values of the data fields of the objects listed in CDOL1 and CDOL2.
Note that CDOL1 and CDOL2 objects can contain references to the same object. However, despite this, the data field values of such shared objects are transferred to the card in every AC GENERATE command. This is because the value of some objects changes during the processing of a transaction. An example is the TVR data object. After receiving a response from the issuer, the terminal finds out, for example, whether the issuer authentication procedure was successful (whether the x110 message contains the Issuer Authentication Data value) or whether critical commands of the Issuer Script Processing procedure were successfully processed. Depending on this, the value of the last fifth byte of TVR changes.
The only required (Tag-Length) pair in the CDOL1 list is the Unpredictable Number object reference (Tag '9F37') (for CDOL2 this reference is required only if the card supports the CDA method).
If the data field of the CDOL1 object contains Tag '9F33' corresponding to the Terminal Capabilities object, the card is able to independently determine whether this operation will use the CDA method for dynamic card authentication, regardless of the value of bit 6 of the P1 parameter of the C-APDU block of the GENERATE AC command ...
An approximate list of the Tag-Length references contained in the CDOL1 object is shown in table. 4.18.
Let us explain the purpose of the last reference to the TC Hash Value object in table CDOL1. 4.18. There may be data that the card does not need to perform the risk management procedure, but is important for the formation of the cryptogram, since the cryptogram is the signature of the most critical transaction data. The issuer verifies this signature
Tab. 4.18. Card Risk Management Data Object List-1
| Data object | Tag | Size, bytes | Finding |
| Amount, Authorized (Numeric) | '9F02' | 6 | Optional |
| Amount, Other (Numeric) | '9F03' | 6 | Optional |
| Terminal country code | '9F1A' | 2 | Optional |
| Terminal Verification Results | '95' | 5 | Optional |
| Transaction Currency Code | '5F2A' | 2 | Optional |
| Transaction Date | '9A | 3 | Optional |
| Transaction Type | '9C' | 1 | Optional |
| Unpredictable Number | '9F37' | 4 | Necessarily |
| Data Authentication Code | '9F45' | 2 | Optional |
| ICC Dynamic Number | '9F4C' | 2-8 | Optional |
| TC Hash Value | '98' | 20 | Optional |
cards. Such data are defined by the card issuer in a special object Transaction Certificate Data Object List (TDOL, Tag '97') - the Terminal concatenates all data fields listed in the TDOL object and applies the SHA-1 hash function to the resulting bit string. As a result, the value of the Value field of the TC Hash Value object is obtained, which is passed to the card in the GENERATE AC command. This approach can significantly reduce the amount of data transmitted by the terminal to the card.
If TDOL is absent among the data read by the terminal, the Default TDOL value should be used to form the TC Hash Value (TDOL by default). Since the Default TDOL object must be known at the same time to the serving bank and the card issuer, it can only be specified by the payment system. If Default TDOL is used, the terminal shall set bit 8 of Byte 5 of TVR "Default TDOL used" to 1.
If the Default TDOL is required by the card (via CDOL1 / CDOL2), but its value is not present on the card or in the terminal, the Default TDOL is considered to be an empty list.
When using the second GENERATE AC command during the execution of the transaction, the terminal must re-calculate the TC Hash Value corresponding to the new data values defined in TDOL.
The CDOL1 and CDOL2 data objects may also contain references to some of the data received by the terminal while it is executing risk management (TRM) procedures. Among such data it should be noted:
- Terminal Verification Results object (Tag '95');
- the Data Authentication Code object (Tag '9F45'), used to confirm the fact that the terminal has performed the static card authentication procedure;
- ICC Dynamic Number ('9F4C') / DAC (Tag '9F45') object used to confirm that the terminal has performed dynamic / static card authentication.
The list of data objects used by the card to generate a cryptogram is determined by the card issuer (more precisely, by the payment system) and is stored on the card in a form not regulated by the EMV standard.
