Acquiring: EMV Transaction Flow. Part 5: READ RECORDS

Introduction

We bring to your attention our next article on «EMV Transaction flow» that will cover the command to READ RECORDS. In this article, we will look into the examples of how the data of Mastercard chip card is read.

GPO RESPONSE

Let us remind you that the stages of EMV Transaction Flow described by us in the previous articles are as follows:

1. ATR
2. Select (1PAY.SYS.DDF01), an attempt of selection through the PSE. In case of denial:
3. Select (AID), selection through the PSA. If there is only one applet, the procedure is finished, moving to the next step. If there are two applets:
4. Application select in manual or authomatic mode.
5. Get Processing Options with or without PDOL.

The next step is APDU-R (response) to the command to Get Processing Options.

Example:

Response: 770E82023900940828010401300102009000

Tag 77: Response Message Template Format 2 — format of data presentation in the response.

Tag 82: Application Interchange Profile: 3900 —​ profile of the card application and description of its functionality. In terms of bytes:

• Byte 1 bit 8 = 0 RFU — reserved for future use.
• Byte 1 bit 7 = 0 Offline static data authentication is NOT supported — offline SDA is not supported.
• Byte 1 bit 6 = 1 Offline dynamic data authentication is supported — offline DDA is supported.
• Byte 1 bit 5 = 1 Cardholder verification is supported.
• Byte 1 bit 4 = 1 Terminal risk management is to be performed — risk management procedure is to be performed.
• Byte 1 bit 3 = 0 Issuer authentication is supported using GENERATE AC command — authentication of the issuer using the generation of the cryptogram is supported.
• Byte 1 bit 2 = 0 On device cardholder verification is NOT supported — the cardholder verification on the mobile device is not supported.
• Byte 1 bit 1 = 1 Combined DDA / GENERATE AC supported — DDA (Dynamic Data Authentication) with generation of the cryptogram is supported.
• Byte 2 bit 8 = 0 Only Mag Stripe profile supported —​ only magnetic stripe mode is supported.

The rest of the second byte’s bits are reserved for future use.

The terminal analyzes the AIP object and compares it with the third byte of its object 9F33 (Terminal Capabilities), following which the mutually supported method of card authentication is to be selected.

After the AIP object, the key element for the command to Read Records is transmitted to the terminal - Tag 94 ((AFL) Application File Locator). This object contains links to the linear files of the card application that the terminal is to read.

Let us introduce the example of its structure:

AFL = 28010401

28 —​ SFI (Short File Identifier), 28 = decimal 5.

01 —​ No. of the first SFI record

04 —​ No. of the last SFI record

01 —​ number of records for ODA (Offline Data Authentication), i.e., for the card authenticity verification.

READ RECORDS

After that, the terminal sends the command to Read Records in accordance with the AFL previously received. Example:

Term: 00B2012C00 (Read Record (SFI 05, record 01))

Cla: 00 —​ command class

Ins: B2 —​ instruction code

P1: 01

P2: 2C

Lc: 00

Data:

It means that the terminal reads the first record in the fifth SFI. Let us consider the data contained in it by analyzing the card’s APDU-R:

Read Record response (OK): 70818C9F420206435F25031603015F24032011305A0855702956266780855F3401029F0702FF008C219F02069F03069F1A0295055F2A029A039C019F37049F35019F45029F4C089F34038D0C910A8A0295059F37049F4C088E14000000000000000042014403410342031E031F039F0D05BC50BC88009F0E0500000800009F0F05BC70BC98005F280206439F4A01829000

По байтам это:

Tag 70: Application Elementary File (AEF) Data Template

Tag 9F42: Application Currency Code: 0643 —​ code of the application currency, rubles.

Tag 5F25: Application Effective Date: 160301 —​ card issue date, 2016, March, 1st day.

Tag 5F24: Application Expiration Date: 201230 —​ card expiry date, 2020, December, 30th day.

Tag 5A: Application Primary Account Number (PAN): 5512345678918085 — the card number itself.

Tag 5F 34: Application PAN Sequence Number: 02 —​ sequence number of the card. Its initial purpose was to be used in the profiles that have more than one application on one physical card. Currently, it is often used in the cryptographic procedures related to the card authenticity verification by the issuer’s host.

Tag 9F07: Application Usage Control (AUC): FF00 —​ the element where the card use capabilities determined by the issuer are specified. In our case, those are the following:

• Byte 1 bit 8 = 1 — Valid for domestic cash transactions: the local (i.e., national or domestic) cash withdrawal transactions are permitted.
• Byte 1 bit 7 = 1 — Valid for international cash transactions: the international cash withdrawal transactions are permitted.
• Byte 1 bit 6 = 1 — Valid for domestic goods: the local goods payment transactions are permitted.
• Byte 1 bit 5 = 1 — Valid for international goods: the international goods payment transactions are permitted.
• Byte 1 bit 4 = 1 — Valid for domestic services: the local services payment transactions are permitted.
• Byte 1 bit 3 = 1 — Valid for international services: the international services payment transactions are permitted.
• Byte 1 bit 2 = 1 — Valid at ATMs: ATMs transactions are permitted.
• Byte 1 bit 1 = 1 — Valid at terminals other than ATMs: permitted for use in the other devices (for example, in the self-service terminals, etc.).
• Byte 2 bit 8 = 0 — Domestic cashback not allowed: local cashback is not permitted.
• Byte 2 bit 7 = 0 — International cashback not allowed: international cashback is not permitted.

The rest of the second byte’s bits are reserved for future use.

Therefore, AUC makes it clear how the card may (and may not) be used. For example, if someone attempts to receive cash at the cash register when purchasing something using it (i.e., cashback), the transaction will be declined without query to the issuer with the offline response code Z1.

Furthermore, the record of interest includes CDOL1 and CDOL2 objects. CDOL (Card Risk Management Data Object List) is a set of data needed for the card to generate the first (CDOL1) and the second (CDOL2) cryptogram of the transaction (Note that it is the contact chip that we look into. In case of exchange using the contactless interface, the second cryptogram is not used; consequently, CDOL2 is not a part of the exchange). We will look into both CDOL objects, one after another.

Tag 8C: Card Risk Management Data Object List 1: 9F02069F03069F1A0295055F2A029A039C019F37049F35019F45029F4C089F3403

As it was mentioned before, the data needed for the card to generate the first cryptogram is specified here. In terms of bytes, it is as follows:

Tag 9F02, length 06: Transaction Amount.

Tag 9F03, length 06: Cashback Amount.

Tag 9F1A, length 02: Terminal Country Code.

Tag 95, length 05: Terminal Verification Results (TVR) —​ the data object where the results of various verifications (ODA, CVM and many others) performed by the terminal are recorded (Hereinafter, TVR will be described when we look into the relevant stage of the EMV exchange).

Tag 5F2A, length 02: Transaction Currency Code.

Tag 9A, length 03: Transaction Date.

Tag 9C, length 01: Transaction Type.

Tag 9F37, length 04: Unpredictable Number (UN) —​ the random number generated by the terminal in order to ensure the uniqueness of the transaction’s cryptogram.

Tag 9F35, length 01: Terminal Type.

Tag 9F45, length 02: Data Authentication Code (DAC) —​ the object involved into the SDA procedure (Static Data Authentication). In our case, the zero value will be sent, because, based on the data in AIP objects (see above), offline SDA is not supported.

Tag 9F4C, length 08: ICC Dynamic Number (IDN) —​ dynamic number of the EMV application. The cryptographic time-related value confirming that the terminal has completed the offline DDA procedure (Dynamic Data Authentication).

Tag 9F34, length 03: Cardholder Verification Method (CVM) Results.

In other words, CDOL1 contains a set of mandatory data that a terminal is to send to the card with the command to Generate AC1. If any data are missing, the transaction will end with error.

CDOL2

Tag 8D: Card Risk Management Data Object List 2: 910A8A0295059F37049F4C08

To generate the second cryptogram, the card needs the following set of data:

Tag 91, length до 16 байт: Issuer Authentication Data (IAD) —​  the cryptographic value transmitted as a part of field 55 of the response message, confirming that the authorization was completed by the issuer of the card.

Tag 8A, length 02: Authorization Response Code —​ code of the issuer’s response transmitted in field 39 of the response message.

Tag 95, length 05: Terminal Verification Results (TVR) — the TVR object that we have already mentioned before.

Tag 9F37, length 04: Unpredictable Number (UN) — the UN object that we have already mentioned before.

Tag 9F4C, length 08: ICC Dynamic Number (IDN) — the IDN object that we have already mentioned before..

If any of those objects is missing in the command to Generate AC2, the transaction will be declined by the card, and the terminal will have to generate the automatic reversal.

CVM List

The next data element present in the record of interest, is CVM List. This object contains the list of the cardholder verification methods supported by the card, as well as the conditions and scenarios of their use. It should be also looked into in detail in the next example.

Tag 8E: Cardholder Verification Method (CVM) List:

• 000000000000000042014403410342031E031F03
• Amount X = 00000000
• Amount Y = 00000000

CVM 1: 4201 (Enciphered PIN verified online) —​ the first method, enciphered online PIN. Conditions of its use:

• Byte 1 bit 8 = 0 (default value)
• Byte 1 bit 7 = 1 (Apply succeeding CVM field if this CVM is unsuccessful)
• Byte 1 bit 6-1= 000010 (Enciphered PIN verified online)
• Byte 2 = '01' (If unattended cash) —​ i.e., that method should be used in ATMs.

CVM 2: 4403 (Enciphered PIN verification performed by ICC) —​ the second method, enciphered offline PIN. Conditions of use:

• Byte 1 bit 8 = 0 (default value)
• Byte 1 bit 7 = 1 (Apply succeeding CVM field if this CVM is unsuccessful)
• Byte 1 bit 6-1= 000100 (Enciphered PIN verification performed by ICC)
• Byte 2 = '03' (If terminal supports the CVM type) —​ this method is used if it is supported by the terminal. Otherwise, go to the next method.

CVM 3: 4103 (Plaintext PIN verification performed by ICC) —​ the third method, plaintext offline PIN. Conditions of use:

• Byte 1 bit 8 = 0 (default value)
• Byte 1 bit 7 = 1 (Apply succeeding CVM field if this CVM is unsuccessful)
• Byte 1 bit 6-1= 000001 (Plaintext PIN verification performed by ICC)
• Byte 2 = '03' (If terminal supports the CVM type) — this method is used if it is supported by the terminal. Otherwise, go to the next method.

CVM 4: 4203 (Enciphered PIN verified online) —​ the fourth method, enciphered online PIN. Conditions of use:

• Byte 1 bit 8 = 0 (default value)
• Byte 1 bit 7 = 1 (Apply succeeding CVM field if this CVM is unsuccessful)
• Byte 1 bit 6-1= 000010 (Enciphered PIN verified online)
• Byte 2= '03' (If terminal supports the CVM type) —​ this method is used if it is supported by the terminal. Otherwise, go to the next method.

CVM 5: 1E03 (Signature (paper)) — ​the fifth method, holder’s handwritten signature on the cheque. Conditions of use:

• Byte 1 bit 8 = 0 (default value)
• Byte 1 bit 7 = 0 (Fail Cardholder Verification if this CVM is unsuccessful))
• Byte 1 bit 6-1= 011110 (Signature (paper))
• Byte 2 = '03' (If terminal supports the CVM type) —​ this method is used if it is supported by the terminal. Otherwise, the cardholder verification procedure will be deemed failed.

Its working mechanism is as follows. The terminal analyzes the card’s CVM List and compares it with the second byte of its object 9F33 (Terminal Capabilities), following which the mutually supported method of verification is to be selected.

Issuer Action Codes

Another object present in the record is Issuer Action Codes (IAC).

IAC object consists of three blocks: IAC-Default, IAC-Denial and IAC-Online. Each one of those blocks determines the conditions under which the transaction will be approved or declined off-line or sent to the issuer for authorization. It should be mentioned that the configuration of the terminal includes its own TAC (Terminal Action Codes) objects, terminal action codes the structure of which is exactly the same as the IAC. During the transaction, those objects are compared to each other as follows:

IAC-Denial — TAC-Denial

IAC-Online — TAC-Online

IAC-Default — TAC-Default

Based on the analysis, the result will be generated. As it was mentioned before, there are three options: approve offline (this is only valid for the terminals that support offline processing), decline offline, or send to the issuer for authorization. The procedure is called Terminal Risk Management (TRM). Note that this is mandatory for our example, because byte 1 bit 4 of the above-mentioned AIP object = 1; therefore, TRM procedure is to be completed.

Let us look into all three IAC blocks, one after another.

IAC-Denial, Tag 9F0E: 0000080000

• Byte 1 bit 8 = 0 Do not decline if Offline data authentication was not performed: do not decline if ODA was not performed.
• Byte 1 bit 7 = 0 Do not decline if Offline static data authentication failed: do not decline if SDA fails.
• Byte 1 bit 6 = 0 Do not decline if ICC data missing: do not decline if the chip misses some data.
• Byte 1 bit 5 = 0 Do not decline if Card appears on terminal exception file (in essence, stop files are not currently in use in the terminals).
• Byte 1 bit 4 = 0 Do not decline if Offline dynamic data authentication failed: do not decline if DDA fails.
• Byte 1 bit 3 = 0 Do not decline if Combined DDA/AC Generation failed: do not decline if CDA fails.
• Byte 1 bit 2 = 0 Do not decline if SDA selected: do not decline if SDA is selected.
• Byte 1 bit 1 = 0 RFU
• Byte 2 bit 8 = 0 Do not decline if ICC and terminal have different application versions: do not decline if the application versions on the card and on the terminal are different.
• Byte 2 bit 7 = 0 Do not decline if Expired application: do not decline if the application’s validity term is expired.
• Byte 2 bit 6 = 0 Do not decline if Application not yet effective: do not decline if the application is not yet effective.
• Byte 2 bit 5 = 0 Do not decline if Requested service not allowed for card product: do not decline if the requested transaction is not permitted for the card.
• Byte 2 bit 4 = 0 Do not decline if New card: do not decline if this is a new card.

Bits 3 to 1 of the second byte: RFU.

• Byte 3 bit 8 = 0 Do not decline if Cardholder verification was not successful: do not decline if the verification of the cardholder was not successful.
• Byte 3 bit 7 = 0 Do not decline if Unrecognised CVM: do not decline if CVM is unknown.
• Byte 3 bit 6 = 0 Do not decline if PIN Try Limit exceeded: do not decline if the PIN code entry attempts limit is exceeded.
• Byte 3 bit 5 = 0 Do not decline if PIN entry required and PIN pad not present or not working: do not decline if the PIN was requested, but the PIN pad is missing or unserviceable.
• Byte 3 bit 4 = 1 Decline if PIN entry required, PIN pad present, but PIN was not entered: decline if the PIN was requested, but not entered.
• Byte 3 bit 3 = 0 Do not decline if Online PIN entered: do not decline if the online PIN is entered.

Bits 2 to 1 of the third byte: RFU.

• Byte 4 bit 8 = 0 Do not decline if Transaction exceeds floor limit: do not decline if the permissible offline transactions limit is exceeded.
• Byte 4 bit 7 = 0 Do not decline if Lower consecutive offline limit exceeded: do not decline if the lower consecutive offline transactions limit is exceeded (this is only valid for the terminals that support offline approval).
• Byte 4 bit 6 = 0 Do not decline if Upper consecutive offline limit exceeded: do not decline if the upper consecutive offline transactions limit is exceeded (this is only valid for the terminals that support offline approval).
• Byte 4 bit 5 = 0 Do not decline if Transaction selected randomly for online processing: do not decline if the transaction is selected for online authorization (this is only valid for the terminals that support offline approval).
• Byte 4 bit 4 = 0 Do not decline if Merchant forced transaction online: do not decline if the transaction is forced to go online (this is only valid for the terminals that support offline approval).

Bits 3 to 1 of the fourth byte: RFU.

• Byte 5 bit 8 = 0 Do not decline if Default TDOL used: do not decline if TDOL is used by default.
• Byte 5 bit 7 = 0 Do not decline if Issuer authentication was unsuccessful.
• Byte 5 bit 6 = 0 Do not decline if Script processing failed before final GENERATE AC: do not decline if the critical issuer scripts processing procedure fails.
• Byte 5 bit 5 = 0 Do not decline if Script processing failed after final GENERATE AC: do not decline if the non-critical issuer scripts processing procedure fails.

Bits 4 to 1 of the fifth byte: RFU.

This example makes it clear that IAC-Denial block contains the description of the conditions under any of which the transaction will be declined offline without attempt to send to the issuer for authorization. In our case, there is only one such condition: the transaction will be declined if the PIN code is not entered.

Furthermore, if the card has no IAC-Denial, the terminal will deem that all of its bits = 0, i.e., there is no condition under which the transaction is to be declined offline.

IAC-Online, Tag 9F0F: BC70BC9800

• Byte 1 bit 8 = 1 Go online if Offline data authentication was not performed: go online if ODA was not performed.
• Byte 1 bit 7 = 0 Do not go online if Offline static data authentication failed: do not go online if SDA fails.
• Byte 1 bit 6 = 1 Go online if ICC data missing: go online if the chip misses some data.
• Byte 1 bit 5 = 1 Go online if Card appears on terminal exception file (in essence, stop files are not currently in use in the terminals).
• Byte 1 bit 4 = 1 Go online if Offline dynamic data authentication failed: go online if DDA fails.
• Byte 1 bit 3 = 1 Go online if Combined DDA/AC Generation failed: go online if CDA fails.
• Byte 1 bit 2 = 0 Do not go online if SDA is selected.
• Byte 1 bit 1 = 0 RFU
• Byte 2 bit 8 = 0 Do not go online if ICC and terminal have different application versions: do not go online if the application versions on the card and on the terminal are different.
• Byte 2 bit 7 = 1 Go online if Expired application: go online if the application’s validity term is expired.
• Byte 2 bit 6 = 1 Go online if Application not yet effective: go online if the application is not yet effective.
• Byte 2 bit 5 = 1 Go online if Requested service not allowed for card product: go online if the requested transaction is not permitted for the card.
• Byte 2 bit 4 = 0 Do not go online if New card: do not go online if this is a new card.

Bits 3 to 1 of the second byte: RFU.

• Byte 3 bit 8 = 1 Go online if Cardholder verification was not successful: go online if the verification of the cardholder was not successful.
• Byte 3 bit 7 = 0 Do not go online if Unrecognised CVM: do not go online if CVM is unknown.
• Byte 3 bit 6 = 1 Go online if PIN Try Limit exceeded: go online if the PIN code entry attempts limit is exceeded.
• Byte 3 bit 5 = 1 Go online if PIN entry required and PIN pad not present or not working: go online if the PIN was requested, but the PIN pad is missing or unserviceable.
• Byte 3 bit 4 = 1 Go online if PIN entry required, PIN pad present, but PIN was not entered: go online if the PIN was requested, but not entered.
• Byte 3 bit 3 = 1 Go online if Online PIN entered: go online if the online PIN was entered.

Bits 2 to 1 of the third byte: RFU.

• Byte 4 bit 8 = 1 Go online if Transaction exceeds floor limit: go online if the permissible offline transactions limit is exceeded.
• Byte 4 bit 7 = 0 Do not go online if Lower consecutive offline limit exceeded: do not go online if the lower consecutive offline transactions limit is exceeded (this is only valid for the terminals that support offline approval).
• Byte 4 bit 6 = 0 Do not go online if Upper consecutive offline limit exceeded: do not go online if the upper consecutive offline transactions limit is exceeded (this is only valid for the terminals that support offline approval).
• Byte 4 bit 5 = 1 Go online if Transaction selected randomly for online processing: go online if the transaction is selected for online authorization (this is only valid for the terminals that support offline approval).
• Byte 4 bit 4 = 1 Go online if Merchant forced transaction online: go online, if the transaction is forced to go online (excuse the tautologism, but such are the conditions. This is only valid for the terminals that support offline approval).

Bits 3 to 1 of the fourth byte: RFU.

• Byte 5 bit 8 = 0 Do not go online if Default TDOL used: do not go online if TDOL is used by default.
• Byte 5 bit 7 = 0 Do not go online if Issuer authentication was unsuccessful.
• Byte 5 bit 6 = 0 Do not go online if Script processing failed before final GENERATE AC: do not go online if the critical issuer scripts processing procedure fails.
• Byte 5 bit 5 = 0 Do not go online if Script processing failed after final GENERATE AC: do not go online if the non-critical issuer scripts processing procedure fails.

Bits 4 to 1 of the fifth byte: RFU.

This example makes it clear that IAC-Online block contains the description of the conditions under any of which the transaction has to be sent to the issuer for authorization.

In this case, if the card has no IAC-Online, the terminal will deem that all of its bits = 1, i.e., the transaction has to go online in any event.

IAC-Default, Tag 9F0D: B450848000

• Byte 1 bit 8 = 1 Reject if unable to process online and if Offline data authentication was not performed: decline if the online processing is impossible and if ODA was not performed.
• Byte 1 bit 7 = 0 Do not reject if unable to process online and if Offline static data authentication failed: do not decline if the online processing is impossible and if SDA fails.
• Byte 1 bit 6 = 1 Reject if unable to process online and if ICC data missing: decline if the online processing is impossible and if the chip misses some critical data.
• Byte 1 bit 5 = 1 Reject if unable to process online and if Card appears on terminal exception file: decline if the online processing is impossible and if the card appears on terminal exception file (in essence, stop files are not currently in use in the terminals).
• Byte 1 bit 4 = 0 Do not reject if unable to process online and if Offline dynamic data authentication failed: do not decline if the online processing is impossible and if DDA fails.
• Byte 1 bit 3 = 1 Reject if unable to process online and if Combined DDA/AC Generation failed: decline if the online processing is impossible and if CDA fails.
• Byte 1 bit 2 = 0 Do not reject if unable to process online and if SDA selected: do not decline if the online processing is impossible, and if SDA method is selected.
• Byte 1 bit 1 = 0 RFU
• Byte 2 bit 8 = 0 Do not reject if unable to process online and if ICC and terminal have different application versions: do not decline if the online processing is impossible and if the application versions on the card and on the terminal are different.
• Byte 2 bit 7 = 1 Reject if unable to process online and if Expired application: decline if the online processing is impossible, and if the card application’s validity term is expired.
• Byte 2 bit 6 = 0 Do not reject if unable to process online and if Application not yet effective: do not decline if the online processing is impossible and if the application is not yet effective.
• Byte 2 bit 5 = 1 Reject if unable to process online and if Requested service not allowed for card product: decline if the online processing is impossible and if the requested transaction is not permitted for the card.
• Byte 2 bit 4 = 0 Do not reject if unable to process online and if New card: do not decline if the online processing is impossible, and if this is a new card.

Bits 3 to 1 of the second byte: RFU.

• Byte 3 bit 8 = 1 Reject if unable to process online and if Cardholder verification was not successful: decline if the online processing is impossible, and if the cardholder verification procedure was not successful.
• Byte 3 bit 7 = 0 Do not reject if unable to process online and if Unrecognised CVM: do not decline if the online processing is impossible, and if CVM is unknown.
• Byte 3 bit 6 = 0 Do not reject if unable to process online and if PIN Try Limit exceeded: do not decline if the online processing is impossible, and if the PIN code entry attempts limit is exceeded.
• Byte 3 bit 5 = 0 Do not decline if PIN entry required and PIN pad not present or not working: do not decline if the PIN was requested, but the PIN pad is missing or unserviceable.
• Byte 3 bit 4 = 0 Do not reject if unable to process online and if PIN entry required, PIN pad present, but PIN was not entered: do not decline if the online processing is impossible and if the PIN was requested, but not entered.
• Byte 3 bit 3 = 1 Reject if unable to process online and if Online PIN entered: decline if the online processing is impossible and if online PIN was entered.

Bits 2 to 1 of the third byte: RFU.

• Byte 4 bit 8 = 1 Reject if unable to process online and if Transaction exceeds floor limit: decline if the online processing is impossible and if the permissible offline transactions limit is exceeded.
• Byte 4 bit 7 = 0 Do not reject if unable to process online and if Lower consecutive offline limit exceeded: do not decline if the online processing is impossible and if the lower consecutive offline transactions limit is exceeded (this is only valid for the terminals that support offline approval).
• Byte 4 bit 6 = 0 Do not reject if unable to process online and if Upper consecutive offline limit exceeded: do not decline if the online processing is impossible and if the upper consecutive offline transactions limit is exceeded (this is only valid for the terminals that support offline approval).
• Byte 4 bit 5 = 0 Do not reject if unable to process online and if Transaction selected randomly for online processing: do not decline if the online processing is impossible and if transaction is selected for online authorization (this is only valid for the terminals that support offline approval).
• Byte 4 bit 4 = 0 Do not reject if unable to process online and if Merchant forced transaction online: do not decline if the online processing is impossible, and if the online transaction is forced (this is only valid for the terminals that support offline approval).

Bits 4 to 1 of the fourth byte: RFU.

• Byte 5 bit 8 = 0 Do not reject if unable to process online and if Default TDOL used: do not decline if the online processing is impossible, and if TDOL was used by default.
• Byte 5 bit 7 = 0 Do not reject if unable to process online and if Issuer authentication was unsuccessful: do not decline if the online processing is impossible, and if issuer authentication was unsuccessful.
• Byte 5 bit 6 = 0 Do not reject if unable to process online and if Script processing failed before final GENERATE AC: do not decline if the online processing is impossible and if the critical issuer scripts processing procedure fails.
• Byte 5 bit 5 = 0 Do not reject if unable to process online and if Script processing failed after final GENERATE AC: do not decline if the online processing is impossible and if the non-critical issuer scripts processing procedure fails.

Bits 4 to 1 of the fifth byte: RFU.

This example makes it clear that IAC-Default block contains the description of the scenarios for the terminals, which (temporarily or permanently) cannot perform online authorization. Under any of the above-mentioned conditions, the transaction will be declined.

Furthermore, if the card has no IAC-Default, the terminal will deem that all of its bits = 1, i.e., for the terminals that have no online exchange capability, all conditions = «decline».

It is necessary to mention that the terminal will record the results of TACs-IACs analysis in the TVR object, which is also a part of the cryptogram generation (again, TVR will be described in detail in the next articles on «EMV Transaction Flow»).

Hence, in connection with the command to Read Records, the terminal has received the important data of the card, such as CDOLs, CVM List, IACs, etc. All of them will be used during the further exchange. Which will be the subject of our future articles.

See you next time!

Our Payment Solutions