PCI Watch

Tracking changes across the Payment Card Industry

Book 4 – Cardholder, Attendant, and Acquirer Interface Requirements

v4.3 Specifications
Contact Acceptance DeviceCard

EMV Integrated Circuit Card Specifications for Payment Systems Book 4 Cardholder, Attendant, and Acquirer Interface Requirements Version 4.3 November 2011

EMV®* Integrated Circuit Card Specifications for Payment Systems Book 4 Cardholder, Attendant, and Acquirer Interface Requirements Version 4.3 November 2011 * EMV is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere. The EMV trademark is owned by EMVCo.

EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements © 2011 EMVCo, LLC (“EMVCo”). All rights reserved. Any and all uses of these Specifications are subject to the terms and conditions of the EMVCo Terms of Use agreement available at www.emvco.com. These 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 NONINFRINGEMENT, 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.

November 2011

EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements Revision Log

  • Version 4.3 The following changes have been made to Book 4 since the publication of Version 4.2. 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 Updates: Specification Update Bulletin no. 70 Third Edition: Selectable Kernel Configurations Specification Update Bulletin no. 71 Second Edition: Change the status of the ‘Presence’ of the Application Label data element in the FCI of an ADF to mandatory Specification Update Bulletin no. 72: DDA support in terminals Incorporated changes described in the following Specification Bulletins: Specification Bulletin no. 76: Language Selection Specification Bulletin no. 78: Removal of DDF Entries from PSE Records Specification Bulletin no. 79: Amount Requested in the PDOL Specification Bulletin no. 82: Various Terminal Updates Specification Bulletin no. 85: CVM Results after a CVM Failure Specification Bulletin no. 88: Application Selection Updates Minor editorial clarifications, including those described in the following Specification Bulletin: Specification Bulletin no. 80: Editorial Errors in Version 4.2 of the EMV Specifications November 2011 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements Part I
  • General Contents 1 Scope 3 1.1 Changes in Version 4.3 3 1.2 Structure 3 1.3 Underlying Standards 5 1.4 Audience 5 2 Normative References 7 3 Definitions 11 4 Abbreviations, Notations, Conventions, and Terminology 21 4.1 Abbreviations 21 4.2 Notations 29 4.3 Data Element Format Conventions 31 4.4 Terminology 33 Part II
  • General Requirements 5 Terminal Types and Capabilities 37 5.1 Terminal Types 37 5.2 Terminal Capabilities 38 5.3 Terminal Configurations 39 6 Functional Requirements 43 6.1 Application Independent ICC to Terminal Interface Requirements 43 6.2 Security and Key Management 43 6.3 Application Specification 43 6.3.1 Initiate Application Processing 44 6.3.2 Offline Data Authentication 44 6.3.3 Processing Restrictions 45 6.3.4 Cardholder Verification Processing 45 6.3.5 Terminal Risk Management 51 6.3.6 Terminal Action Analysis 51 6.3.7 Card Action Analysis 52 6.3.8 Online Processing 53 6.3.9 Issuer-to-Card Script Processing 53 6.4 Conditions for Support of Functions 54 6.5 Other Functional Requirements 55 November 2011 Page v EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 6.5.1 Amount Entry and Management 55 6.5.2 Voice Referrals 55 6.5.3 Transaction Forced Online 56 6.5.4 Transaction Forced Acceptance 56 6.5.5 Transaction Sequence Counter 57 6.5.6 Unpredictable Number 57 6.6 Card Reading 57 6.6.1 IC Reader 58 6.6.2 Exception Handling 58 6.7 Date Management 59 6.7.1 Data Authentication 59 6.7.2 Processing Restrictions 59 6.7.3 Date Management 59 7 Physical Characteristics 61 7.1 Keypad 61 7.1.1 Command Keys 62 7.1.2 PIN Pad 63 7.2 Display 64 7.3 Memory Protection 64 7.4 Clock 64 7.5 Printer 65 7.6 Magnetic Stripe Reader 65 Part III
  • Software Architecture 8 Terminal Software Architecture 69 8.1 Environmental Changes 69 8.2 Application Libraries 70 8.3 Application Program Interface 71 8.4 Interpreter 72 8.4.1 Concept 72 8.4.2 Virtual Machine 73 8.4.3 Kernel 73 8.4.4 Application Code Portability 73 8.5 Plugs and Sockets 74 9 Software Management 77 10 Data Management 79 10.1 Application Independent Data 79 10.1.1 Terminal Related Data 80 November 2011 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 10.1.2 Transaction Related Data 80 10.2 Application Dependent Data 81 Part IV
  • Cardholder, Attendant, and Acquirer Interface 11 Cardholder and Attendant Interface 87 11.1 Language Selection 87 11.2 Standard Messages 88 11.3 Application Selection 91 11.4 Receipt 92 12 Acquirer Interface 93 12.1 Message Content 93 12.1.1 Authorisation Request 95 12.1.2 Financial Transaction Request 97 12.1.3 Authorisation or Financial Transaction Response 99 12.1.4 Financial Transaction Confirmation 100 12.1.5 Batch Data Capture 101 12.1.6 Reconciliation 103 12.1.7 Online Advice 104 12.1.8 Reversal 106 12.2 Exception Handling 108 12.2.1 Unable to Go Online 108 12.2.2 Downgraded Authorisation 109 12.2.3 Authorisation Response Incidents 110 12.2.4 Script Incidents 111 12.2.5 Advice Incidents 111 Part V
  • Annexes Annex A Coding of Terminal Data Elements 115 A1 Terminal Type 115 A2 Terminal Capabilities 116 A3 Additional Terminal Capabilities 118 A4 CVM Results 121 A5 Issuer Script Results 121 A6 Authorisation Response Code 122 November 2011 Annex B Common Character Set EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 123 Annex C Example Data Element Conversion 125 Annex D Informative Terminal Guidelines 129 D1 Terminal Usage 129 D2 Power Supply 129 D2.1 External Power Supply 129 D2.2 Battery Requirements 129 D3 Keypad 130 D4 Display 130 D5 Informative References 130 Annex E Examples of Terminals 133 E1 Example 1
  • POS Terminal or Electronic Cash Register 134 E2 Example 2
  • ATM 135 E3 Example 3
  • Vending Machine 136 Index 137 November 2011 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements Tables Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table 1: Terms Describing Terminal Types 37 2: Setting of CVM Results, TVR bits and TSI bits following CVM Processing 49 3: Card Action Analysis 52 4: Key Types 61 5: Command Keys 62 6: Command Key Colours 62 7: Application Dependent Data Elements 81 8: Standard Messages 89 9: ICC-specific Authorisation Request Data Elements 95 10: Existing Authorisation Request Data Elements 96 11: ICC-specific Financial Transaction Request Data Elements 97 12: Existing Financial Transaction Request Data Elements 98 13: ICC-specific Authorisation or Financial Transaction Response Data Elements 99 14: Existing Authorisation or Financial Transaction Response Data Elements 99 15: ICC-specific Financial Transaction Confirmation Data Elements 100 16: Existing Financial Transaction Confirmation Data Elements 100 17: ICC-specific Batch Data Capture Data Elements 101 18: Existing Batch Data Capture Data Elements 102 19: Existing Reconciliation Data Elements 103 20: ICC-specific Online Advice Data Elements 104 21: Existing Online Advice Data Elements 105 22: ICC-specific Reversal Data Elements 106 23: Existing Reversal Data Elements 107 Annexes Table 24: Terminal Type 115 Table 25: Terminal Capabilities Byte 1
  • Card Data Input Capability 116 Table 26: Terminal Capabilities Byte 2
  • CVM Capability 117 Table 27: Terminal Capabilities Byte 3
  • Security Capability 117 Table 28: Add’l Term. Capabilities Byte 1
  • Transaction Type Capability 118 Table 29: Add’l Term. Capabilities Byte 2
  • Transaction Type Capability 119 Table 30: Add’l Term. Capabilities Byte 3
  • Terminal Data Input Capability 119 Table 31: Add’l Term. Capabilities Byte 4
  • Term. Data Output Capability 120 Table 32: Add’l Term. Capabilities Byte 5
  • Term. Data Output Capability 120 Table 33: CVM Results 121 Table 34: Issuer Script Results 121 Table 35: Authorisation Response Codes 122 Table 36: Common Character Set 123 Table 37: Data Element Conversion 125 November 2011 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements Table 38: Example of POS Terminal or Electronic Cash Register 134 Table 39: Example of ATM 135 Table 40: Example of Vending Machine 136 Page x November 2011 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements Figures Figure 1: Example of an Attended Terminal 39 Figure 2: Example of a Merchant Host 40 Figure 3: Example of a Cardholder-Controlled Terminal 41 Figure 4: PIN Pad Layout 63 Figure 5: Terminal Software 70 Figure 6: Socket/Plug Relationship 75 November 2011 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements Part I General November 2011 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 1

Scope

This document, the Integrated Circuit Card Specifications for Payment Systems Book 4, Cardholder, Attendant, and Acquirer Interface Requirements for Payment Systems, defines the mandatory, recommended, and optional terminal requirements necessary to support the acceptance of integrated circuit cards (ICCs) in accordance with the other documents of the Integrated Circuit Card Specifications for Payment Systems, all available on http://www.emvco.com:

  • Book 1 - Application Independent ICC to Terminal Interface Requirements
  • Book 2 - Security and Key Management
  • Book 3 - Application Specification 1.1 Changes in Version 4.3 This release incorporates all relevant Specification Update 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 4 consists of the following parts: Part I - General Part II - General Requirements Part III - Software Architecture Part IV - Cardholder, Attendant, and Acquirer Interface Part V - Annexes 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 addresses:

  • Functional requirements, such as those emerging from the other Books of the Integrated Circuit Card Specifications for Payment Systems
  • General physical characteristics November 2011 1 Scope 1.2 Structure EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements Part III addresses software architecture including software and data management. Part IV discusses:
  • Cardholder and attendant interface
  • Acquirer interface Part V discusses the coding of terminal data elements, lists the common character set, provides an example data element conversion, includes informative terminal guidelines, and provides examples of the physical and functional characteristics of terminals. The Book also includes a revision log and an index. This specification applies to all terminals operating in attended or unattended environments, having offline or online capabilities, and supporting transaction types such as purchase of goods, services, and cash. Terminals include but are not limited to automated teller machines (ATMs), branch terminals, cardholder-activated terminals, electronic cash registers, personal computers, and point of service (POS) terminals. This specification defines the requirements necessary to support the implementation of ICCs. These requirements are in addition to those already defined by individual payment systems and acquirers for terminals that accept magnetic stripe cards. ICC and magnetic stripe acceptance capability may co-exist in the same terminal. It is recognised that different terminal implementations exist depending on business environment and intended usage. This specification defines requirements for those features and functions that are applicable according to the particular operating environment of the terminal. This specification:
  • Does not cover application-specific terminal requirements unique to individual payment systems and those functions not required to support interchange.
  • Does not address cardholder or merchant operating procedures, which are established by individual payment systems.
  • Does not provide sufficient detail to be used as a specification for terminal procurement. Individual payment systems and acquirers will define complementary requirements applicable to different situations that will provide more detailed specifications applicable to terminal implementations. November 2011 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 1 Scope 1.3 Underlying Standards 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. November 2011

EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 2 Normative

References

The following standards contain provisions that are referenced in these specifications. The latest version shall apply unless a publication date is explicitly stated. ISO 639-1 ISO 3166 ISO 4217 ISO/IEC 7811-1 ISO/IEC 7811-3 ISO/IEC 7813 ISO/IEC 7816-1 ISO/IEC 7816-2 ISO/IEC 7816-3 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/iso6392/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 – Recording technique – Part 1: Embossing Identification cards – Recording technique – Part 3: Location of embossed characters on ID-1 cards Identification cards – Financial transaction cards Identification cards – Integrated circuit(s) cards with contacts – Part 1: Physical characteristics Information technology – Identification cards – Integrated circuit(s) cards with contacts – Part 2: Dimensions and location of contacts Identification cards — Integrated circuit cards — Part 3: Cards with contacts — Electrical interface and transmission protocols November 2011

2 Normative References ISO/IEC 7816-4 ISO/IEC 7816-5 ISO/IEC 7816-6 ISO 8583:1987 ISO 8583:1993 ISO/IEC 8825-1 ISO/IEC 8859 ISO 9362 ISO 9564-1:2011 ISO/IEC 9796-2:2010 ISO/IEC 9797-1:2011 ISO/IEC 10116 ISO/IEC 10118-3 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 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 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 – Modes of operation for an n-bit block cipher Information technology – Security techniques – Hash-functions – Part 3: Dedicated hash-functions

November 2011

EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 2 Normative References ISO/IEC 10373 ISO 13491-1 ISO 13616 ISO 16609 ISO/IEC 18031 ISO/IEC 18033-3 Identification cards – Test methods Banking – Secure cryptographic devices (retail) – Part 1: Concepts, requirements and evaluation methods Banking and related financial services – International bank account number (IBAN) Banking – Requirements for message authentication using symmetric techniques Information technology - Security techniques Random bit generation Information technology – Security techniques – Encryption algorithms – Part 3: Block ciphers November 2011

EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 3

Definitions

The following terms are used in one or more books of these specifications. Accelerated Revocation Application Application Authentication Cryptogram Application Cryptogram Authorisation Request Cryptogram Authorisation Response Cryptogram Asymmetric Cryptographic Technique Authentication Block Byte A key revocation performed on a date sooner than the published key expiry date. 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 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 cryptographic technique that uses two related transformations, a public transformation (defined by the public key) and a private transformation (defined by the private key). The two transformations have the property that, given the public transformation, it is computationally infeasible to derive the private transformation. The provision of assurance of the claimed identity of an entity or of data origin. A succession of characters comprising two or three fields defined as prologue field, information field, and epilogue field. 8 bits. November 2011 3 Definitions Card Certificate Certification Authority Ciphertext Cold Reset Combined DDA/Application Cryptogram Generation Command Compromise Concatenation Contact Cryptogram EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements A payment card as defined by a payment system. 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. Trusted third party that establishes a proof that links a public key and other relevant information to its owner. Enciphered information. The reset of the ICC that occurs when the supply voltage (VCC) and other signals to the ICC are raised from the inactive state and the reset (RST) signal is applied. A form of offline dynamic data authentication. A message sent by the terminal to the ICC that initiates an action and solicits a response from the ICC. The breaching of secrecy or security. 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. A conducting element ensuring galvanic continuity between integrated circuit(s) and external interfacing equipment. Result of a cryptographic operation. November 2011 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 3 Definitions Cryptographic Algorithm Data Integrity Deactivation Sequence Decipherment Digital Signature Dynamic Data Authentication Embossing Encipherment Epilogue Field Exclusive-OR Financial Transaction Function 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 deactivation sequence defined in section 6.1.5 of Book 1. The reversal of a corresponding encipherment. 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 Characters raised in relief from the front surface of a card. The reversible transformation of data by a cryptographic algorithm to produce ciphertext. The final field of a block. It contains the error detection code (EDC) byte(s). Binary addition with no carry, giving the following values: 0 + 0 = 0 0 + 1 = 1 1 + 0 = 1 1 + 1 = 0 The act between a cardholder and a merchant or acquirer that results in the exchange of goods or services against payment. A process accomplished by one or more commands and resultant actions that are used to perform all or part of a transaction. November 2011 3 Definitions EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements Guardtime Hash Function Hash Result Inactive Integrated Circuit Module Integrated Circuit(s) Integrated Circuit(s) Card Interface Device Issuer Action Code The minimum time between the trailing edge of the parity bit of a character and the leading edge of the start bit of the following character sent in the same direction. 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. The supply voltage (VCC) and other signals to the ICC are in the inactive state when they are at a potential of 0.4 V or less with respect to ground (GND). The sub–assembly embedded into the ICC comprising the IC, the IC carrier, bonding wires, and contacts. 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. 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 November 2011 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 3 Definitions Kernel Key Key Expiry Date Key

Introduction

Key Life Cycle Key Replacement Key Revocation Key Revocation Date Key Withdrawal Keypad 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 date after which a signature made with a particular key is no longer valid. Issuer certificates signed by the key must expire on or before this date. Keys may be removed from terminals after this date has passed. The process of generating, distributing, and beginning use of a key pair. All phases of key management, from planning and generation, through revocation, destruction, and archiving. The simultaneous revocation of a key and introduction of a key to replaced the revoked one. The key management process of withdrawing a key from service and dealing with the legacy of its use. Key revocation can be as scheduled or accelerated. The date after which no legitimate cards still in use should contain certificates signed by this key, and therefore the date after which this key can be deleted from terminals. For a planned revocation the Key Revocation Date is the same as the key expiry date. 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. November 2011

3 Definitions EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements Library A set of high–level software functions with a published interface, providing general support for terminal programs and/or applications. Logical Compromise The compromise of a key through application of improved cryptanalytic techniques, increases in computing power, or combination of the two. Magnetic Stripe The stripe containing magnetically encoded information. Message A string of bytes sent by the terminal to the card or vice versa, excluding transmission–control characters. Message Authentication Code A symmetric cryptographic transformation of data that protects the sender and the recipient of the data against forgery by third parties. Nibble The four most significant or least significant bits of a byte. Padding Appending extra bits to either side of a data string. Path Concatenation of file identifiers without delimitation. Payment System Environment 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. Physical Compromise 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. PIN Pad Arrangement of numeric and command keys to be used for personal identification number (PIN) entry. Plaintext Unenciphered information. Planned Revocation A key revocation performed as scheduled by the published key expiry date.

November 2011

EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 3 Definitions Potential Compromise Private Key Prologue Field Public Key Public Key Certificate Response Script Secret Key Signal Amplitude Signal Perturbations Socket 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. The first field of a block. It contains subfields for node address (NAD), protocol control byte (PCB), and length (LEN). 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 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. A key used with symmetric cryptographic techniques and usable only by a set of specified entities. The difference between the high and low voltages of a signal. Abnormalities occurring on a signal during normal operation such as undershoot/overshoot, electrical noise, ripple, spikes, crosstalk, etc. Random perturbations introduced from external sources are beyond the scope of this specification. An execution vector defined at a particular point in an application and assigned a unique number for reference. November 2011

3 Definitions EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements State H Voltage high on a signal line. May indicate a logic one or logic zero depending on the logic convention used with the ICC. State L Voltage low on a signal line. May indicate a logic one or logic zero depending on the logic convention used with the ICC. 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. T=0 Character–oriented asynchronous half duplex transmission protocol. T=1 Block–oriented asynchronous half duplex transmission protocol. 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 section 6.1.5 of Book 1, 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. November 2011 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 3 Definitions Transaction Transaction Certificate Virtual Machine Warm Reset 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. An Application Cryptogram generated by the card when accepting a transaction A theoretical microprocessor architecture that forms the basis for writing application programs in a specific interpreter software implementation. The reset that occurs when the reset (RST) signal is applied to the ICC while the clock (CLK) and supply voltage (VCC) lines are maintained in their active state. November 2011 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations µA µm µs a AAC AC ACK ADF AEF AFL AID AIP an ans APDU API ARC ARPC ARQC ASI ASN Microampere Micrometre Microsecond Alphabetic (see section 4.3, Data Element Format Conventions) Application Authentication Cryptogram Application Cryptogram Acknowledgment Application Definition File Application Elementary File Application File Locator Application Identifier Application Interchange Profile Alphanumeric (see section 4.3) Alphanumeric Special (see section 4.3) Application Protocol Data Unit Application Program Interface Authorisation Response Code Authorisation Response Cryptogram Authorisation Request Cryptogram Application Selection Indicator Abstract Syntax Notation November 2011 4 Abbreviations, Notations, Conventions, and Terminology EMV 4.3 Book 4 4.1 Abbreviations Cardholder, Attendant, and Acquirer Interface Requirements ATC ATM ATR AUC b BCD BER BIC BGT BWI BWT C CAD C-APDU CBC CCD CCI CDA CDOL CID CIN CLA CLK cn CPU CRL CSU C-TPDU Application Transaction Counter Automated Teller Machine Answer to Reset Application Usage Control Binary (see section 4.3) Binary Coded Decimal Basic Encoding Rules (defined in ISO/IEC 8825–1) Bank Identifier Code Block Guardtime Block Waiting Time Integer Block Waiting Time Celsius or Centigrade Card Accepting Device Command APDU Cipher Block Chaining Common Core Definitions Common Core Identifier Combined DDA/Application Cryptogram Generation Card Risk Management Data Object List Cryptogram Information Data Input Capacitance Class Byte of the Command Message Clock Compressed Numeric (see section 4.3) Central Processing Unit Certificate Revocation List Card Status Update Command TPDU November 2011 EMV 4.3 Book 4 4 Abbreviations, Notations, Conventions, and Terminology Cardholder, Attendant, and Acquirer 4.1 Abbreviations Interface Requirements CV CVM CVR CV Rule CWI CWT D DAD DC DDA DDF DDOL DES DF DIR DOL ECB EDC EF EN etu f FC FCI GND GP Hex HHMMSS Cryptogram Version Cardholder Verification Method Card Verification Results Cardholder Verification Rule Character Waiting Time Integer Character Waiting Time Bit Rate Adjustment Factor Destination Node Address Direct Current Dynamic Data Authentication Directory Definition File Dynamic Data Authentication Data Object List Data Encryption Standard Dedicated File Directory Data Object List Electronic Code Book Error Detection Code Elementary File European Norm Elementary Time Unit Frequency Format Code File Control Information Ground Grandparent key for session key generation Hexadecimal Hours, Minutes, Seconds November 2011 4 Abbreviations, Notations, Conventions, and Terminology EMV 4.3 Book 4 4.1 Abbreviations Cardholder, Attendant, and Acquirer Interface Requirements I/O IAC IAD IBAN I-block IC ICC ICC IEC IFD IFS IFSC IFSD IFSI IIN IK INF INS IOH IOL ISO IV KM KS L l.s. Lc Input/Output Issuer Action Code (Denial, Default, Online) Issuer Application Data International Bank Account Number Information Block Integrated Circuit Integrated Circuit(s) Card Current drawn from VCC International Electrotechnical Commission Interface Device Information Field Size Information Field Size for the ICC Information Field Size for the Terminal Information Field Size Integer Issuer Identification Number Intermediate Key for session key generation Information Field Instruction Byte of Command Message High Level Output Current Low Level Output Current International Organization for Standardization Initial Vector for session key generation Master Key Session Key Length Least Significant Exact Length of Data Sent by the TAL in a Case 3 or 4 Command November 2011 EMV 4.3 Book 4 4 Abbreviations, Notations, Conventions, and Terminology Cardholder, Attendant, and Acquirer 4.1 Abbreviations Interface Requirements LCOL LDD Le LEN Licc Lr LRC M mΩ m.s. m/s mA MAC max. MF MHz min. MK mm MMDD MMYY N n NAD NAK nAs 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 Exact Length of Data Available or Remaining in the ICC (as Determined by the ICC) to be Returned in Response to the Case 2 or 4 Command Received by the ICC Length of Response Data Field Longitudinal Redundancy Check Mandatory Milliohm Most Significant Meters per Second Milliampere Message Authentication Code Maximum Master File Megahertz Minimum ICC Master Key for session key generation Millimetre Month, Day Month, Year Newton Numeric (see section 4.3) Node Address Negative Acknowledgment Nanoampere–second November 2011 4 Abbreviations, Notations, Conventions, and Terminology EMV 4.3 Book 4 4.1 Abbreviations Cardholder, Attendant, and Acquirer Interface Requirements NCA NF NI NIC NIST NPE ns O O/S P P1 P2 P3 PAN PC PCA PCB PDOL pF PI PIC PIN PIX POS pos. PSE PTS Length of the Certification Authority Public Key Modulus Norme Française 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 Nanosecond Optional Operating System Parent key for session key generation Parameter 1 Parameter 2 Parameter 3 Primary Account Number Personal Computer Certification Authority Public Key Protocol Control Byte Processing Options Data Object List Picofarad Issuer Public Key ICC Public Key Personal Identification Number Proprietary Application Identifier Extension Point of Service Position Payment System Environment Protocol Type Selection November 2011 EMV 4.3 Book 4 4 Abbreviations, Notations, Conventions, and Terminology Cardholder, Attendant, and Acquirer 4.1 Abbreviations Interface Requirements R-APDU R-block RFU RID RSA RST SAD S-block SCA SDA SFI SHA-1 SI SIC SK SW1 SW2 TAC TAL TC TCK TDOL tF TLV TPDU tR TS Response APDU Receive Ready Block Reserved for Future Use Registered Application Provider Identifier Rivest, Shamir, Adleman Algorithm Reset Source Node Address Supervisory Block Certification Authority Private Key Static Data Authentication Short File Identifier Secure Hash Algorithm 1 Issuer Private Key ICC Private Key Session Key for session key generation Status Byte One Status Byte Two Terminal Action Code(s) (Default, Denial, Online) Terminal Application Layer Transaction Certificate Check Character Transaction Certificate Data Object List Fall Time Between 90% and 10% of Signal Amplitude Tag Length Value Transport Protocol Data Unit Rise Time Between 10% and 90% of Signal Amplitude Initial Character November 2011 4 Abbreviations, Notations, Conventions, and Terminology EMV 4.3 Book 4 4.1 Abbreviations Cardholder, Attendant, and Acquirer Interface Requirements TSI TTL TVR UCOL UL V var. VCC VCC VIH VIL VOH VOL VPP VPP WI WTX WWT YYMM YYMMDD Transaction Status Information Terminal Transport Layer Terminal Verification Results Upper Consecutive Offline Limit Underwriters Laboratories Incorporated Volt Variable (see section 4.3) Voltage Measured on VCC Contact Supply Voltage High Level Input Voltage Low Level Input Voltage High Level Output Voltage Low Level Output Voltage Programming Voltage Voltage Measured on VPP contact Waiting Time Integer Waiting Time Extension Work Waiting Time Year, Month Year, Month, Day November 2011 EMV 4.3 Book 4 4 Abbreviations, Notations, Conventions, and Terminology Cardholder, Attendant, and Acquirer 4.2 Notations Interface Requirements 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 Annex A1 of Book 2, using a secret key K X = ALG–1(K)[Y] Decipherment of a data block Y with a block cipher as specified in Annex A1 of Book 2, using a secret key K Y:= Sign (SK)[X] The signing of a data block X with an asymmetric reversible algorithm as specified in Annex A2 of Book 2, using the private key SK X = Recover(PK)[Y] The recovery of the data block X with an asymmetric reversible algorithm as specified in Annex A2 of Book 2, 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. November 2011 4 Abbreviations, Notations, Conventions, and Terminology EMV 4.3 Book 4 4.2 Notations Cardholder, Attendant, and Acquirer Interface Requirements Leftmost Rightmost H:= Hash[MSG] X ⊕ Y 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. 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. November 2011 EMV 4.3 Book 4 4 Abbreviations, Notations, Conventions, and Terminology Cardholder, Attendant, and Acquirer 4.3 Data Element Format Conventions Interface Requirements 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). 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 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'. November 2011 4 Abbreviations, Notations, Conventions, and Terminology EMV 4.3 Book 4 4.3 Data Element Format Conventions Cardholder, Attendant, and Acquirer Interface Requirements 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. November 2011 EMV 4.3 Book 4 4 Abbreviations, Notations, Conventions, and Terminology Cardholder, Attendant, and Acquirer 4.4 Terminology Interface Requirements 4.4 Terminology proprietary Not defined in this specification and/or outside the scope of this specification shall Denotes a mandatory requirement should Denotes a recommendation November 2011 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements Part II General Requirements November 2011 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 5 Terminal Types and Capabilities 5.1 Terminal Types As described in section 1, this specification addresses a broad spectrum of terminals. For the purpose of this specification, terminals are categorised by the following:
  • Environment: Attended or unattended
  • Communication: Online or offline
  • Operational control: Financial institution, merchant, or cardholder Table 1 defines the terms used to describe terminal types. Term Attended Unattended Online only Offline with online capability Offline only Operational control Definition An attendant (an agent of the merchant or of the acquirer) is present at the point of transaction and participates in the transaction by entering transaction-related data. The transaction occurs ‘face to face’. The cardholder conducts the transaction at the point of transaction without the participation of an attendant (agent of the merchant or of the acquirer). The transaction does not occur ‘face to face’. The transaction can normally only be approved in real time by transmission of an authorisation request message. Depending upon transaction characteristics, the transaction can be completed offline by the terminal or online in real time. It is equivalent to ‘online with offline capability’. The transaction can only be completed offline by the terminal. Identifies the entity responsible for the operation of the terminal. This does not necessarily equate to the actual owner of the terminal. Table 1: Terms Describing Terminal Types Within this specification, online reflects online communication to acquirer (or its agent). The acquirer is assumed to be capable of communicating to the issuer (or its agent). November 2011 5 Terminal Types and Capabilities 5.2 Terminal Capabilities EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements The type of terminal shall be indicated in Terminal Type. The coding of Terminal Type using the three categories is shown in Annex A.

5.2 Terminal Capabilities For the purpose of this specification, terminal capabilities are described in Terminal Capabilities and Additional Terminal Capabilities. The following categories shall be indicated in Terminal Capabilities:

  • Card data input capability - Indicates all the methods supported by the terminal for entering the information from the card into the terminal.
  • Cardholder Verification Method (CVM) capability - Indicates all the methods supported by the terminal for verifying the identity of the cardholder at the terminal.
  • Security capability - Indicates all the methods supported by the terminal for authenticating the card at the terminal and whether or not the terminal has the ability to capture a card. The following categories shall be indicated in Additional Terminal Capabilities:
  • Transaction type capability - Indicates all the types of transactions supported by the terminal.
  • Terminal data input capability - Indicates all the methods supported by the terminal for entering transaction-related data into the terminal.
  • Terminal data output capability - Indicates the ability of the terminal to print or display messages and the character set code table(s) referencing the part(s) of ISO/IEC 8859 supported by the terminal. The coding of Terminal Capabilities and Additional Terminal Capabilities using these categories is shown in Annex A. November 2011 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 5. Terminal Types and Capabilities 5.3 Terminal Configurations 5.3 Terminal Configurations Terminal capabilities and device components vary depending on the intended usage and physical environment. A limited set of configuration examples follow. Figure 1 illustrates an example of an attended terminal where the integrated circuit (IC) interface device (IFD) and PIN pad are integrated but separate from the POS device (such as for an electronic fund transfer terminal or an electronic cash register). Terminal 123 456 ICC 789 C0E IFD POS Device Mag. stripe card C = ‘Cancel’ E = ‘Enter’ Figure 1: Example of an Attended Terminal November 2011 5 Terminal Types and Capabilities 5.3 Terminal Configurations EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements Figure 2 illustrates an example of merchant host concentrating devices, which may be of various types and capabilities. POS Device Merchant Host Figure 2: Example of a Merchant Host Within this specification a merchant host to which is connected a cluster of POS devices shall be considered, in its totality, as a ‘terminal’ regardless of the distribution of functions between the host and POS devices. (See section 10 for terminal data management requirements.) November 2011 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 5. Terminal Types and Capabilities 5.3 Terminal Configurations Figure 3 illustrates an example of a cardholder-controlled terminal that is connected via a public network to a merchant or acquirer host. 123 456 789 C0E Cardholder Terminal Public Network C = ‘Cancel’ E = ‘Enter’ Merchant Host Acquirer Host Figure 3: Example of a Cardholder-Controlled Terminal November 2011 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 6 Functional Requirements This Book does not replicate the other Books of the Integrated Circuit Card Specifications for Payment Systems but describes the implementation issues and the impact of those Books on the terminal. This section uses standard messages described in section 11.2 to illustrate the appropriate message displays for the transaction events described below. The usage of Authorisation Response Code, CVM Results, and Issuer Script Results is specified in this section. See Annex A for additional information on coding.

6.1 Application Independent ICC to Terminal Interface Requirements The terminal shall comply with all Parts of Book 1. It shall support all data elements and commands subject to the conditions described in section 6.3.

6.2 Security and Key Management The terminal shall comply with all Parts of Book 2. It shall support all data elements and commands subject to the conditions described in section 6.3.

6.3 Application Specification The terminal shall comply with all Parts of Book 3. It shall support all functions subject to the conditions described in this section. Sections 6.3.1 to 6.3.9 expand upon the terminal functions described in Book 3. November 2011

6 Functional Requirements 6.3 Application Specification EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 6.3.1 Initiate Application Processing When the Processing Options Data Object List (PDOL) includes an amount field (either Amount, Authorised or Amount, Other), an attended terminal (Terminal Type = 'x1', 'x2' or 'x3') shall provide the amount at this point in transaction processing. If the amount is not yet available, the terminal shall obtain the amount and should display the ‘ENTER AMOUNT’ message. For any other terminal type, if the terminal is unable to provide the amount at this point in transaction processing, the amount field in the data element list shall be filled with hexadecimal zeroes. As described in Book 3, if the card returns SW1 SW2 = '6985' in response to the GET PROCESSING OPTIONS command, indicating that the transaction cannot be performed with this application, then the terminal should display the ‘NOT ACCEPTED’ message and shall return to application selection. The terminal shall not allow that application to be selected again for this card session as defined in Book 1.

6.3.2 Offline Data Authentication An online-only terminal supporting no form of offline data authentication as indicated in Terminal Capabilities shall set to 1 the ‘Offline data authentication was not performed’ bit in the Terminal Verification Results (TVR). (For details, see Annex C of Book 3.) All other terminals shall support both offline static data authentication (SDA) and offline dynamic data authentication (DDA and optionally CDA) as described in Books 2 and 3. When the selected form of offline data authentication is CDA and CDA fails prior to the final Terminal Action Analysis (for example, Issuer Public Key recovery fails prior to Terminal Action Analysis) preceding the issuance of a first GENERATE AC command, or second GENERATE AC command in the case ‘unable to go online’, the terminal shall set the TVR bit for ‘CDA failed’ to 1 and request the cryptogram type determined by Terminal Action Analysis. In this case, the GENERATE AC command shall not request a CDA signature and no further CDA processing is performed. When the selected form of offline data authentication is CDA and a CDA failure is detected after the final Terminal Action Analysis preceding the issuance of a first or second GENERATE AC command, the terminal shall set the ‘CDA failed’ bit in the TVR to 1 and the following rules apply: If CDA fails in conjunction with the first GENERATE AC:

  • If the Cryptogram Information Data (CID) bit indicates that the card has returned a TC, the terminal shall decline the transaction and not perform a second GENERATE AC command. November 2011 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 6. Functional Requirements 6.3 Application Specification
  • If the CID bit indicates that the card has returned an ARQC, the terminal shall complete the transaction processing by performing an immediate second GENERATE AC command requesting an AAC. If CDA fails in conjunction with the second GENERATE AC, the terminal shall decline the transaction If as part of dynamic signature verification the CID was retrieved from the ICC Dynamic Data (as recovered from the Signed Dynamic Application Data), then it is this value that shall be used to determine the cryptogram type. Otherwise the cleartext CID in the GENERATE AC response shall be used. Terminals supporting offline cryptography should support Certificate Revocation Lists (CRLs). If CRLs are supported, the support shall be in accordance with section 5.1.2 of Book 2.

6.3.3 Processing Restrictions If the card and terminal Application Version Numbers are different, the terminal shall attempt to continue processing the transaction. If it is unable to continue, the terminal shall abort the transaction and should display the ‘NOT ACCEPTED’ message. When processing the Application Usage Control, the terminal must know whether or not it is an ATM. See Annex A1 for information on identifying an ATM. A terminal supporting cashback should not offer cashback facility to the cardholder if the Application Usage Control does not allow this option.

6.3.4 Cardholder Verification Processing Recognition of a CVM means the CVM Code is understood by the terminal but not necessarily supported by the terminal. The terminal shall recognise the EMV-defined CVM codes in Annex C3 of Book 3 including the CVM codes for 'No CVM required' and 'Fail CVM processing. The terminal may also recognize proprietary CVM Codes not defined in Annex C3. Support for a CVM means the terminal has the hardware and software necessary to perform the CVM. Support for EMV-defined CVM codes is indicated in the following manner:

  • For EMV-defined CVM codes, support is indicated in Terminal Capabilities.
  • For CVM codes not defined in EMV, support may be known implicitly.
  • For Combination CVMs, both CVM codes must be supported.
  • Fail CVM shall always be considered supported. A CVM can be performed only if it is both recognised and supported. November 2011 6 Functional Requirements 6.3 Application Specification EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 6.3.4.1 Offline CVM When the applicable CVM is an offline PIN, the terminal should issue a GET DATA command to the card to retrieve the PIN Try Counter prior to issuing either the VERIFY command or GET CHALLENGE command. If the PIN Try Counter is not retrievable or the GET DATA command is not supported by the ICC, or if the value of the PIN Try Counter is not zero, indicating remaining PIN tries, the terminal shall prompt for PIN entry such as by displaying the message ‘ENTER PIN’. If the value of the PIN Try Counter is zero, indicating no remaining PIN tries, the terminal should not allow offline PIN entry. The terminal:
  • shall set the ‘PIN Try Limit exceeded’ bit in the TVR to 1 (for details on TVR, see Annex C of Book 3),
  • shall not display any specific message regarding PINs, and
  • shall continue cardholder verification processing in accordance with the card’s CVM List. If offline PIN verification by the ICC is successful, the terminal shall set byte 3 of the CVM Results to ‘successful’. Otherwise, the terminal shall continue cardholder verification processing in accordance with the card’s CVM List. (CVM Results is described in section 6.3.4.5 and coded according to Annex A4.) 6.3.4.2 Online CVM When the applicable CVM is an online PIN, the IFD shall not issue a VERIFY command. Instead, the PIN pad shall encipher the PIN upon entry for transmission in the authorisation or financial transaction request. The terminal shall allow a PIN to be entered for online verification even if the card’s PIN Try Limit is exceeded. The terminal shall set byte 3 of the CVM Results to ‘unknown’. November 2011 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 6. Functional Requirements 6.3 Application Specification 6.3.4.3 PIN Entry Bypass If a PIN is required for entry as indicated in the card’s CVM List, an attended terminal with an operational PIN pad may have the capability to bypass PIN entry before or after several unsuccessful PIN tries.1 If this occurs, the terminal:
  • shall set the ‘PIN entry required, PIN pad present, but PIN was not entered’ bit in the TVR to 1,
  • shall not set the ‘PIN Try Limit exceeded’ bit in the TVR to 1,
  • shall consider this CVM unsuccessful, and
  • shall continue cardholder verification processing in accordance with the card’s CVM List. When PIN entry has been bypassed for one PIN-related CVM, it may be considered bypassed for any subsequent PIN-related CVM during the current transaction.

6.3.4.4 Signature (Paper) When the applicable CVM is signature, the terminal shall set byte 3 of the CVM Results to ‘unknown’. At the end of the transaction, the terminal shall print a receipt with a line for cardholder signature. (See Annex A2 for requirements for the terminal to support signature as a CVM.) 1 This prevents a genuine cardholder who does not remember the PIN from having to keep entering incorrect PINs until the PIN is blocked in order to continue with the transaction. November 2011

6 Functional Requirements 6.3 Application Specification EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 6.3.4.5 CVM Results When the applicable CVM is ‘No CVM required’, if the terminal supports ‘No CVM required’ it shall set byte 3 of the CVM Results to ‘successful’. When the applicable CVM is ‘Fail CVM processing’, the terminal shall set byte 3 of the CVM Results to ‘failed’. The terminal shall set bytes 1 and 2 of the CVM Results with the Method Code and Condition Code of the last CVM performed. After a successful CVM, CVM Results reflect the successful CVM. After an unsuccessful CVM with byte 1 bit 7 of the CV Rule set to 0 (fail cardholder verification), CVM Results reflect the unsuccessful CVM. After an unsuccessful CVM with byte 1 bit 7 set to 1 (apply succeeding CVM), CVM Results reflect this unsuccessful CVM only when no subsequent CVMs are performed; that is, when for each subsequent CV Rule either the CVM condition is not satisfied or the CVM condition is satisfied but the CVM method is not supported or is not recognised. If a subsequent CVM is performed, CVM Results reflect the outcome of the subsequent CVM. If the last CVM performed was not considered successful (byte 3 of the CVM Results is not set to ‘successful’ or ‘unknown’), the terminal shall set byte 3 of the CVM Results to ‘failed’. If no CVM was performed (no CVM List present or no CVM conditions satisfied), the terminal shall set byte 1 of the CVM Results to ‘No CVM performed’. Table 2 on the following page shows the setting of CVM Results, Byte 3 of Terminal Verification Results (TVR) related to CVM processing, and the Transaction Status Information (TSI) bit for CVM processing for some conditions that may occur during CVM List processing. Please note that for the first five entries in the table, the second byte of the CVM Results has no actual meaning so it is recommended it be set to '00'.

November 2011

EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 6. Functional Requirements 6.3 Application Specification Conditions When the card does not support cardholder verification (AIP bit 5=0) When CVM List is not present or the CVM List has no CVM rules When no CVM Conditions in CVM List are satisfied When the terminal does not support any of the CVM Codes in CVM List where the CVM Condition was satisfied When the terminal does not recognise any of the CVM Codes in CVM List (or the code is RFU) where the CVM Condition was satisfied Corresponding CVM Results Byte 1 (CVM Performed) '3F' (Book 4 Section 6.3.4.5 and Annex A4) '3F' (Book 4 Section 6.3.4.5 and Annex A4) '3F' (Book 4 Section 6.3.4.5 and Annex A4) '3F' (Book 4 Section 6.3.4.5 and Annex A4) '3F' (Book 4 Section 6.3.4.5 and Annex A4) Byte 2 (CVM Condition) '00' (no meaning) '00' (no meaning) '00' (no meaning) '00' (no meaning) '00' (no meaning) When the (last) performed CVM is 'Fail CVM processing' '00' or '40' (Not recommended for cards.) The CVM Condition Code for the CVM Code in Byte 1 When the last performed CVM fails The CVM Code for the last performed CVM The CVM Condition Code for the CVM Code in Byte 1 When the CVM performed is 'Signature' '1E' or '5E' (CVM Code for 'Signature') The CVM Condition Code for the CVM Code in Byte 1 Byte 3 (CVM Result) '00' '00' '01' '01' '01' '01' (Book 4 Section 6.3.4.5 and Annex A4) '01' '00' (Book 4 Section 6.3.4.4 and Annex A4) Table 2: Setting of CVM Results, TVR bits and TSI bits following CVM Processing TVR Byte 3 --bit 8 = 1 bit 8 = 1 bit 8 = 1 bit 7 = 1 bit 8 = 1 bit 8 = 12 -- TSI Byte 1 bit 7 0 0 (Book 3 Section 10.5) 1 1 1 1 1 1 2 Errors with PIN related CVMs may also result in the setting of other PIN-related TVR bits. November 2011

6 Functional Requirements 6.3 Application Specification EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements Conditions When the CVM performed is 'Online PIN' Corresponding CVM Results Byte 1 (CVM Performed) Byte 2 (CVM Condition) '02' or '42' (CVM Code for 'Online PIN') The CVM Condition Code for the CVM Code in Byte 1 When the CVM performed is 'No CVM required' '1F' or '5F' The CVM Condition Code for (CVM code for 'No CVM Required') the CVM Code in Byte 1 When a CVM is performed and fails with the failure action being 'Go to Next' and then the end of the CVM List is reached without another CVM Condition being satisfied When the CVM performed is a combination CVM Code, and at least one fails and the failure action is Fail CVM When the CVM performed is a combination CVM Code, and one passes and the result of the other is 'unknown' The last CVM Code in the CVM List for which the CVM Condition was satisfied (but that failed). The CVM Condition Code for the CVM Code in Byte 1 CVM Code for the combination CVM CVM Code for the combination CVM The CVM Condition Code for the CVM Code in Byte 1 The CVM Condition Code for the CVM Code in Byte 1 Byte 3 (CVM Result) '00' (Book 4 Section 6.3.4.2 and Annex A4) '02' (Book 4 Section 6.3.4.5 and Annex A4) '01' '01' '00' TVR Byte 3 bit 3 = 1 -- bit 8 = 1 bit 8 = 12 -- Table 2: Setting of CVM Results, TVR bits and TSI bits following CVM Processing, continued TSI Byte 1 bit 7 1 1 1 1 1

November 2011

EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 6 Functional Requirements 6.3 Application Specification 6.3.5 Terminal Risk Management In addition to the terminal risk management functions described in Book 3 and regardless of the coding of the card’s Application Interchange Profile bit setting for ‘Terminal Risk Management is to be performed’, a terminal may support an exception file per application. When the terminal has an exception file listing cards and associated applications, the terminal shall check the presence of the card (identified by data such as the Application Primary Account Number (PAN) and the Application PAN Sequence Number taken from the currently selected application) in the exception file. If a match is found in the exception file, the terminal shall set the ‘Card appears in exception file’ bit in the TVR to 1.

6.3.6 Terminal Action Analysis As described in Book 3, during terminal action analysis the terminal determines whether the transaction should be approved offline, declined offline, or transmitted online by comparing the TVR with both Terminal Action Code Denial and Issuer Action Code - Denial, both Terminal Action Code - Online and Issuer Action Code - Online, and both Terminal Action Code - Default and Issuer Action Code - Default.

  • If the terminal decides to accept the transaction offline, it shall set the Authorisation Response Code to ‘Offline approved’.3
  • If the terminal decides to decline the transaction offline, it shall set the Authorisation Response Code to ‘Offline declined’.
  • If the terminal decides to transmit the transaction online, it shall not set a value for the Authorisation Response Code nor change the value for the Authorisation Response Code returned in the response message. 3 This does not mean that the transaction will be approved. The card makes the final decision and returns it to the terminal in its response to the first GENERATE AC command. November 2011 6 Functional Requirements 6.3 Application Specification EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 6.3.7 Card Action Analysis In response to the GENERATE APPLICATION CRYPTOGRAM (AC) command, the card returns CID. Based on the CID, the terminal shall process the transaction as follows: If the card indicates: approval decline process online advice, and if advices are supported by the terminal and terminal acquirer interface protocol advice, and if advices are not supported by the terminal and terminal acquirer interface protocol ‘Service not allowed’ then the terminal:
  • shall complete the transaction
  • should display the ‘APPROVED’ message
  • shall decline the transaction
  • should display the ‘DECLINED’ message shall transmit an authorisation or financial transaction request message, if capable (See section 12.2.1 for exception handling when the terminal is unable to go online.)  shall not, if the transaction is captured, create an advice message.  shall, if the transaction is not captured (such as a decline), either transmit an online advice if online data capture is performed by the acquirer, or create an offline advice for batch data capture. (See section 12.2.5 for exception handling when the terminal is unable to create an advice) does not create an advice.
  • shall terminate the transaction
  • should display the ‘NOT ACCEPTED’ message Table 3: Card Action Analysis November 2011 EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 6.3.8 Online Processing Depending on the Authorisation Response Code returned in the response message, the terminal shall determine whether to accept or decline the transaction. It shall issue the second GENERATE AC command to the ICC indicating its decision. The result of card risk management performed by the ICC is made known to the terminal through the return of the CID indicating either a transaction certificate (TC) for an approval or an application authentication cryptogram (AAC) for a decline. When online data capture is performed by the acquirer, the terminal shall send a reversal message if the final decision of the card is to decline a transaction for which the Authorisation Response Code is ‘Online approved’.

6.3.9 Issuer-to-Card Script Processing The terminal shall be able to support one or more Issuer Scripts in each authorisation or financial transaction response it receives, where the total length of all Issuer Scripts in the response shall be less than or equal to 128 bytes. Note: In this case and when only one Issuer Script (tag ‘71’ or ‘72’) is sent, and no Issuer Script Identifier is used, the maximum length of the Issuer Script Command (tag ‘86’) is limited to 124 bytes. This implies that the maximum available useful command data (Lc) is limited to 119 bytes for a Case 3 command. The terminal shall be able to recognise the tag for the Issuer Script transmitted in the response message. If the tag is '71', the terminal shall process the script before issuing the second GENERATE AC command. If the tag is '72', the terminal shall process the script after issuing the second GENERATE AC command. For each Issuer Script processed, the terminal shall report the Script Identifier (when present) with its result in the Issuer Script Results. If an error code was returned by the card for one of the single Script Commands, the terminal shall set the most significant nibble of byte 1 of the Issuer Script Results to ‘Script processing failed’ and the least significant nibble with the sequence number of the Script Command in the order it appears in the Issuer Script. If no error code was returned by the card, the terminal shall set the most significant nibble of byte 1 of the Issuer Script Results to ‘Script processing successful’ and the least significant nibble to '0'. See Annex A5 for details. The terminal shall transmit the Issuer Script Results in the batch data capture message (financial record or offline advice), the financial transaction confirmation message, or the reversal message. If no message is created for the transaction (such as a decline), the terminal shall create an advice to transmit the Issuer Script Results, if the terminal supports advices. November 2011

6 Functional Requirements 6.4 Conditions for Support of Functions EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 6.4 Conditions for Support of Functions A terminal supporting offline PIN verification shall support the VERIFY command. A terminal supporting offline PIN encipherment shall also support the GET CHALLENGE command. A terminal not supporting offline PIN verification need not support the VERIFY command. An offline-only terminal and an offline terminal with online capability shall support both SDA and DDA and may optionally support CDA. An online-only terminal need not support SDA or DDA or CDA. Individual payment systems will define rules for this case. An offline-only terminal and an offline terminal with online capability shall support terminal risk management. An offline-only terminal and an online-only terminal need not support random transaction selection. An online-only terminal need not support all of the terminal risk management functions. In this case, the acquirer (or its agent) should process the transaction instead of the terminal according to Book 3. In other words, the acquirer should perform the remaining terminal risk management functions. Individual payment systems will define rules for this case. A financial institution- or merchant-controlled terminal (Terminal Type = '1x' or '2x') shall support the terminal risk management functions described in Book 3. A cardholder-controlled terminal (Terminal Type = '3x') need not support terminal risk management.

November 2011

EMV 4.3 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements 6.5 Other Functional Requirements 6.5.1 Amount Entry and Management The amount of a transaction shall be indicated to the cardholder preferably by means of a terminal display or labels, such as posted prices on a vending machine, or alternatively by printing on a receipt. When the amounts are entered through the use of a keypad the terminal should allow the amount to be displayed during entry. The attendant or cardholder should be able to either correct the amounts entered prior to authorisation and proceed with the transaction or cancel the transaction if the amount was entered incorrectly. The cardholder should be able to validate the original or corrected amount when the transaction amount is known before authorisation. If PIN entry occurs immediately after t

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