7.6 Adaptive initiate application processing

Following a successful selection of an EMV ¢ application in the ICC, the terminal checks whether the PDOL is included or not in the FCI of the selected ADF. The issuer distinguishes between two cases:

The PDOL is not included in the FCI or it is included but is empty. In this case the GET PROCESSING OPTIONS command received from the terminal does not include any data from the business environment at the point of service. Therefore, the card has no input data to process with the GET PROCESSING OPTIONS command.
The PDOL is included in the FCI and is not empty. The card application indicates to the terminal a list of data objects from the business environment, which it would need to receive as input data to the GET PROCESSING OPTIONS command. This is the data the card needs to process in order to initiate the transaction.

In the first case the result of the processing performed by the card, consisting at least of the AIP and AFL, is always the same. The card has no way to adapt its behavior to a certain business environment or another, since no appropriate information is sent from the terminal.

In the second case, the result of the processing performed by the ICC can be made dependent on the content of the data objects required in the PDOL, which is provided by the terminal according to the existing situation at the point of service. Consequently, the ICC can adapt the EMV ¢ transaction profile, through the content of the AIP and AFL, to be the most appropriate from the point of view of the service availability.

In the remainder of this section we consider a design example of an adaptable card application, for which the following items are included in the PDOL:

Terminal Type (tag 9F35): This indicates the environment of the terminal (attended/unattended), its communication capabilities (on-line only/off-line with on-line possibility/off-line only), and its operational control (financial institution/merchant/cardholder).
Amount, Authorized (Binary) (tag 81).
Merchant Category Code (tag 9F15).

For simplicity reasons, we assume a domestic debit/credit scheme where there are no problems linked to different currencies used by the card and terminal.

We will take a closer look at the way the issuer can specify the GET PROCESSING OPTIONS . Thus, the response elaborated by the card application will include a different AFL depending on the communication capabilities of the terminal, the amount involved in the transaction, and the type of merchant at the point of service.

After receiving the GET PROCESSING OPTIONS C-APDU, the card application checks whether the flow conditions needed to process this command are fulfilled.

First, it checks that there is currently an application selected in the card.
Second, the card checks that this is the first time in the current card session that the terminal issues the GET PROCESSING OPTIONS command.

If any of these conditions are not respected, the card responds with SW1SW2 = 6985, "Command not allowed; conditions of use not satisfied" (see Table I-4 in Book 3 of the EMV 2000 specifications), and the initiate application processing is aborted.

The card application proceeds with verifying that the length of the data field received in the C-APDU corresponds to the expected length according to the length of the data elements included in the PDOL. If this verification does not pass, the card responds with the checking error code SW1SW2 = 6700, corresponding to "Wrong length". The card also positions a flag PDOL Processing with Error , which is used by the processing performed by the risk management of the card (see Section 7.10.3). The Application Transaction Counter (tag 9F36) in the card is incremented.

The card parses the byte string received in the value field of the data object with tag 83, according to the tag-length indicators contained in the PDOL. It stores the corresponding value fields of each tag-length indicator, obtaining the complete BER-TLV encoding of the data objects required from the terminal. In case the value field of any required data object is zero, the flag PDOL Processing with Error is set in the card with the meaning "Data element required in the PDOL is not provided". The card risk management process will consider this flag. If a higher resolution is needed during the card risk management processing, the card application can manage a separate flag for each data object present in the PDOL: "Terminal Type required in PDOL and not provided", "Amount, Authorized required in PDOL and not available", and so on. Once these data objects from the point of service are obtained, the card can determine the AFL that is appropriate in the given conditions.

The issuer defines two business contexts as follows :

Context 1

The value fields of the corresponding data objects required in the PDOL are not provided in the data field of the GET PROCESSING OPTIONS command.

OR
The required value fields are provided. The value field of the Terminal Type is an eligible value different than 13, while the Amount, Authorized is above the floor limit. The Terminal Type 13 corresponds to a terminal that has no on-line connection to a financial institution (off-line only), that is working in an environment attended by a shop assistant, and that is being controlled by a financial institution (see Annex A1 in Book 4 of the EMV 2000 specifications).

OR
The Merchant Category Code is different than the code associated with a tollgate operator for highway tax collection.

Within this business context, the issuer associates a default CVM List, which includes three CVRs. For each CVR, the corresponding CVM condition code is set to "Always" (00). Thus, the floor amount X and amount Y, which are associated with this CVM List, are null. Regarding the CVM code of these three rules, these are "Enciphered PIN verified on-line", "Plaintext PIN verification performed by ICC", and "Signature paper", respectively.

Context 2

The required value fields in PDOL are provided. The value field of the Terminal Type is 13.

AND
The Amount, Authorized is below a floor limit accepted as low risk by both the issuer and the acquirer.

AND
The Merchant Category Code corresponds to a tollgate operator for highway tax collection.

This business context can be found at a tollgate on a highway, where the amounts are small and the cardholder has no opportunity to either type in a PIN or to sign the sales slip, unless he or she spends an amount of time that can lead to an unacceptable transaction time.

For this business context the issuer defines the fast CVM List, for which the amount X encodes the floor limit and the amount Y is zero. It contains only one CVR, for which the CVM condition code is 06, "If transaction is in application currency and is under X value", and the CVM code is "No CVM required".

Then, the issuer can organize the public information in the AEF(s) such that all the data elements common to both business contexts are arranged in the AEF(s) with the SFI equal to 1 and 2. The AEF with the SFI equal to 3 includes (besides other data elements specific to the first context) the default CVM List, while the AEF with the SFI equal to 4 includes (besides other data elements specific to the second context) the fast CVM List. Correspondingly, the application will keep two application file locators:

AFL1 includes the list of file entries corresponding to the AEF(s) referred by the SFI 1, 2, and 3.
AFL2 includes the list of file entries corresponding to the AEF(s) referred by the SFI 1, 2, and 4.

Thus, if during the processing performed by the card based on the value fields of the Terminal Type, Amount, Authorized, and Merchant Category Code the first business context is identified, then the card retrieves the AFL1. This AFL1 is included beside the AIP in the R-APDU. Otherwise, AFL2 is included in the R-APDU. When the card completes the processing successfully, the SW1 SW2 status words are set to 9000 and the R-APDU is sent to the terminal.