6.2 Initiate application processing

After the terminal has completed the final selection of the EMV ¢ application in the card, it initiates the EMV ¢ transaction flow, during the initiate application processing stage (see Figure 6.3).

Figure 6.3: Initiate application processing.

6.2.1 TVR and TSI ”two witnesses of terminal processing

First, the terminal resets (bit set on 0) all the bits in the two status registers kept by the terminal ”namely, the TVR (see Section 6.1) and the Transaction Status Information (TSI). This operation marks up the initialization of the EMV ¢ debit/credit transaction in the terminal.

The TVR is a register encoded on 5 bytes, as detailed in Annex C.5 in Book 3 [1]. Each byte of the TVR witnesses the results of the processing performed by the terminal during one of the following stages of the EMV ¢ debit/credit transaction:

Off-line data authentication (byte 1);
Processing restrictions (byte 2);
Cardholder verification (byte 3);
Terminal risk management (byte 4);
Issuer authentication/issuer scripts processing (byte 5).

The TSI is encoded on 2 bytes, as detailed in Annex C.6 in Book 3 [1]. At the moment only 6 bits in the first byte of the TSI are used, while the rest are reserved for future use (RFU). Each of these 6 bits witnesses whether the terminal performed (bit positioned on 1) or did not perform (bit positioned on 0) any of the following stages of the EMV ¢ debit/credit transaction:

Bit 8: Off-line data authentication;
Bit 7: Cardholder verification;
Bit 6: Issuer authentication;
Bit 4: Terminal risk management;
Bit 3: Issuer script processing.

Bit 6 of the TSI witnesses whether the card performed the card risk management or not.

6.2.2 PDOL and GET PROCESSING OPTIONS

The terminal informs the ICC that the processing of a new EMV ¢ transaction begins with a GET PROCESSING OPTIONS command. The C-APDU of this command is summarized in Table 6.1 (according to Table I-17 in Book 3 [1]).

Table 6.1: C-APDU of the `GET PROCESSING OPTIONS`
Code	Value
CLA	80 (proprietary to the EMV ¢ specification)
INS	A8
P1	00 (all other values are RFU)
P2	00 (all other values are RFU)
Lc	Variable (the length of the data field, encoded as a simple TLV)
Data	Tag ˜83 Length Byte String (containing the concatenation of the value fields of the data objects indicated by the card in the PDOL)
Le	00

The byte string contains the concatenation of the value fields of those data objects in the terminal that were indicated by the card application in the PDOL. This object is encoded with the tag 9F38 and is optional. The terminal obtains the PDOL, when it is personalized in the card application, from the FCI of the ADF hosting the selected EMV ¢ debit/credit card application (see Section 4.3.1).

When the PDOL is not included in the FCI, the card will always initiate the processing of the EMV ¢ card application in a standard way, without considering the business environment existent at the point of service. Correspondingly, the response of the card to the GET PROCESSING OPTIONS command will be always the same. In this case the data field of the command will include the data object with tag 83 and the length equal to zero (see Figure 6.3).
When the PDOL is included in the FCI it contains the list of identifiers (tag, length) of some data objects, which the card needs from the terminal in order to appropriately adapt its response to the GET PROCESSING OPTIONS command. These data objects could be those describing the business environment at the point of service like the Terminal Type (tag 9F35), Terminal Capabilities (9F33), Terminal Country Code (9F1A), or the Merchant Category Code (9F15). The data field of the command will include the data object with tag 83 and the length equal to the total length of the byte string.

The issuer decides upon the content of the PDOL, which is stored in the card since the personalization stage, as well as upon the processing performed by the card on the corresponding objects received from the terminal.

6.2.3 AIP and AFL

In the case of a successful processing of the C-APDU, the card application is initialized for a new EMV ¢ debit/credit transaction. Thus, the content of the Application Transaction Counter (ATC) is incremented, and the content of both the AIP and the AFL is adapted according to the business environment at the point of service. The ATC is initially zero, when the card is new, and is incremented by each and every new transaction performed by the card application. The card application returns to the terminal a response R-APDU.

The R-APDU returned by the card to the GET PROCESSING OPTIONS command includes, beside the status words SW1SW2 = 9000, two data objects: the AIP and the AFL. The meaning and content of these two data objects are described below.

The AIP (tag 82) consists of 2 bytes, of which the second byte is RFU, while the first byte encodes the stages of the EMV ¢ debit/credit transaction flow and the corresponding application functions that are actually supported by the card. The meaning of the bits in the first byte is presented in Table 6.2 (according to Annex C.1 in Book 3 [1]).

Table 6.2: AIP, Byte 1
Bit 8	RFU
Bit 7	Indicates whether the off-line SDA is supported: 0 ”not supported; 1 ” supported (the same convention apply for the bits 6, 5, and 2 in the AIP)
Bit 6	Indicates whether the off-line DDA is supported
Bit 5	Indicates whether the cardholder verification is supported
Bit 4	Indicates whether the card requires the terminal to perform the terminal risk management stage (bit 4 = 1) or not (bit 4 = 0).
Bit 3	Indicates whether the card supports the issuer authentication through a separate `EXTERNAL AUTHENTICATE` command (bit 3 = 1) or through the second `GENERATE AC` command (bit 3 = 0).
Bit 2	Indicates whether the card supports combined off-line DDA and `GENERATE AC` .
Bit 1	RFU

The AFL (tag 94) gives the table of contents of the publicly available information provided by the card application. It identifies the AEF(s) and their corresponding records to be used by the terminal for the processing of an EMV ¢ debit/credit transaction. The terminal can only read the AEF(s) indicated in the AFL.

The AFL is a list of AEF(s) file entries, each consisting of 4 bytes, the meaning of which was explained in Section 5.8.1.

The first byte encodes the SFI of the AEF.
The second byte encodes the first record number of the AEF.
The third byte encodes the last record number of the AEF, which can be greater than or equal to the first record number.
The fourth byte indicates the number of records in that AEF, starting from the first record number, that shall be considered by the terminal in the off-line data authentication processing.

After receiving the AIP, the terminal will be able to configure the appropriate sequence of commands to be sent to the card, according to the possibilities of the card. The AFL will allow the terminal to retrieve all the public information from the card (see Section 6.3) that is needed for the completion of the EMV ¢ debit/credit transaction.