PCI Watch

Tracking changes across the Payment Card Industry

Book 3 – Application Specification

v4.4 Specifications
Contact Acceptance Device

EMV® Integrated Circuit Card Specifications for Payment Systems Book 3 Application Specification Version 4.4 October 2022

Specification The EMV® Specifications are provided “AS IS” without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in these Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT, AS TO THESE SPECIFICATIONS. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to determine whether any implementation of these Specifications may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of these Specifications should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, the Specifications may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement these Specifications is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party’s infringement of any intellectual property rights in connection with these Specifications. October 2022

Specification Revision Log – Version 4.4 The following changes have been made to Book 3 since the publication of Version 4.3. Numbering and cross references in this version have been updated to reflect changes introduced by the published bulletins. Incorporated changes described in the following Specification Bulletins: Specification Bulletin no. 113: SDA selected TVR bit Specification Bulletin no. 117, Second Edition: Order of Data Elements in Templates Specification Bulletin no. 118: Clarification on the Definition of Payment System Specification Bulletin no. 120: Reserve AIP Bits for Contactless Specification Bulletin no. 140: Clarification on the Format of AFL, Byte 1 Specification Bulletin no. 141: Clarification on Random Transaction Selection Specification Bulletin no. 147: Clarification on the Format of Exponent Data Elements Specification Bulletin no. 159: Incorrectly Formatted ICC Data Objects Specification Bulletin no. 161: Reserve TVR and AIP Bits for Contactless Specification Bulletin no. 163: Changes to PIN Pad requirements Specification Bulletin no. 164: Electronic Signature Capture and Electronic Receipt Delivery Specification Bulletin no. 175: Application Selection Registered Proprietary Data Specification Bulletin no. 178, Third Edition: Tokenisation Data Objects – Payment Account Reference (PAR) Specification Bulletin no. 185, Second Edition: Biometric Terminal Specification Specification Bulletin no. 197: Tokenisation Data Objects – Token Requestor ID and Last 4 Digits of PAN Specification Bulletin no. 209: Clarifications for EMV® Book 3 (Version 4.3), offline-only terminals processing Specification Bulletin no. 231: Issuer Identification Number Extended (IINE) Specification Bulletin no. 234: Data Object Lists (DOLs) and Constructed Data Objects Specification Bulletin no. 243: Introduction of XDA/ODE for EMV Specifications Specification Bulletin no. 260: Terminal Risk Management Clarification October 2022

Specification Specification Bulletin no. 267: Clarification on Handling of Unknown ICC Data and Track 1 Discretionary Data Specification Bulletin no. 273: Clarification on Setting TSI bit for CDA (Mode 1 and 2) Transaction Minor editorial clarifications and corrections, including those described in the following: Specification Bulletin no. 175: Application Selection Registered Proprietary Data Specification Bulletin no. 243: Introduction of XDA/ODE for EMV Specifications October 2022

Specification Part I – General Contents 1 Scope 14 1.1 Changes in Version 4.4 14 1.2 Structure 14 1.3 Underlying Standards 15 1.4 Audience 15 2 Normative References 16 3 Definitions 19 4 Abbreviations, Notations, Conventions, and Terminology 27 4.1 Abbreviations 27 4.2 Notations 34 4.3 Data Element Format Conventions 36 4.4 Terminology 37 Part II – Data Elements and Commands 5 Data Elements and Files 39 5.1 Data Elements Associated with Financial Transaction Interchange 39 5.2 Data Objects 40 5.2.1 Classes of Data Objects 40 5.3 Files 41 5.3.1 Application Elementary Files 41 5.3.2 File Referencing 41 5.4 Rules for Using a Data Object List (DOL) 42 6 Commands for Financial Transaction 44 6.1 Command APDU Format 44 6.2 Response APDU Format 44 6.3 Coding Conventions 45 6.3.1 Coding of the Class Byte 45 6.3.2 Coding of the Instruction Byte 46 6.3.3 Coding of Parameter Bytes 46 6.3.4 Coding of Data Field Bytes 47 6.3.5 Coding of the Status Bytes 47 6.3.6 Coding of RFU Data 50 6.4 Logical Channels 50 October 2022

Specification 6.5 Commands 51 6.5.1 APPLICATION BLOCK Command-Response APDUs 52 6.5.2 APPLICATION UNBLOCK Command-Response APDUs 53 6.5.3 CARD BLOCK Command-Response APDUs 54 6.5.4 EXTERNAL AUTHENTICATE Command-Response APDUs 55 6.5.5 GENERATE APPLICATION CRYPTOGRAM Command-Response APDUs 56 6.5.6 GET CHALLENGE Command-Response APDUs 60 6.5.7 GET DATA Command-Response APDUs 61 6.5.8 GET PROCESSING OPTIONS Command-Response APDUs 62 6.5.9 INTERNAL AUTHENTICATE Command-Response APDUs 64 6.5.10 PIN CHANGE/UNBLOCK Command-Response APDUs 66 6.5.11 READ RECORD Command-Response APDUs 69 6.5.12 VERIFY Command-Response APDUs 71 6.5.13 Command Chaining 75 Part III – Debit and Credit Application Specification 7 Files for Financial Transaction Interchange 77 7.1 Mapping Data Objects 77 7.2 Mandatory Data Objects 78 7.3 Data Retrievable by GET DATA Command 80 7.4 Data Retrievable by GET PROCESSING OPTIONS 80 7.5 Erroneous or Missing Data in the ICC 81 8 Transaction Flow 84 8.1 Exception Handling 84 8.2 Example Flowchart 84 8.3 Additional Functions 86 9 GENERATE AC Command Coding 87 9.1 Command Parameters 89 9.2 Command Data 89 9.2.1 Card Risk Management Data 89 9.2.2 Transaction Certificate Data 90 9.3 Command Use 90 9.3.1 GENERATE AC (First Issuance) 91 9.3.2 GENERATE AC (Second Issuance) 91 10 Functions Used in Transaction Processing 92 10.1 Initiate Application Processing 92 10.2 Read Application Data 94 10.3 Offline Data Authentication 96 October 2022

Specification 10.4 Processing Restrictions 100 10.4.1 Application Version Number 100 10.4.2 Application Usage Control 100 10.4.3 Application Effective/Expiration Dates Checking 101 10.5 Cardholder Verification 102 10.5.1 Offline PIN Processing 105 10.5.2 Online PIN Processing 106 10.5.3 Signature Processing 106 10.5.4 Combination CVMs 106 10.5.5 CVM Processing Logic 106 10.5.6 Offline Biometric Verification Processing 115 10.5.7 Online Biometric Verification Processing 117 10.6 Terminal Risk Management 118 10.6.1 Floor Limits 119 10.6.2 Random Transaction Selection 119 10.6.3 Velocity Checking 121 10.7 Terminal Action Analysis 122 10.8 Card Action Analysis 127 10.8.1 Terminal Messages for an AAC 127 10.8.2 Advice Messages 128 10.9 Online Processing 129 10.10 Issuer-to-Card Script Processing 131 10.11 Completion 133 Part IV – Annexes Annex A Data Elements Dictionary 135 A1 Data Elements by Name 135 A2 Data Elements by Tag 162 Annex B Rules for BER-TLV Data Objects 168 B1 Coding of the Tag Field of BER-TLV Data Objects 169 B2 Coding of the Length Field of BER-TLV Data Objects 171 B3 Coding of the Value Field of Data Objects 171 Annex C Coding of Data Elements Used in Transaction Processing 172 C1 Application Interchange Profile 173 C2 Application Usage Control 174 C3 Cardholder Verification Rule Format 175 October 2022

Specification C4 Issuer Code Table Index 178 C5 Terminal Verification Results 179 C6 Transaction Status Information 182 C7 Biometric Information Template (BIT) 183 C8 BIT Group Template 188 Annex D Transaction Log Information 190 D1 Purpose 190 D2 Conditions of Execution 190 D3 Sequence of Execution 190 D4 Description 191 D5 Example 192 Annex E TVR and TSI Bit Settings Following Script Processing 193 E1 Scenarios 193 E2 Additional Information 194 Annex F Status Words Returned in EXTERNAL AUTHENTICATE 195 Annex G Account Type 196 Part V – Common Core

Definitions

Common Core Definitions 198 Changed and Added Sections 198 6 Commands for Financial Transaction 199 6.2 Response APDU Format 199 6.5 Commands 199 6.5.4 EXTERNAL AUTHENTICATE Command-Response APDUs 199 6.5.5 GENERATE APPLICATION CRYPTOGRAM Command-Response APDUs 199 6.5.8 GET PROCESSING OPTIONS Command-Response APDUs 201 6.5.9 INTERNAL AUTHENTICATE Command-Response APDUs 201 7 Files for Financial Transaction Interchange 202 7.3 Data Retrievable by GET DATA Command 202 9 GENERATE AC Command Coding 203 9.2 Command Data 203 9.2.2 Transaction Certificate Data 203 October 2022

Specification 9.2.3 Common Core Definitions Card Verification Results 203 9.3 Command Use 212 10 Functions Used in Transaction Processing 213 10.5 Cardholder Verification 213 10.5.1 Offline PIN Processing 213 10.8 Card Action Analysis 213 10.8.1 Terminal Messages for an AAC 213 10.8.2 Advice Messages 213 10.10 Issuer-to-Card Script Processing 213 10.11 Completion 213 10.11.1 Additional Completion Actions for a CCD-Compliant Application 213 Annex A Data Elements Dictionary 218 Annex C Coding of Data Elements Used in Transaction Processing 220 C9 Issuer Application Data for a CCD-Compliant Application 220 C9.1 Common Core Identifier 220 C9.2 Issuer Application Data for Format Code 'A' 221 C9.3 Card Verification Results 222 C10 Card Status Update for a CCD-Compliant Application 224 Annex D Transaction Log Information 226 Index 227 October 2022

Specification Tables Table 1: Structure of SFI 42 Table 2: Most Significant Nibble of the Class Byte 45 Table 3: Coding of the Instruction Byte 46 Table 4: Coding of Status Bytes SW1 SW2 48 Table 5: Allocation of Status Bytes 49 Table 6: APPLICATION BLOCK Command Message 52 Table 7: APPLICATION UNBLOCK Command Message 53 Table 8: CARD BLOCK Command Message 54 Table 9: EXTERNAL AUTHENTICATE Command Message 55 Table 10: GENERATE AC Cryptogram Types 56 Table 11: GENERATE AC Command Message 56 Table 12: GENERATE AC Reference Control Parameter 57 Table 13: Format 1 GENERATE AC Response Message Data Field 57 Table 14: Format 2 GENERATE AC Response Message Data Field 58 Table 15: Coding of Cryptogram Information Data 59 Table 16: GET CHALLENGE Command Message 60 Table 17: GET DATA Command Message 61 Table 18: GET PROCESSING OPTIONS Command Message 62 Table 19: INTERNAL AUTHENTICATE Command Message 64 Table 20: PIN CHANGE/UNBLOCK Command Message 67 Table 21: READ RECORD Command Message 69 Table 22: READ RECORD Command Reference Control Parameter 69 Table 23: VERIFY Command Message 71 Table 24: VERIFY Command Qualifier of Reference Data (P2) 72 Table 25: Plaintext Offline PIN Block Format 73 Table 26: Values of CLA in Command Chaining 75 Table 27: Data Objects Used by the Offline Data Authentication Algorithm 78 Table 28: Mandatory Data Objects 78 Table 29: Data Required for SDA 79 Table 30: Data Required for DDA and/or CDA 79 Table 31: Data Required for XDA 79 Table 32: Data Objects Retrievable by GET DATA Command 80 Table 33: Data Retrievable by GET PROCESSING OPTIONS 80 Table 34: Proposed Terminal Behaviours when Format Errors Detected for Selected Data Elements 82 Table 35: ICC Data Missing Indicator Setting 83 Table 36: Terminal Action Regarding Application Usage Control 101 Table 37: Data Elements Dictionary 135 Table 38: Data Elements Tags 162 Table 39: Tag Field Structure (First Byte) BER-TLV 169 Table 40: Tag Field Structure (Subsequent Bytes) BER-TLV 169 Table 41: Application Interchange Profile 173 Table 42: Application Usage Control 174 Table 43: CVM Codes 175 Table 44: CVM Condition Codes 177 October 2022

Specification Table 45: Issuer Code Table Index 178 Table 46: Terminal Verification Results 179 Table 47: Transaction Status Information 182 Table 48: Biometric Information Template (BIT) 184 Table 49: Biometric Type 186 Table 50: Biometric Subtype 187 Table 51: Card BIT Group Template 188 Table 52: Terminal BIT Group Template 189 Table 53: Log Entry 191 Table 54: Example of Log Format 192 Table 55: Terminal Action after (First) EXTERNAL AUTHENTICATE Response 195 Table 56: Account Type 196 Table CCD 1: Body of Response APDU Structure 199 Table CCD 2: Format 2 GENERATE AC Response Message Data Field 200 Table CCD 3: Coding of Cryptogram Information Data 200 Table CCD 4: Format 2 GET PROCESSING OPTIONS Response Message Data Field 201 Table CCD 5: Format 2 Internal Authenticate Response Message Data Field 201 Table CCD 6: Data Elements Not Used by a CCD-Compliant Application 218 Table CCD 7: Additional Data Elements Defined for CCD 219 Table CCD 8: Common Core Identifier 220 Table CCD 9: Issuer Application Data for Format Code 'A' 221 Table CCD 10: Card Verification Results for Format Code 'A' 222 Table CCD 11: Card Status Update for Cryptogram Versions '5' and '6' 224 October 2022

Specification Figures Figure 1: Command APDU Structure 44 Figure 2: Response APDU Structure 44 Figure 3: Structural Scheme of Status Bytes 47 Figure 4: Format 1 GET PROCESSING OPTIONS Response Message Data Field 63 Figure 5: READ RECORD Response Message Data Field 70 Figure 6: Transaction Flow Example 85 Figure 7: Use of GENERATE AC Options (no ODA, SDA, DDA) 88 Figure 8: CVM Processing (Part 1 of 7) 107 Figure 9: CVM Processing (Part 2 of 7) 109 Figure 10: CVM Processing (Part 3 of 7) 110 Figure 11: CVM Processing (Part 4 of 7) 111 Figure 12: CVM Processing (Part 5 of 7) 112 Figure 13: CVM Processing (Part 6 of 7) 113 Figure 14: CVM Processing (Part 7 of 7) 114 Figure 15: Random Transaction Selection Example 120 Figure 16: Issuer Script Format 131 Figure 17: Issuer Script Command Format (Shown with Three Commands) 131 Figure 18: Primitive BER-TLV Data Object (Data Element) 171 Figure 19: Constructed BER-TLV Data Object 171 October 2022

Specification Part I General October 2022

Specification 1

Scope

This document, the Integrated Circuit Card Specifications for Payment Systems – Book 3, Application Specification defines the terminal and integrated circuit card (ICC) procedures necessary to effect a payment system transaction in an international interchange environment. The Integrated Circuit Card Specifications for Payment Systems includes the following additional documents, all available on http://www.emvco.com:

  • Book 1 – Application Independent ICC to Terminal Interface Requirements
  • Book 2 – Security and Key Management
  • Book 4 – Cardholder, Attendant, and Acquirer Interface Requirements 1.1 Changes in Version 4.4 This release incorporates all relevant Specification Bulletins, Application Notes, amendments, etc. published up to the date of this release. The Revision Log at the beginning of the Book provides additional detail about changes to this specification.

1.2 Structure Book 3 consists of the following parts: Part I Part II Part III Part IV Part V – General – Data Elements and Commands – Debit and Credit Application Specification – Annexes – Common Core Definitions Part I includes this introduction, as well as data applicable to all Books: normative references, definitions, abbreviations, notations, data element format convention, and terminology. Part II describes data elements and files as well as commands for financial transaction. October 2022

Specification 1 Scope 1.3 Underlying Standards Part III specifies the debit and credit application functions including:

  • Transaction flow (the sequence of events and the commands issued to the card)
  • Exception processing
  • Definition of data elements and commands as they apply to the exchange of information between an ICC and a terminal. In particular,  Structure and referencing of files  The usage of commands between the ICC and the terminal to achieve application level functions. The functions described are those necessary to ensure that payment system cards conforming to this specification can perform a set of core functions in terminals conforming to this specification. Application functions unique to individual payment systems and those functions not performed in interchange are not described, but are not precluded. Part IV includes a complete data elements dictionary, rules for BER-TLV data objects, instructions for coding of specific data elements, and transaction log information. It discusses TVR and TSI bit settings following script processing, and Status Words returned in response to an EXTERNAL AUTHENTICATE command. Part V defines an optional extension to be used when implementing a card complying to the Common Core Definitions (CCD). The Book also includes a revision log and an index. This specification does not address clearing and settlement or any transactions where the ICC is not present.

1.3 Underlying Standards This specification is based on the ISO/IEC 7816 series of standards and should be read in conjunction with those standards. However, if any of the provisions or definitions in this specification differ from those standards, the provisions herein shall take precedence.

1.4 Audience This specification is intended for use by manufacturers of ICCs and terminals, system designers in payment systems, and financial institution staff responsible for implementing financial applications in ICCs. October 2022

Specification 2 Normative

References

The following specifications and standards contain provisions that are referenced in these specifications. The latest version shall apply unless a publication date is explicitly stated. EMV Contact Interface Specification EMV Tokenisation Framework FIPS 202 IEEE P1363 ISO 639-1 ISO 3166 ISO 4217 ISO/IEC 7812-1 ISO/IEC 7813 ISO/IEC 7816-4 ISO/IEC 7816-5 ISO/IEC 7816-6 EMV Level 1 Specifications for Payment Systems, EMV Contact Interface Specification EMV Payment Tokenisation Specification – Technical Framework Framework specification for an interoperable Payment Tokenisation solution. SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions Standard Specifications For Public-Key Cryptography Codes for the representation of names of languages – Part 1: Alpha-2 Code Note: This standard is updated continuously by ISO. Additions/changes to ISO 639-1:1988: Codes for the Representation of Names of Languages are available on: http://www.loc.gov/standards/iso639-2/php/code_changes.php Codes for the representation of names of countries and their subdivisions Codes for the representation of currencies and funds Identification cards – Identification of issuers — Part 1: Numbering System Identification cards – Financial transaction cards Identification cards — Integrated circuit cards — Part 4: Organization, security and commands for interchange Identification cards — Integrated circuit cards — Part 5: Registration of application providers Identification cards – Integrated circuit cards – Part 6: Interindustry data elements for interchange October 2022

Specification 2 Normative References ISO/IEC 7816-11 ISO 8583:1987 ISO 8583:1993 ISO/IEC 8825-1 ISO/IEC 8859 ISO 9362 ISO 9564-1 ISO/IEC 9796-2 ISO/IEC 9797-1 ISO/IEC 9797-2 ISO/IEC 10116 ISO/IEC 10118-3 ISO/IEC 11770-6 ISO 13616 Identification cards – Integrated circuit cards – Personal verification through biometric methods Bank card originated messages – Interchange message specifications – Content for financial transactions Financial transaction card originated messages – Interchange message specifications Information technology – ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) Information processing – 8-bit single-byte coded graphic character sets Banking – Banking telecommunication messages – Bank identifier codes Financial services – Personal Identification Number (PIN) management and security – Part 1: Basic principles and requirements for PINs in card-based systems Information technology – Security techniques – Digital signature schemes giving message recovery – Part 2: Integer factorization based mechanisms Information technology – Security techniques – Message Authentication Codes – Part 1: Mechanisms using a block cipher Information technology – Security techniques – Message Authentication Codes (MACs) – Part 2: Mechanisms using a dedicated hash-function Information technology – Security techniques – Modes of operation for an n-bit block cipher Information technology – Security techniques – Hash-functions – Part 3: Dedicated hash-functions Information technology – Security techniques – Key management — Part 6: Key derivation Banking and related financial services – International bank account number (IBAN) October 2022

Specification ISO/IEC 14888-3 ISO/IEC 15946-1 ISO/IEC 15946-5 ISO 16609 ISO/IEC 18031 ISO/IEC 18033-2 ISO/IEC 18033-3 ISO/IEC 19772 ISO/IEC 19785-3 ISO/IEC 19794 ISO/IEC 19794-2 SEC 1 2 Normative References Information technology – Security techniques – Digital signatures with appendix — Part 3: Discrete logarithm based mechanisms Information technology – Security techniques – Cryptographic techniques based on elliptic curves — Part 1: General Information technology – Security techniques – Cryptographic techniques based on elliptic curves — Part 5: Elliptic curve generation Banking – Requirements for message authentication using symmetric techniques Information technology – Security techniques – Random bit generation Information technology – Security techniques – Encryption algorithms – Part 2: Asymmetric ciphers Information technology – Security techniques – Encryption algorithms – Part 3: Block ciphers Information technology – Security techniques – Authenticated encryption Information technology – Common Biometric Exchange Formats Framework – Patron format specifications Information technology – Biometric data interchange formats Information technology – Biometric data interchange formats – Part 2: Finger minutiae data Elliptic Curve Cryptography (available at http://www.secg.org) October 2022

Specification 3 Definitions The following terms are used in one or more books of these specifications. Application Application Authentication Cryptogram Application Cryptogram Authentication Authorisation Request Cryptogram Authorisation Response Cryptogram Biometric Data Block The application protocol between the card and the terminal and its related set of data. An Application Cryptogram generated by the card when declining a transaction. A cryptogram generated by the card in response to a GENERATE AC command. See also:

  • Application Authentication Cryptogram
  • Authorisation Request Cryptogram
  • Transaction Certificate The provision of assurance of the claimed identity of an entity or of data origin. An Application Cryptogram generated by the card when requesting online authorisation. A cryptogram generated by the issuer in response to an Authorisation Request Cryptogram. A block of data with a specific format that contains information captured from a biometric capture device and that could be used as follows:
  • stored in the card as part of the biometric reference template
  • sent to the ICC in the data field of the PIN CHANGE/UNBLOCK command
  • sent to the ICC in the data field of the VERIFY command for offline biometric verification
  • sent online for verification The format of the BDB is outside the scope of this specification. October 2022 Specification 3 Definitions Biometric Reference Template Biometric data stored in the card as reference. Data provided by a biometric capture device would be compared against the biometric reference template to determine a match. Biometric Verification The process of determining that the biometrics presented, such as finger, palm, iris, voice, or facial, are valid. Byte 8 bits. Card A payment card as defined by a payment system. Certificate The public key and identity of an entity together with some other information, rendered unforgeable by signing with the private key of the certification authority which issued that certificate. Certification Authority Trusted third party that establishes a proof that links a public key and other relevant information to its owner. Ciphertext Enciphered information. Combined DDA/Application Cryptogram Generation A form of offline dynamic data authentication. Command A message sent by the terminal to the ICC that initiates an action and solicits a response from the ICC. Command Chaining A mechanism where consecutive command-response pairs can be chained. Compromise The breaching of secrecy or security. Concatenation Two elements are concatenated by appending the bytes from the second element to the end of the first. Bytes from each element are represented in the resulting string in the same sequence in which they were presented to the terminal by the ICC, that is, most significant byte first. Within each byte bits are ordered from most significant bit to least significant. A list of elements or objects may be concatenated by concatenating the first pair to form a new element, using that as the first element to concatenate with the next in the list, and so on. October 2022 Specification 3 Definitions Contact Cryptogram Cryptographic Algorithm Data Integrity Decipherment DEM1 Digital Signature Dynamic Data Authentication Elliptic Curve Cryptography Encipherment Exclusive-OR Extended Data Authentication Facial Verification Financial Transaction A conducting element ensuring galvanic continuity between integrated circuit(s) and external interfacing equipment. Result of a cryptographic operation. An algorithm that transforms data in order to hide or reveal its information content. The property that data has not been altered or destroyed in an unauthorised manner. The reversal of a corresponding encipherment. A family of data encapsulation mechanisms defined in ISO/IEC 18033-2. An asymmetric cryptographic transformation of data that allows the recipient of the data to prove the origin and integrity of the data, and protect the sender and the recipient of the data against forgery by third parties, and the sender against forgery by the recipient. A form of offline dynamic data authentication Public key cryptography based on the algebraic structure of elliptic curves over finite fields. The reversible transformation of data by a cryptographic algorithm to produce ciphertext. Binary addition with no carry, giving the following values: 0 + 0 = 0 0 + 1 = 1 1 + 0 = 1 1 + 1 = 0 A form of offline dynamic data authentication. The process of determining that the face presented is valid. The act between a cardholder and a merchant or acquirer that results in the exchange of goods or services against payment. October 2022 Specification 3 Definitions Finger Verification Function Hash Function Hash Result I2OSP Integrated Circuit(s) Integrated Circuit(s) Card Interface Device Iris Verification Issuer Action Code The process of determining that the finger presented is valid. A process accomplished by one or more commands and resultant actions that are used to perform all or part of a transaction. A function that maps strings of bits to fixed-length strings of bits, satisfying the following two properties:
  • It is computationally infeasible to find for a given output an input which maps to this output.
  • It is computationally infeasible to find for a given input a second input that maps to the same output. Additionally, if the hash function is required to be collision-resistant, it must also satisfy the following property:
  • It is computationally infeasible to find any two distinct inputs that map to the same output. The string of bits that is the output of a hash function. An integer to octet string conversion primitive function defined in ISO/IEC 18033-2. Electronic component(s) designed to perform processing and/or memory functions. A card into which one or more integrated circuits are inserted to perform processing and memory functions. That part of a terminal into which the ICC is inserted, including such mechanical and electrical devices as may be considered part of it. The process of determining that the iris presented is valid. Any of the following, which reflect the issuer-selected action to be taken upon analysis of the TVR:
  • Issuer Action Code – Default
  • Issuer Action Code – Denial
  • Issuer Action Code – Online October 2022 Specification 3 Definitions Kernel Key Key

Introduction

Key Withdrawal Keypad Library Logical Compromise Magnetic Stripe Message Message Authentication Code Nibble Offline Data Encipherment Padding Palm Verification The set of functions required to be present on every terminal implementing a specific interpreter. The kernel contains device drivers, interface routines, security and control functions, and the software for translating from the virtual machine language to the language used by the real machine. In other words, the kernel is the implementation of the virtual machine on a specific real machine. A sequence of symbols that controls the operation of a cryptographic transformation. The process of generating, distributing, and beginning use of a key pair. The process of removing a key from service as part of its revocation. Arrangement of numeric, command, and, where required, function and/or alphanumeric keys laid out in a specific manner. A set of high-level software functions with a published interface, providing general support for terminal programs and/or applications. The compromise of a key through application of improved cryptanalytic techniques, increases in computing power, or combination of the two. The stripe containing magnetically encoded information. A string of bytes sent by the terminal to the card or vice versa, excluding transmission-control characters. A symmetric cryptographic transformation of data that protects the sender and the recipient of the data against forgery by third parties. The four most significant or least significant bits of a byte. Offline encipherment of data, in particular for cardholder PIN and biometric data. See Book 2. Appending extra bits to either side of a data string. The process of determining that the palm presented is valid. October 2022

Specification 3 Definitions Path Payment System Environment Physical Compromise PIN Pad Plaintext Potential Compromise Private Key Public Key Public Key Certificate Response RSA-KEM RSATransform Concatenation of file identifiers without delimitation. A logical construct within the ICC, the entry point to which is a Directory Definition File (DDF) named '1PAY.SYS.DDF01'. This DDF contains a Payment System Directory which in turn contains entries for one or more Application Definition Files (ADFs) which are formatted according to this specification. The compromise of a key resulting from the fact that it has not been securely guarded, or a hardware security module has been stolen or accessed by unauthorised persons. Arrangement of numeric and command keys to be used for personal identification number (PIN) entry. Also known as a “PIN Entry Device” (PED). Unenciphered information. A condition where cryptanalytic techniques and/or computing power has advanced to the point that compromise of a key of a certain length is feasible or even likely. That key of an entity’s asymmetric key pair that should only be used by that entity. In the case of a digital signature scheme, the private key defines the signature function. That key of an entity’s asymmetric key pair that can be made public. In the case of a digital signature scheme, the public key defines the verification function. The public key information of an entity signed by the certification authority and thereby rendered unforgeable. A message returned by the ICC to the terminal after the processing of a command message received by the ICC. A family of key encapsulation mechanisms defined in ISO/IEC 18033-2. The RSA exponentiation that is used for encryption and decryption, and generating and verifying a signature. October 2022

Specification 3 Definitions Script A command or a string of commands transmitted by the issuer to the terminal for the purpose of being sent serially to the ICC as commands. Secret Key A key used with symmetric cryptographic techniques and usable only by a set of specified entities. Socket An execution vector defined at a particular point in an application and assigned a unique number for reference. Static Data Authentication Offline static data authentication Symmetric Cryptographic Technique A cryptographic technique that uses the same secret key for both the originator’s and recipient’s transformation. Without knowledge of the secret key, it is computationally infeasible to compute either the originator’s or the recipient’s transformation. Template Value field of a constructed data object, defined to give a logical grouping of data objects. Terminal The device used in conjunction with the ICC at the point of transaction to perform a financial transaction. The terminal incorporates the interface device and may also include other components and interfaces such as host communications. Terminal Action Code Any of the following, which reflect the acquirer-selected action to be taken upon analysis of the TVR:

  • Terminal Action Code – Default
  • Terminal Action Code – Denial
  • Terminal Action Code – Online Terminate Card Session End the card session by deactivating the IFD contacts according to EMV Contact Interface Specification and displaying a message indicating that the ICC cannot be used to complete the transaction. Terminate Transaction Stop the current application and deactivate the card. Transaction An action taken by a terminal at the user’s request. For a POS terminal, a transaction might be payment for goods, etc. A transaction selects among one or more applications as part of its processing flow. October 2022 Specification 3 Definitions Transaction Certificate An Application Cryptogram generated by the card when accepting a transaction. Virtual Machine A theoretical microprocessor architecture that forms the basis for writing application programs in a specific interpreter software implementation. Voice Verification The process of determining that the voice presented is valid. October 2022 Specification 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations a Alphabetic (see section 4.3, Data Element Format Conventions) AAC Application Authentication Cryptogram AAD Additional Authenticated Data AC Application Cryptogram ADF Application Definition File AEF Application Elementary File AES Advanced Encryption Standard AFL Application File Locator AID Application Identifier AIP Application Interchange Profile an Alphanumeric (see section 4.3) ans Alphanumeric Special (see section 4.3) APDU Application Protocol Data Unit API Application Program Interface ARC Authorisation Response Code ARPC Authorisation Response Cryptogram ARQC Authorisation Request Cryptogram ASI Application Selection Indicator ASN Abstract Syntax Notation ATC Application Transaction Counter ATM Automated Teller Machine ATR Answer to Reset October 2022 Specification 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations AUC b BCD BDB BEK BER BHT BIC BIT BMK CA CAD C-APDU CBC CBEFF CCD CCI CCYYMMDD CDA CDOL CID CLA cn CPU CRL CSU CV CV Rule Application Usage Control Binary (see section 4.3) Binary Coded Decimal Biometric Data Block Biometric Encryption Key Basic Encoding Rules (defined in ISO/IEC 8825-1) Biometric Header Template Bank Identifier Code Biometric Information Template Biometric MAC Key Certification Authority Card Accepting Device Command APDU Cipher Block Chaining Common Biometric Exchange Formats Framework Common Core Definitions Common Core Identifier Year (4 digits), Month, Day Combined DDA/Application Cryptogram Generation Card Risk Management Data Object List Cryptogram Information Data Class Byte of the Command Message Compressed Numeric (see section 4.3) Central Processing Unit Certificate Revocation List Card Status Update Cryptogram Version Cardholder Verification Rule October 2022 Specification 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations CVM CVR DDA DDF DDOL DES DF DIR DOL ECB EC-SDSA ECC EF EN FC FCI Hex HHMMSS HMAC I/O IAC IAD IBAN IC ICC ICCD IEC IFD Cardholder Verification Method Card Verification Results Dynamic Data Authentication Directory Definition File Dynamic Data Authentication Data Object List Data Encryption Standard Dedicated File Directory Data Object List Electronic Code Book Elliptic Curve Schnorr Digital Signature Algorithm Elliptic Curve Cryptography Elementary File European Norm Format Code File Control Information Hexadecimal Hours, Minutes, Seconds Keyed-hash Message Authentication Code Input/Output Issuer Action Code (Denial, Default, Online) Issuer Application Data International Bank Account Number Integrated Circuit Integrated Circuit(s) Card Issuer Certified Card Data International Electrotechnical Commission Interface Device October 2022 Specification 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations IIN IINE INS ISO KD KDF KM KS L l.s. Lc LCOL LDD Le Lr LRC M m.s. MAC max. MF MK MMDD MMYY n NCA NF Issuer Identification Number Issuer Identification Number Extended Instruction Byte of Command Message International Organization for Standardization Key Derivation Key Derivation Function Master Key Session Key Length Least Significant Exact Length of Data Sent by the TAL in a Case 3 or 4 Command Lower Consecutive Offline Limit Length of the ICC Dynamic Data Maximum Length of Data Expected by the TAL in Response to a Case 2 or 4 Command Length of Response Data Field Longitudinal Redundancy Check Mandatory Most Significant Message Authentication Code Maximum Master File ICC Master Key for session key generation Month, Day Month, Year Numeric (see section 4.3) Length of the Certification Authority Public Key Modulus Norme Française October 2022 Specification 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations NFIELD NHASH NI NIC NIST NPE NSIG O O/S ODA ODE P1 P2 PAN PAR PC PCA PDOL PI PIC PIN PIX POS pos. PSE R-APDU RFU RID Length of a finite field element Output length of a hash function Length of the Issuer Public Key Modulus Length of the ICC Public Key Modulus National Institute for Standards and Technology Length of the ICC PIN Encipherment Public Key Modulus Length of an ECC Digital Signature Optional Operating System Offline Data Authentication Offline Data Encipherment Parameter 1 Parameter 2 Primary Account Number Payment Account Reference Personal Computer Certification Authority Public Key Processing Options Data Object List Issuer Public Key ICC Public Key Personal Identification Number Proprietary Application Identifier Extension Point of Service Position Payment System Environment Response APDU Reserved for Future Use Registered Application Provider Identifier October 2022 Specification 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations RSA SCA SDA SDAD SFI SHA-1 SHA-2 SHA-256 SHA-3 SI SIC SK SW1 SW2 TAA TAC TAL TC TDOL TLV TPDU TSI TVR UCOL UL UN var. XDA Rivest, Shamir, Adleman Algorithm Certification Authority Private Key Static Data Authentication Signed Dynamic Application Data Short File Identifier Secure Hash Algorithm 1 Secure Hash Algorithm 2 (includes SHA-256 and SHA-512) Secure Hash Algorithm 256 Secure Hash Algorithm 3 Issuer Private Key ICC Private Key Session Key Status Byte One Status Byte Two Terminal Action Analysis Terminal Action Code(s) (Default, Denial, Online) Terminal Application Layer Transaction Certificate Transaction Certificate Data Object List Tag Length Value Transport Protocol Data Unit Transaction Status Information Terminal Verification Results Upper Consecutive Offline Limit Underwriters Laboratories Incorporated Unpredictable Number Variable (see section 4.3) Extended Data Authentication October 2022 Specification 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations YYMM YYMMDD Year, Month Year, Month, Day October 2022 Specification 4 Abbreviations, Notations, Conventions, and Terminology 4.2 Notations 4.2 Notations '0' to '9' and 'A' to 'F' 16 hexadecimal characters xx Any value A:= B A is assigned the value of B A = B Value of A is equal to the value of B A ≡ B mod n Integers A and B are congruent modulo the integer n, that is, there exists an integer d such that (A – B) = dn A mod n The reduction of the integer A modulo the integer n, that is, the unique integer r, 0 ≤ r < n, for which there exists an integer d such that A = dn + r A / n The integer division of A by n, that is, the unique integer d for which there exists an integer r, 0 ≤ r < n, such that A = dn + r Y:= ALG(K)[X] Encipherment of a data block X with a block cipher as specified in Book 2 section A1, using a secret key K X = ALG-1(K)[Y] Decipherment of a data block Y with a block cipher as specified in Book 2 section A1, using a secret key K Y:= Sign (SK)[X] The signing of a data block X with an asymmetric reversible algorithm as specified in Book 2 section A2, using the private key SK X = Recover(PK)[Y] The recovery of the data block X with an asymmetric reversible algorithm as specified in Book 2 section A2, using the public key PK C:= (A || B) The concatenation of an n-bit number A and an m-bit number B, which is defined as C = 2m A + B. Leftmost Applies to a sequence of bits, bytes, or digits and used interchangeably with the term “most significant”. If C = (A || B) as above, then A is the leftmost n bits of C. October 2022 Specification 4 Abbreviations, Notations, Conventions, and Terminology 4.2 Notations Rightmost H:= Hash[MSG] X ⊕ Y MIN (x, y) Applies to a sequence of bits, bytes, or digits and used interchangeably with the term “least significant”. If C = (A || B) as above, then B is the rightmost m bits of C. Hashing of a message MSG of arbitrary length using a 160-bit hash function The symbol '⊕' denotes bit-wise exclusive-OR and is defined as follows: X ⊕ Y The bit-wise exclusive-OR of the data blocks X and Y. If one data block is shorter than the other, then it is first padded to the left with sufficient binary zeros to make it the same length as the other. The smaller of values x and y. October 2022 Specification 4 Abbreviations, Notations, Conventions, and Terminology 4.3 Data Element Format Conventions 4.3 Data Element Format Conventions The EMV specifications use the following data element formats: a Alphabetic data elements contain a single character per byte. The permitted characters are alphabetic only (a to z and A to Z, upper and lower case). an Alphanumeric data elements contain a single character per byte. The permitted characters are alphabetic (a to z and A to Z, upper and lower case) and numeric (0 to 9). There is one exception: The permitted characters for Payment Account Reference are alphabetic upper case (A to Z) and numeric (0 to 9). ans Alphanumeric Special data elements contain a single character per byte. The permitted characters and their coding are shown in the Common Character Set table in Book 4 Annex B. There is one exception: The permitted characters for Application Preferred Name are the non-control characters defined in the ISO/IEC 8859 part designated in the Issuer Code Table Index associated with the Application Preferred Name. b These data elements consist of either unsigned binary numbers or bit combinations that are defined elsewhere in the specification. Binary example: The Application Transaction Counter (ATC) is defined as “b” with a length of two bytes. An ATC value of 19 is stored as Hex '00 13'. Bit combination example: Processing Options Data Object List (PDOL) is defined as “b” with the format shown in Book 3 section 5.4. cn Compressed numeric data elements consist of two numeric digits (having values in the range Hex '0'–'9') per byte. These data elements are left justified and padded with trailing hexadecimal 'F's. Example: The Application Primary Account Number (PAN) is defined as “cn” with a length of up to ten bytes. A value of 1234567890123 may be stored in the Application PAN as Hex '12 34 56 78 90 12 3F FF' with a length of 8. n Numeric data elements consist of two numeric digits (having values in the range Hex '0' – '9') per byte. These digits are right justified and padded with leading hexadecimal zeroes. Other specifications sometimes refer to this data format as Binary Coded Decimal (“BCD”) or unsigned packed. Example: Amount, Authorised (Numeric) is defined as “n 12” with a length of six bytes. A value of 12345 is stored in Amount, Authorised (Numeric) as Hex '00 00 00 01 23 45'. var. Variable data elements are variable length and may contain any bit combination. Additional information on the formats of specific variable data elements is available elsewhere. October 2022 Specification 4 Abbreviations, Notations, Conventions, and Terminology 4.4 Terminology 4.4 Terminology business agreement An agreement reached between a payment system and its business partner(s). proprietary Not defined in this specification and/or outside the scope of this specification shall Denotes a mandatory requirement should Denotes a recommendation October 2022 Specification Part II Data Elements and Commands October 2022 Specification 5 Data Elements and Files An application in the Integrated Circuit Card (ICC) includes a set of items of information. These items of information may be accessible to the terminal after a successful application selection (see Book 1 section 12). An item of information is called a data element. A data element is the smallest piece of information that may be identified by a name, a description of logical content, a format, and a coding.

5.1 Data Elements Associated with Financial Transaction Interchange The data elements dictionary defined in Annex A includes those data elements that may be used for financial transaction interchange. Data elements not specified in Annex A are outside the scope of these specifications. Any additional data element transmitted in the response to the SELECT command (for example, O/S Manufacturer proprietary data) is placed in the field “FCI Issuer Discretionary Data” (tag 'BF0C'). October 2022

Specification 5 Data Elements and Files 5.2 Data Objects 5.2 Data Objects A data object consists of a tag, a length, and a value. A tag uniquely identifies a data object within the environment of an application. The length is the length of the value field of the data object. The value field of a data object may consist of either a single data element or one or more data objects. When a data object encapsulates a single data element, it is called a primitive data object. When a data object encapsulates one or more data objects, it is called a constructed data object. Specific tags are assigned to the constructed data objects with a specific meaning in the environment of an application according to this specification. The value field of such constructed data objects is a context-specific template. Rules for the coding of context-specific data objects and templates are given in Annex B. Upon receipt, the terminal shall parse all the data elements following the rules described in Annex B. The retrieved value fields of the data elements shall be stored in the terminal buffer for possible later use in the application. The actual order of tagged data elements within templates encountered by the terminal may differ from that described in the Specifications. The terminal shall not treat different ordering of data elements as an error. The terminal shall be capable of correctly interpreting Tag Length Value (TLV) data objects with a length field coded '00' as defined in ISO/IEC 7816. This situation can occur when a data element is personalised on a card without an actual value field. A data element with length '00' shall be treated as not present. The data element length indicated in Annex A reflects the length of the data elements when actually present on the card. Annex A describes the mapping of data elements onto data objects and the mapping of data objects into templates when applicable. Records are templates containing one or more primitive and/or constructed data objects. The mapping of data objects into records is left to the discretion of the issuer. The manner in which data elements are to be used is described in Part III. Annex B defines the tags that are reserved by this specification for EMVCo, the payment systems, and issuers. All ICC applications conforming to this specification shall comply with this coding and allocation scheme in accordance with ISO/IEC 7816-6.

5.2.1 Classes of Data Objects Identification and coding of different classes of data objects are defined in Annex B. The tag definitions specified in that annex are according to ISO/IEC 8825 and the ISO/IEC 7816 series and apply to applications conforming to this specification. October 2022

Specification 5 Data Elements and Files 5.3 Files 5.3 Files The data objects contained in data files accessible from the ICC are stored in records. The file structure and referencing method depend on the purpose of the file. The following sections describe structures and referencing methods. The layout of the data files accessible from the ICC is left to the discretion of the issuer except for the directory files described in the following section.

5.3.1 Application Elementary Files An Application Elementary File (AEF) in the range 1-10, contains one or more primitive Basic Encoding Rules – TLV (BER-TLV) data objects grouped into constructed BER-TLV data objects (records) according to Annex B. After selecting the application, an AEF in the range 1-10 is referred to only by its SFI as described in section 5.3.2.2. A data file referred to in this specification consists of a sequence of records addressed by record number. The data files referred to by SFIs in the range 1-10 contain only data not interpreted by the card, that is, data that is not used by the card in its internal processes. This file structure is defined as linear. It can be either linear fixed or linear variable according to ISO/IEC 7816-4. The choice is left to the issuer and does not affect the reading of the file according to this specification.

5.3.2 File Referencing A file may be referred to by a name or a SFI depending on its type.

5.3.2.1 Referencing by Name Any Application Definition File (ADF) or Directory Definition File (DDF) in the card is referenced by its Dedicated File (DF) name. A DF name for an ADF corresponds to the Application Identifier (AID) or contains the AID as the beginning of the DF name. Each DF name shall be unique within a given card. October 2022

Specification 5 Data Elements and Files 5.4 Rules for Using a Data Object List (DOL) 5.3.2.2 Referencing by SFI SFIs are used for the selection of AEFs. Any AEF within a given application is referenced by a SFI coded on 5 bits in the range 1 to 30. The coding of the SFI is described in every command that uses it. Table 1 describes the assignment of SFIs for an EMV application: Value 1-10 11-20 21-30 Meaning Governed by this specification Payment system-specific Issuer-specific Table 1: Structure of SFI An SFI shall be unique within an application. The coding of SFIs within the range 1 to 10 is used to address AEFs governed by this specification.

5.4 Rules for Using a Data Object List (DOL) In several instances, the terminal is asked to build a flexible list of data elements to be passed to the card under the card’s direction. To minimise processing within the ICC, such a list is not TLV encoded but is a single constructed field built by concatenating several data elements together. Since the elements of the constructed field are not TLV encoded, it is imperative that the ICC knows the format of this field when the data is received. This is achieved by including a Data Object List (DOL) in the ICC, specifying the format of the data to be included in the constructed field. DOLs currently used in this specification include:

  • The Processing Options Data Object List (PDOL) used with the GET PROCESSING OPTIONS command Note: An ICC supporting XDA or ECC ODE may use PDOL to obtain Terminal Capabilities (tag '9F33') to determine whether the terminal supports XDA.
  • The Card Risk Management Data Object Lists (CDOL1 and CDOL2) used with the GENERATE APPLICATION CRYPTOGRAM (AC) command
  • The Transaction Certificate Data Object List (TDOL) used to generate a TC Hash Value
  • The Dynamic Data Authentication Data Object List (DDOL) used with the INTERNAL AUTHENTICATE command This section describes the rules for constructing a field using a DOL supplied by the card. October 2022 Specification 5 Data Elements and Files 5.4 Rules for Using a Data Object List (DOL) A DOL is a concatenated list of entries, with each entry representing a single data element to be included in the constructed field. The format of each entry is a one- or twobyte tag identifying the desired data object, followed by a one-byte length which represents the number of bytes the field shall occupy in the command data. Only tags representing primitive data objects constructed according to Annex B shall be used in DOLs. Primitive data objects contained within terminal sourced constructed data objects cannot be requested using DOLs. The terminal shall complete the following steps to build the constructed field: 1. Read the DOL from the ICC. 2. Concatenate all data elements listed in the DOL. The following rules apply to this concatenation:
  • If the tag of any data object identified in the DOL is unknown to the terminal or represents a constructed data object, the terminal shall provide a data element with the length specified and a value of all hexadecimal zeroes.
  • If a data object is in the list and is meaningful to the terminal but represents optional static data that is absent from the terminal, the portion of the command field representing the data object shall be filled with hexadecimal zeroes.
  • If the length specified in the DOL entry is less than the length of the actual data object, the leftmost bytes of the data element shall be truncated if the data object has numeric (n) format,1 or the rightmost bytes of the data shall be truncated for any other format.
  • If the length specified in the DOL entry is greater than the length of the actual data, the actual data shall be padded:  with leading hexadecimal zeroes if the data has numeric format  with trailing hexadecimal 'FF's if the data has compressed numeric (cn 1) format  with trailing hexadecimal zeroes for any other format (an, ans, or b including bit combination data)1
  • If a data object is in the list and is meaningful to the terminal but represents data that is not applicable to the current transaction, the portion of the command field representing the data object shall be filled with hexadecimal zeroes. The completed list of data elements shall be concatenated in the sequence in which the corresponding data objects appear in the DOL. 1 See section 4.3, Data Element Format Convention. October 2022 Specification 6 Commands for Financial Transaction 6.1 Command APDU Format The command Application Protocol Data Unit (APDU) consists of a mandatory header of four bytes followed by a conditional body of variable length, as shown in Figure 1: CLA INS P1 P2 ← Mandatory Header 2 → Lc ← Data Conditional Body Le → Figure 1: Command APDU Structure The number of data bytes sent in the command APDU (C-APDU) is denoted by Lc (length of command data field). The maximum number of data bytes expected in the response APDU is denoted by length of expected data (Le). When Le is present and contains the value zero, the maximum number of available data bytes (up to 256) is expected. When required in a command message, Le shall always be set to '00'.

6.2 Response APDU Format The response APDU format consists of a conditional body of variable length followed by a mandatory trailer of two bytes, as shown in Figure 2: Data SW1 SW2 ← Body → ← Trailer → Figure 2: Response APDU Structure The data field of a response APDU is an object structured as defined in Annex B. The detailed coding of the objects is provided with the commands described in subsequent sub-clauses. 2 CLA = Class Byte of the Command Message INS = Instruction Byte of Command Message P1 = Parameter 1 P2 = Parameter 2 October 2022

Specification 6 Commands for Financial Transaction 6.3 Coding Conventions 6.3 Coding Conventions This section defines the coding of the header and the body of the messages (command and response).

6.3.1 Coding of the Class Byte The most significant nibble of the class byte indicates the type of command as shown in Table 2: Hex '0' '8' Any other value Meaning Inter-industry command Proprietary to this specification Outside the scope of this specification Table 2: Most Significant Nibble of the Class Byte A command proprietary to this specification is introduced by the most significant nibble of the class byte set to 8; in other words, the structure of the command and response messages is according to ISO/IEC 7816-4, and the coding of the messages is defined within the context of these specifications. The least significant nibble of the class byte indicates secure messaging and logical channel mechanisms, according to ISO/IEC 7816-4. October 2022

Specification 6 Commands for Financial Transaction 6.3 Coding Conventions 6.3.2 Coding of the Instruction Byte The INS byte of a command is structured according to EMV Contact Interface Specification. Table 3 indicates the coding of INS and its relationship to CLA: CLA '8x' '8x' '8x' '0x' '8x' '0x' '8x' '8x' '0x' '8x' '0x' '0x' '0x' '8x' '8x' '9x' 'Ex' INS Meaning '1E' APPLICATION BLOCK '18' APPLICATION UNBLOCK '16' CARD BLOCK '82' EXTERNAL AUTHENTICATE 'AE' GENERATE APPLICATION CRYPTOGRAM '84' GET CHALLENGE 'CA' GET DATA 'A8' GET PROCESSING OPTIONS '88' INTERNAL AUTHENTICATE '24' PERSONAL IDENTIFICATION NUMBER (PIN) CHANGE/UNBLOCK 'B2' READ RECORD 'A4' SELECT '20' VERIFY 'Dx' RFU for the payment systems 'Ex' RFU for the payment systems 'xx' RFU for manufacturers for proprietary INS coding 'xx' RFU for issuers for proprietary INS coding Table 3: Codin

Shown in part. Read the original for the full text.