EMV

Integrated Circuit Card
Specifications for Payment Systems


Book 1

Application Independent ICC to Terminal
Interface Requirements


Version 4.2
June 2008


© 1994-2008 EMVCo, LLC (―EMVCo‖). All rights reserved. Any and all uses of the
EMV Specifications (―Materials‖) shall be permitted only pursuant to the terms and
conditions of the license agreement between the user and EMVCo found at
http://www.emvco.com
EMV
Integrated Circuit Card
Specifications for Payment Systems


Book 1

Application Independent ICC to Terminal
Interface Requirements


Version 4.2
June 2008

EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page ii June 2008

EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page iii
Revision Log - Version 4.2
The following changes have been made to Book 1 since the publication of
Version 4.1. Numbering and cross references in this version have been updated
to reflect changes introduced by the published bulletins.
Incorporated changes described in the following General bulletins:
General Bulletin no. 11 Second Edition: Lower Voltage Card Migration
Mandatory Implementation Schedule
Incorporated changes described in the following Specification Updates:
Specification Update Bulletin no. 42: Voice Referrals
Specification Update Bulletin no. 43: Correction to the Coding of TA2
Specification Update Bulletin no. 49: Data Errors during List of AIDs
Selection
Updated in support of the following Application Notes:
Application Note no. 26: Warm Reset Timing
Application Note no.38: Recommendations Regarding the Use of Historical
Bytes
Minor editorial clarifications, including those described in the following
Specification Updates:
Specification Update Bulletin no. 37 Fourth Edition: Editorial Errors in
Release 4.1 of the EMV Specifications

EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page v
Contents

Part I - General

1 Scope 3
1.1 Changes in Version 4.2 3
1.2 Structure 3
1.3 Underlying Standards 4
1.4 Audience 4
2 Normative References 5
3 Definitions 9
4 Abbreviations, Notations, Conventions, and Terminology 19
4.1 Abbreviations 19
4.2 Notations 27
4.3 Data Element Format Conventions 29
4.4 Terminology 31


Part II - Electromechanical Characteristics, Logical Interface, and
Transmission Protocols

5 Electromechanical Interface 35
5.1 Lower Voltage ICC Migration 36
5.2 Mechanical Characteristics of the ICC 37
5.2.1 Physical Characteristics 37
5.2.2 Dimensions and Location of Contacts 38
5.2.3 Contact Assignment 39
5.3 Electrical Characteristics of the ICC 40
5.3.1 Measurement Conventions 40
5.3.2 Input/Output (I/O) 40
5.3.3 Programming Voltage (VPP) 42
5.3.4 Clock (CLK) 43
5.3.5 Reset (RST) 44
5.3.6 Supply Voltage (VCC) 45
5.3.7 Contact Resistance 46
5.4 Mechanical Characteristics of the Terminal 47
5.4.1 Interface Device 47
5.4.2 Contact Forces 48
5.4.3 Contact Assignment 48
5.5 Electrical Characteristics of the Terminal 48
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page vi June 2008
5.5.1 Measurement Conventions 48
5.5.2 Input/Output (I/O) 49
5.5.3 Programming Voltage (VPP) 51
5.5.4 Clock (CLK) 52
5.5.5 Reset (RST) 53
5.5.6 Supply Voltage (VCC) 54
5.5.7 Contact Resistance 56
5.5.8 Short Circuit Resilience 56
5.5.9 Powering and Depowering of Terminal with ICC in Place 57
6 Card Session 59
6.1 Normal Card Session 59
6.1.1 Stages of a Card Session 59
6.1.2 ICC Insertion and Contact Activation Sequence 60
6.1.3 ICC Reset 61
6.1.4 Execution of a Transaction 63
6.1.5 Contact Deactivation Sequence 63
6.2 Abnormal Termination of Transaction Process 64
7 Physical Transportation of Characters 65
7.1 Bit Duration 65
7.2 Character Frame 66
8 Answer to Reset 69
8.1 Physical Transportation of Characters Returned at Answer to Reset 69
8.2 Characters Returned by ICC at Answer to Reset 70
8.3 Character Definitions 72
8.3.1 TS - Initial Character 73
8.3.2 T0 - Format Character 74
8.3.3 TA1 to TC3 - Interface Characters 74
8.3.4 TCK - Check Character 83
8.4 Terminal Behaviour during Answer to Reset 83
8.5 Answer to Reset - Flow at the Terminal 85
9 Transmission Protocols 87
9.1 Physical Layer 87
9.2 Data Link Layer 88
9.2.1 Character Frame 88
9.2.2 Character Protocol T=0 89
9.2.3 Error Detection and Correction for T=0 93
9.2.4 Block Protocol T=1 94
9.2.5 Error Detection and Correction for T=1 104
9.3 Terminal Transport Layer (TTL) 107
9.3.1 Transport of APDUs by T=0 107
9.3.2 Transportation of APDUs by T=1 115
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page vii
9.4 Application Layer 115
9.4.1 C-APDU 116
9.4.2 R-APDU 117


Part III - Files, Commands, and Application Selection

10 Files 121
10.1 File Structure 121
10.1.1 Application Definition Files 121
10.1.2 Application Elementary Files 122
10.1.3 Mapping of Files Onto ISO/IEC 7816-4 File Structure 122
10.1.4 Directory Structure 122
10.2 File Referencing 123
10.2.1 Referencing by Name 123
10.2.2 Referencing by SFI 123
11 Commands 125
11.1 Message Structure 125
11.1.1 Command APDU Format 126
11.1.2 Response APDU Format 127
11.2 READ RECORD Command-Response APDUs 127
11.2.1 Definition and Scope 127
11.2.2 Command Message 128
11.2.3 Data Field Sent in the Command Message 128
11.2.4 Data Field Returned in the Response Message 128
11.2.5 Processing State Returned in the Response Message 128
11.3 SELECT Command-Response APDUs 129
11.3.1 Definition and Scope 129
11.3.2 Command Message 130
11.3.3 Data Field Sent in the Command Message 130
11.3.4 Data Field Returned in the Response Message 131
11.3.5 Processing State Returned in the Response Message 134
12 Application Selection 135
12.1 Overview of Application Selection 135
12.2 Data in the ICC Used for Application Selection 137
12.2.1 Coding of Payment System Application Identifier 137
12.2.2 Structure of the PSE 138
12.2.3 Coding of a Payment System Directory 139
12.2.4 Coding of Other Directories 141
12.2.5 Error Handling for FCI Response Data 141
12.3 Building the Candidate List 141
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page viii June 2008
12.3.1 Matching Terminal Applications to ICC Applications 142
12.3.2 Using the PSE 143
12.3.3 Using a List of AIDs 146
12.4 Final Selection 149


Part IV - Annexes

Annex A Examples of Exchanges Using T=0 155
A1 Case 1 Command 155
A2 Case 2 Command 156
A3 Case 3 Command 156
A4 Case 4 Command 157
A5 Case 2 Command Using the '61' and '6C' Procedure Bytes 157
A6 Case 4 Command Using the '61' Procedure Byte 158
A7 Case 4 Command with Warning Condition 158

Annex B Data Elements Table 159
B1 Data Elements by Name 159
B2 Data Elements by Tag 165

Annex C Examples of Directory Structures 167
C1 Single Application Card 167
C2 Single Level Directory 168
C3 Multi-Level Directory 169


Part V - Common Core Definitions
Common Core Definitions 173
Changed Sections 173
10 Files 174
10.1 File Structure 174
10.1.4 Directory Structure 174
11 Commands 174
11.3 SELECT Command-Response APDUs 174
11.3.5 Processing State Returned in the Response Message 174
12 Application Selection 175
12.2 Data in the ICC Used for Application Selection 175
12.2.2 Structure of the PSE 175
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page ix
12.2.3 Coding of a Payment System Directory 175


Index 176

EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page x June 2008
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page xi
Tables

Table 1: Lower Voltage Card Migration 36
Table 2: ICC Contact Assignment 39
Table 3: Electrical Characteristics of I/O for ICC Reception 41
Table 4: Electrical Characteristics of I/O for ICC Transmission 42
Table 5: Electrical Characteristics of CLK to ICC 43
Table 6: Electrical Characteristics of RST to ICC 44
Table 7: Classes of Operation 45
Table 8: Mandatory and Optional Operating Voltage Ranges 46
Table 9: IFD Contact Assignment 48
Table 10: Electrical Characteristics of I/O for Terminal Transmission 50
Table 11: Electrical Characteristics of I/O for Terminal Reception 51
Table 12: Electrical Characteristics of CLK from Terminal 52
Table 13: Electrical Characteristics of RST from Terminal 53
Table 14: Terminal Supply Voltage and Current 55
Table 15: Basic ATR for T=0 Only 70
Table 16: Basic ATR for T=1 Only 71
Table 17: Terminal Behaviour 73
Table 18: Basic Response Coding of Character T0 74
Table 19: Basic Response Coding of Character TB1 76
Table 20: Basic Response Coding of Character TC1 77
Table 21: Basic Response Coding of Character TD1 78
Table 22: Basic Response Coding of Character TD2 80
Table 23: Basic Response Coding of Character TA3 81
Table 24: Basic Response Coding of Character TB3 82
Table 25: Terminal Response to Procedure Byte 91
Table 26: Status Byte Coding 92
Table 27: Structure of a Block 94
Table 28: Types of Blocks 95
Table 29: Coding of the PCB of an I-block 96
Table 30: Coding of the PCB of a R-block 96
Table 31: Coding of the PCB of a S-block 96
Table 32: Structure of Command Message 114
Table 33: GET RESPONSE Error Conditions 114
Table 34: Definition of Cases for Data in APDUs 115
Table 35: C-APDU Structures 116
Table 36: Command APDU Content 126
Table 37: Response APDU Content 127
Table 38: READ RECORD Command Message 128
Table 39: READ RECORD Command Reference Control Parameter 128
Table 40: SELECT Command Message 130
Table 41: SELECT Command Reference Control Parameter 130
Table 42: SELECT Command Options Parameter 130
Table 43: SELECT Response Message Data Field (FCI) of the PSE 131
Table 44: SELECT Response Message Data Field (FCI) of a DDF 132
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page xii June 2008
Table 45: SELECT Response Message Data Field (FCI) of an ADF 133
Table 46: Payment System Directory Record Format 139
Table 47: DDF Directory Entry Format 139
Table 48: ADF Directory Entry Format 140
Table 49: Format of Application Priority Indicator 140
Table 50: Data Elements Table 159
Table 51: Data Elements Tags 165


EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page xiii
Figures

Figure 1: ICC Contact Location and Dimensions 38
Figure 2: Layout of Contacts 39
Figure 3: Terminal Contact Location and Dimensions 47
Figure 4: Maximum Current Pulse Envelope 54
Figure 5: Maximum Current Pulse Envelopes 56
Figure 6: Contact Activation Sequence 60
Figure 7: Cold Reset Sequence 61
Figure 8: Warm Reset Sequence 62
Figure 9: Contact Deactivation Sequence 63
Figure 10: Character Frame 66
Figure 11: ATR - Example Flow at the Terminal 85
Figure 12: Character Repetition Timing 93
Figure 13: Chaining C-APDU 103
Figure 14: Chaining I-Blocks 103
Figure 15: Command APDU Structure 126
Figure 16: Response APDU Structure 127
Figure 17: Terminal Logic Using Directories 145
Figure 18: Using the List of AIDs in the Terminal 148
Figure 19: Simplest Card Structure Single Application 167
Figure 20: Single Level Directory 168
Figure 21: Third Level Directory 169

EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page xiv June 2008

EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 1
Part I

General
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page 2 June 2008

EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 3
1 Scope
This document, the Integrated Circuit Card (ICC) Specifications for Payment
Systems - Book 1, Application Independent ICC to Terminal Interface
Requirements, describes the minimum functionality required of integrated circuit
cards (ICCs) and terminals to ensure correct operation and interoperability
independent of the application to be used. Additional proprietary functionality
and features may be provided, but these are beyond the scope of this specification
and interoperability cannot be guaranteed.
The Integrated Circuit Card Specifications for Payment Systems includes the
following additional documents, all available on http://www.emvco.com:
- Book 2 - Security and Key Management
- Book 3 - Application Specification
- Book 4 - Cardholder, Attendant, and Acquirer Interface Requirements
1.1 Changes in Version 4.2
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 Book.
1.2 Structure
Book 1 consists of the following parts:
Part I - General
Part II - Electromechanical Characteristics, Logical Interface,
and Transmission Protocols
Part III - Files, Commands, and Application Selection
Part IV - Annexes
Part V - 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.
1 Scope EMV 4.2 Book 1
1.3 Underlying Standards Application Independent ICC to
Terminal Interface Requirements
Page 4 June 2008
Part II defines electromechanical characteristics, logical interface, and
transmission protocols as they apply to the exchange of information between an
ICC and a terminal. In particular it covers:
- Mechanical characteristics, voltage levels, and signal parameters as they
apply to both ICCs and terminals.
- An overview of the card session.
- Establishment of communication between the ICC and the terminal by
means of the answer to reset.
- Character- and block-oriented asynchronous transmission protocols.
Part III defines data elements, files, and commands as they apply to the
exchange of information between an ICC and a terminal. In particular it covers:
- Data elements and their mapping onto data objects.
- Structure and referencing of files.
- Structure and coding of messages between the ICC and the terminal to
achieve application selection.
Part III also defines the application selection process from the standpoint of both
the card and the terminal. The logical structure of data and files within the card
that is required for the process is specified, as is the terminal logic using the card
structure.
Part IV includes examples of exchanges using T=0, a data elements table specific
to application selection, and example directory structures.
Part V defines an optional extension to be used when implementing the Common
Core Definitions (CCD).
The Book also includes a revision log and an index.
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.

EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 5
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.

FIPS 180-2 Secure Hash Standard
ISO 639-1 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
ISO 3166 Codes for the representation of names of countries
and their subdivisions
ISO 4217 Codes for the representation of currencies and
funds
ISO/IEC 7811-1 Identification cards – Recording technique –
Part 1: Embossing
ISO/IEC 7811-3 Identification cards – Recording technique –
Part 3: Location of embossed characters on ID-1
cards
ISO/IEC 7813 Identification cards – Financial transaction cards
ISO/IEC 7816-1 Identification cards – Integrated circuit(s) cards
with contacts – Part 1: Physical characteristics
ISO/IEC 7816-2 Information technology – Identification cards –
Integrated circuit(s) cards with contacts – Part 2:
Dimensions and location of contacts
ISO/IEC 7816-3 Identification cards — Integrated circuit cards —
Part 3: Cards with contacts — Electrical interface
and transmission protocols
2 Normative References EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page 6 June 2008
ISO/IEC 7816-4 Identification cards — Integrated circuit cards —
Part 4: Organization, security and commands for
interchange
ISO/IEC 7816-5 Identification cards — Integrated circuit cards —
Part 5: Registration of application providers
ISO/IEC 7816-6 Identification cards – Integrated circuit cards –
Part 6: Interindustry data elements for
interchange
ISO 8583:1987 Bank card originated messages – Interchange
message specifications – Content for financial
transactions
ISO 8583:1993 Financial transaction card originated messages –
Interchange message specifications
ISO/IEC 8825-1 Information technology – ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)
ISO/IEC 8859 Information processing – 8-bit single-byte coded
graphic character sets
ISO 9362 Banking – Banking telecommunication messages
– Bank identifier codes
ISO 9564-1 Banking – PIN management and security –
Part 1: Basic principles and requirements for
online PIN handling in ATM and POS systems
ISO 9564-3 Banking – PIN management and security –
Part 3: Requirements for offline PIN handling in
ATM and POS systems
ISO/IEC 9796-2:2002 Information technology – Security techniques –
Digital signature schemes giving message
recovery – Part 2: Integer factorization based
mechanisms
ISO/IEC 9797-1 Information technology – Security techniques –
Message Authentication Codes – Part 1:
Mechanisms using a block cipher
EMV 4.2 Book 1 2 Normative References
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 7
ISO/IEC 10116 Information technology – Security techniques –
Modes of operation for an n-bit block cipher
ISO/IEC 10118-3 Information technology – Security techniques –
Hash-functions – Part 3: Dedicated hash-functions
ISO/IEC 10373 Identification cards – Test methods
ISO 13491-1 Banking – Secure cryptographic devices (retail) –
Part 1: Concepts, requirements and evaluation
methods
ISO 13616 Banking and related financial services –
International bank account number (IBAN)
ISO 16609 Banking – Requirements for message
authentication using symmetric techniques
ISO/IEC 18031 Information technology - Security techniques -
Random bit generation
ISO/IEC 18033-3 Information technology – Security techniques –
Encryption algorithms – Part 3: Block ciphers
2 Normative References EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page 8 June 2008

EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 9
3 Definitions
The following terms are used in one or more books of these specifications.

Accelerated
Revocation
A key revocation performed on a date sooner than the
published key expiry date.
Application The application protocol between the card and the
terminal and its related set of data.
Application
Authentication
Cryptogram
An Application Cryptogram generated by the card
when declining a transaction
Application
Cryptogram
A cryptogram generated by the card in response to a
GENERATE AC command. See also:
- Application Authentication Cryptogram
- Authorisation Request Cryptogram
- Transaction Certificate
Authorisation
Request Cryptogram
An Application Cryptogram generated by the card
when requesting online authorisation
Authorisation
Response
Cryptogram
A cryptogram generated by the issuer in response to
an Authorisation Request Cryptogram.
Asymmetric
Cryptographic
Technique
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.
Authentication The provision of assurance of the claimed identity of
an entity or of data origin.
Block A succession of characters comprising two or three
fields defined as prologue field, information field, and
epilogue field.
3 Definitions EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page 10 June 2008
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.
Cold Reset 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.
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.
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.
Contact A conducting element ensuring galvanic continuity
between integrated circuit(s) and external interfacing
equipment.
EMV 4.2 Book 1 3 Definitions
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 11
Cryptogram Result of a cryptographic operation.
Cryptographic
Algorithm
An algorithm that transforms data in order to hide or
reveal its information content.
Data Integrity The property that data has not been altered or
destroyed in an unauthorised manner.
Deactivation
Sequence
The deactivation sequence defined in section 6.1.5.
Decipherment The reversal of a corresponding encipherment.
Digital Signature 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.
Dynamic Data
Authentication
A form of offline dynamic data authentication
Embossing Characters raised in relief from the front surface of a
card.
Encipherment The reversible transformation of data by a
cryptographic algorithm to produce ciphertext.
Epilogue Field The final field of a block. It contains the error
detection code (EDC) byte(s).
Exclusive-OR Binary addition with no carry, giving the following
values:
0 + 0 = 0
0 + 1 = 1
1 + 0 = 1
1 + 1 = 0
Financial
Transaction
The act between a cardholder and a merchant or
acquirer that results in the exchange of goods or
services against payment.
Function A process accomplished by one or more commands and
resultant actions that are used to perform all or part
of a transaction.
3 Definitions EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page 12 June 2008
Guardtime 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.
Hash Function 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.
Hash Result The string of bits that is the output of a hash
function.
Inactive 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).
Integrated Circuit
Module
The sub-assembly embedded into the ICC comprising
the IC, the IC carrier, bonding wires, and contacts.
Integrated Circuit(s) Electronic component(s) designed to perform
processing and/or memory functions.
Integrated Circuit(s)
Card
A card into which one or more integrated circuits are
inserted to perform processing and memory functions.
Interface Device That part of a terminal into which the ICC is inserted,
including such mechanical and electrical devices as
may be considered part of it.
Issuer Action Code 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
EMV 4.2 Book 1 3 Definitions
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 13
Kernel 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.
Key A sequence of symbols that controls the operation of a
cryptographic transformation.
Key Expiry Date 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.
Key Introduction The process of generating, distributing, and beginning
use of a key pair.
Key Life Cycle All phases of key management, from planning and
generation, through revocation, destruction, and
archiving.
Key Replacement The simultaneous revocation of a key and
introduction of a key to replaced the revoked one.
Key Revocation 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.
Key Revocation Date 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.
Key Withdrawal The process of removing a key from service as part of
its revocation.
Keypad Arrangement of numeric, command, and, where
required, function and/or alphanumeric keys laid out
in a specific manner.
3 Definitions EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page 14 June 2008
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
The set of logical conditions established within the
ICC when a payment system application conforming
to this specification has been selected, or when a
Directory Definition File (DDF) used for payment
system application purposes has been selected.
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.
EMV 4.2 Book 1 3 Definitions
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 15
Potential
Compromise
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.
Private Key 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.
Prologue Field The first field of a block. It contains subfields for node
address (NAD), protocol control byte (PCB), and
length (LEN).
Public Key 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.
Public Key
Certificate
The public key information of an entity signed by the
certification authority and thereby rendered
unforgeable.
Response A message returned by the ICC to the terminal after
the processing of a command message received by the
ICC.
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.
Signal Amplitude The difference between the high and low voltages of a
signal.
Signal Perturbations 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.
Socket An execution vector defined at a particular point in an
application and assigned a unique number for
reference.
3 Definitions EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page 16 June 2008
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, 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.
EMV 4.2 Book 1 3 Definitions
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 17
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.
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.
Warm Reset 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.

3 Definitions EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page 18 June 2008

EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 19
4 Abbreviations, Notations, Conventions, and
Terminology
4.1 Abbreviations
µA Microampere
µm Micrometre
µs Microsecond
a Alphabetic (see section 4.3, Data Element Format Conventions)
AAC Application Authentication Cryptogram
AC Application Cryptogram
ACK Acknowledgment
ADF Application Definition File
AEF Application Elementary File
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
4 Abbreviations, Notations, Conventions, and Terminology EMV 4.2 Book 1
4.1 Abbreviations Application Independent ICC to
Terminal Interface Requirements
Page 20 June 2008
ATM Automated Teller Machine
ATR Answer to Reset
AUC Application Usage Control
b Binary (see section 4.3)
BCD Binary Coded Decimal
BER Basic Encoding Rules (defined in ISO/IEC 8825–1)
BIC Bank Identifier Code
BGT Block Guardtime
BWI Block Waiting Time Integer
BWT Block Waiting Time
C Celsius or Centigrade
CAD Card Accepting Device
C-APDU Command APDU
CBC Cipher Block Chaining
CCD Common Core Definitions
CCI Common Core Identifier
CDA Combined DDA/Application Cryptogram Generation
CDOL Card Risk Management Data Object List
CID Cryptogram Information Data
C
IN
Input Capacitance
CLA Class Byte of the Command Message
CLK Clock
cn Compressed Numeric (see section 4.3)
CPU Central Processing Unit
CRL Certificate Revocation List
CSU Card Status Update
C-TPDU Command TPDU
CV Cryptogram Version
EMV 4.2 Book 1 4 Abbreviations, Notations, Conventions, and Terminology
Application Independent ICC to 4.1 Abbreviations
Terminal Interface Requirements
June 2008 Page 21
CVM Cardholder Verification Method
CVR Card Verification Results
CV Rule Cardholder Verification Rule
CWI Character Waiting Time Integer
CWT Character Waiting Time
D Bit Rate Adjustment Factor
DAD Destination Node Address
DC Direct Current
DDA Dynamic Data Authentication
DDF Directory Definition File
DDOL Dynamic Data Authentication Data Object List
DES Data Encryption Standard
DF Dedicated File
DIR Directory
DOL Data Object List
ECB Electronic Code Book
EDC Error Detection Code
EF Elementary File
EN European Norm
etu Elementary Time Unit
f Frequency
FC Format Code
FCI File Control Information
GND Ground
GP Grandparent key for session key generation
Hex Hexadecimal
HHMMSS Hours, Minutes, Seconds
I/O Input/Output
4 Abbreviations, Notations, Conventions, and Terminology EMV 4.2 Book 1
4.1 Abbreviations Application Independent ICC to
Terminal Interface Requirements
Page 22 June 2008
IAC Issuer Action Code (Denial, Default, Online)
IAD Issuer Application Data
IBAN International Bank Account Number
I-block Information Block
IC Integrated Circuit
ICC Integrated Circuit(s) Card
I
CC
Current drawn from VCC
IEC International Electrotechnical Commission
IFD Interface Device
IFS Information Field Size
IFSC Information Field Size for the ICC
IFSD Information Field Size for the Terminal
IFSI Information Field Size Integer
IIN Issuer Identification Number
IK Intermediate Key for session key generation
INF Information Field
INS Instruction Byte of Command Message
I
OH
High Level Output Current
I
OL
Low Level Output Current
ISO International Organization for Standardization
IV Initial Vector for session key generation
K
M
Master Key
K
S
Session Key
L Length
l.s. Least Significant
Lc Exact Length of Data Sent by the TAL in a Case 3 or 4
Command
LCOL Lower Consecutive Offline Limit
EMV 4.2 Book 1 4 Abbreviations, Notations, Conventions, and Terminology
Application Independent ICC to 4.1 Abbreviations
Terminal Interface Requirements
June 2008 Page 23
L
DD
Length of the ICC Dynamic Data
Le Maximum Length of Data Expected by the TAL in Response to
a Case 2 or 4 Command
LEN Length
Licc 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
Lr Length of Response Data Field
LRC Longitudinal Redundancy Check
M Mandatory
mO Milliohm
MO Megohm
m.s. Most Significant
m/s Meters per Second
mA Milliampere
MAC Message Authentication Code
max. Maximum
MF Master File
MHz Megahertz
min. Minimum
MK ICC Master Key for session key generation
mm Millimetre
MMDD Month, Day
MMYY Month, Year
N Newton
n Numeric (see section 4.3)
NAD Node Address
NAK Negative Acknowledgment
nAs Nanoampere-second
4 Abbreviations, Notations, Conventions, and Terminology EMV 4.2 Book 1
4.1 Abbreviations Application Independent ICC to
Terminal Interface Requirements
Page 24 June 2008
N
CA
Length of the Certification Authority Public Key Modulus
NF Norme Française
N
I
Length of the Issuer Public Key Modulus
N
IC
Length of the ICC Public Key Modulus
NIST National Institute for Standards and Technology
N
PE
Length of the ICC PIN Encipherment Public Key Modulus
ns Nanosecond
O Optional
O/S Operating System
P Parent key for session key generation
P1 Parameter 1
P2 Parameter 2
P3 Parameter 3
PAN Primary Account Number
PC Personal Computer
P
CA
Certification Authority Public Key
PCB Protocol Control Byte
PDOL Processing Options Data Object List
pF Picofarad
P
I
Issuer Public Key
P
IC
ICC Public Key
PIN Personal Identification Number
PIX Proprietary Application Identifier Extension
POS Point of Service
pos. Position
PSE Payment System Environment
PTS Protocol Type Selection
EMV 4.2 Book 1 4 Abbreviations, Notations, Conventions, and Terminology
Application Independent ICC to 4.1 Abbreviations
Terminal Interface Requirements
June 2008 Page 25
R-APDU Response APDU
R-block Receive Ready Block
RFU Reserved for Future Use
RID Registered Application Provider Identifier
RSA Rivest, Shamir, Adleman Algorithm
RST Reset
SAD Source Node Address
S-block Supervisory Block
S
CA
Certification Authority Private Key
SDA Static Data Authentication
SFI Short File Identifier
SHA-1 Secure Hash Algorithm 1
S
I
Issuer Private Key
S
IC
ICC Private Key
SK Session Key for session key generation
SW1 Status Byte One
SW2 Status Byte Two
TAC Terminal Action Code(s) (Default, Denial, Online)
TAL Terminal Application Layer
TC Transaction Certificate
TCK Check Character
TDOL Transaction Certificate Data Object List
t
F
Fall Time Between 90% and 10% of Signal Amplitude
TLV Tag Length Value
TPDU Transport Protocol Data Unit
t
R
Rise Time Between 10% and 90% of Signal Amplitude
TS Initial Character
4 Abbreviations, Notations, Conventions, and Terminology EMV 4.2 Book 1
4.1 Abbreviations Application Independent ICC to
Terminal Interface Requirements
Page 26 June 2008
TSI Transaction Status Information
TTL Terminal Transport Layer
TVR Terminal Verification Results
UCOL Upper Consecutive Offline Limit
UL Underwriters Laboratories Incorporated
V Volt
var. Variable (see section 4.3)
V
CC
Voltage Measured on VCC Contact
VCC Supply Voltage
V
IH
High Level Input Voltage
V
IL
Low Level Input Voltage
V
OH
High Level Output Voltage
V
OL
Low Level Output Voltage
VPP Programming Voltage
V
PP
Voltage Measured on VPP contact
WI Waiting Time Integer
WTX Waiting Time Extension
WWT Work Waiting Time
YYMM Year, Month
YYMMDD Year, Month, Day
EMV 4.2 Book 1 4 Abbreviations, Notations, Conventions, and Terminology
Application Independent ICC to 4.2 Notations
Terminal Interface Requirements
June 2008 Page 27
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 s 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 s 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 (S
K
)[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 S
K

X = Recover(P
K
)[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 P
K

C := (A || B) The concatenation of an n-bit number A and an m-bit
number B, which is defined as C = 2
m
A + B.
4 Abbreviations, Notations, Conventions, and Terminology EMV 4.2 Book 1
4.2 Notations Application Independent ICC to
Terminal Interface Requirements
Page 28 June 2008
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.
Rightmost 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.
H := Hash[MSG] Hashing of a message MSG of arbitrary length using a
160-bit hash function
X © Y 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.
EMV 4.2 Book 1 4 Abbreviations, Notations, Conventions, and Terminology
Application Independent ICC to 4.3 Data Element Format Conventions
Terminal Interface Requirements
June 2008 Page 29
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 of Book 4.
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'.
4 Abbreviations, Notations, Conventions, and Terminology EMV 4.2 Book 1
4.3 Data Element Format Conventions Application Independent ICC to
Terminal Interface Requirements
Page 30 June 2008
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.
EMV 4.2 Book 1 4 Abbreviations, Notations, Conventions, and Terminology
Application Independent ICC to 4.4 Terminology
Terminal Interface Requirements
June 2008 Page 31
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

4 Abbreviations, Notations, Conventions, and Terminology EMV 4.2 Book 1
4.4 Terminology Application Independent ICC to
Terminal Interface Requirements
Page 32 June 2008

EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 33
Part II

Electromechanical Characteristics,
Logical Interface, and Transmission
Protocols
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page 34 June 2008
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 35
5 Electromechanical Interface
This section covers the electrical and mechanical characteristics of the ICC and
the terminal. ICC and terminal specifications differ to allow a safety margin to
prevent damage to the ICC.
The ICC characteristics defined herein are based on the ISO/IEC 7816 series of
standards with some small variations.
5 Electromechanical Interface EMV 4.2 Book 1
5.1 Lower Voltage ICC Migration Application Independent ICC to
Terminal Interface Requirements
Page 36 June 2008
5.1 Lower Voltage ICC Migration
A phased migration to lower voltage cards is underway. Cards that support
class A only are being phased out and shall be replaced by class AB or class ABC
cards by end December 2013. When all cards in use support class AB or class
ABC, it will be possible to deploy terminals that support class B only in addition
to class A only terminals. Refer to General Bulletin 11 on the EMVCo website at
http://www.emvco.com for details of the migration schedule.
Section 5 describes the requirements for cards and terminals as the transition
occurs. Differences are indicated using the notations shown in Table 1:

Notation Information applies: Values:
class A cards
until end
December
2013
to class A cards are permitted for cards in circulation
until end December 2013. From
January 2014, all cards in circulation
shall be either class AB or class ABC.
new card
values from
January 2014
to the following cards:
1

- class A (until end
December 2013)
- class AB
- class ABC
are permitted immediately and until
further notice. No class A cards shall
be in circulation from January 2014;
only class AB or class ABC cards shall
be in circulation from January 2014.
class A
terminals
until end
December
2013
to class A terminals
(or the class A
component of
multi-class terminals)
shall be used for class A terminals
until end December 2013. From
January 2014, there is no
requirement to update terminals
already in the field built using these
values.
new terminal
values from
January 2014
to class A, class B, and
class C terminals
shall not be used before end December
2013. From January 2014, shall be
used for new class A or class B
terminals.
Class C terminals shall not be
deployed until stated by EMVCo
(except for proprietary purposes
outside the scope of EMV).
Table 1: Lower Voltage Card Migration

1
Class B, class C, class AC, and class BC cards are not allowed.
EMV 4.2 Book 1 5 Electromechanical Interface
Application Independent ICC to 5.2 Mechanical Characteristics of the ICC
Terminal Interface Requirements
June 2008 Page 37
5.2 Mechanical Characteristics of the ICC
This section describes the physical characteristics, contact assignment, and
mechanical strength of the ICC.
5.2.1 Physical Characteristics
Except as otherwise specified herein, the ICC shall comply with the physical
characteristics for ICCs as defined in ISO/IEC 7816-1. The ICC shall also comply
with the additional characteristics defined in ISO/IEC 7816-1 as related to
ultraviolet light, X-rays, surface profile of the contacts, mechanical strength,
electromagnetic characteristics, and static electricity and shall continue to
function correctly electrically under the conditions defined therein.
5.2.1.1 Module Height
The highest point on the IC module surface shall not be greater than 0.10mm
above the plane of the card surface.
The lowest point on the IC module surface shall not be greater than 0.10mm
below the plane of the card surface.
5 Electromechanical Interface EMV 4.2 Book 1
5.2 Mechanical Characteristics of the ICC Application Independent ICC to
Terminal Interface Requirements
Page 38 June 2008
5.2.2 Dimensions and Location of Contacts
The dimensions and location of the contacts shall be as shown in Figure 1:

10.25 max
12.25 min
17.87 max
19.87 min
1
9
.
2
3

m
a
x
2
0
.
9
3

m
i
n
2
1
.
7
7

m
a
x
2
3
.
4
7

m
i
n
2
4
.
3
1

m
a
x
2
6
.
0
1

m
i
n
2
6
.
8
5

m
a
x
2
8
.
5
5

m
i
n
C1 C5
C2 C6
C3 C7
C4 C8
All dimensions
in millimetres
Upper Edge
L
e
f
t

E
d
g
e

Figure 1: ICC Contact Location and Dimensions
Areas C1, C2, C3, C5, and C7 shall be fully covered by conductive surfaces
forming the minimum ICC contacts. Areas C4, C6, C8, and areas Z1 to Z8 as
defined in ISO/IEC 7816-2 Annex B may optionally have conductive surfaces, but
it is strongly recommended that no conductive surfaces exist in areas Z1 to Z8. If
conductive surfaces exist in areas C6, and Z1 to Z8, they shall be electrically
isolated from the integrated circuit (IC), from one another, and from any other
contact area. (Electrically isolated means that the resistance measured between
the conductive surface and any other conductive surface shall be >10MO with an
applied voltage of 5V DC.) In addition, there shall be no connection between the
conductive surface of any area and the conductive surface of any other area,
other than via the IC. The minimum ICC contacts shall be connected to the IC
contacts as shown in Table 2.
EMV 4.2 Book 1 5 Electromechanical Interface
Application Independent ICC to 5.2 Mechanical Characteristics of the ICC
Terminal Interface Requirements
June 2008 Page 39
The layout of the contacts relative to embossing and/or magnetic stripe shall be
as shown in Figure 2:

Front of Card
Magnetic
Stripe
(Back of Card)
Embossing
Area
Mandatory
Contacts
Optional
Contacts

Figure 2: Layout of Contacts
Note: Care should be taken that card embossing does not damage the IC. Further,
positioning of the signature panel behind the IC may lead to damage due to heavy
pressure being applied during signature.
5.2.3 Contact Assignment
The assignment of the ICC contacts shall be as defined in ISO/IEC 7816-2 and is
shown in Table 2:

C1 Supply voltage (VCC) C5 Ground (GND)
C2 Reset (RST) C6 RFU
2

C3 Clock (CLK) C7 Input/output (I/O)
C4 Not used; need not be
physically present
C8 Not used; need not be
physically present
Table 2: ICC Contact Assignment

2
Defined in ISO/IEC 7816-3:1997 as programming voltage (VPP) for class A.
5 Electromechanical Interface EMV 4.2 Book 1
5.3 Electrical Characteristics of the ICC Application Independent ICC to
Terminal Interface Requirements
Page 40 June 2008
5.3 Electrical Characteristics of the ICC
This section describes the electrical characteristics of the signals as measured at
the ICC contacts.
5.3.1 Measurement Conventions
All measurements are made at the point of contact between the ICC and the
interface device (IFD) contacts and are defined with respect to the GND contact
over an ambient temperature range 0° C to 50° C. ICCs shall be capable of
correct operation over an ambient temperature range of at minimum 0° C to
50° C.
All currents flowing into the ICC are considered positive.
Note: The temperature range limits are dictated primarily by the thermal
characteristics of polyvinyl chloride (which is used for the majority of cards that are
embossed) rather than by constraints imposed by the characteristics of the IC.
5.3.2 Input/Output (I/O)
This contact is used as an input (reception mode) to receive data from the
terminal or as an output (transmission mode) to transmit data to the terminal.
During operation, the ICC and the terminal shall not both be in transmission
mode. In the event that this condition occurs, the state (voltage level) of the I/O
contact is indeterminate and no damage shall occur to the ICC.
EMV 4.2 Book 1 5 Electromechanical Interface
Application Independent ICC to 5.3 Electrical Characteristics of the ICC
Terminal Interface Requirements
June 2008 Page 41
5.3.2.1 Reception Mode
When in reception mode, and with the supply voltage (VCC) for the applicable
class in the range specified in section 5.3.6, the ICC shall correctly interpret
signals from the terminal having the characteristics shown in Table 3:

Symbol Conditions Minimum Maximum Unit
class A cards
until end
December
2013; see
Table 1
V
IH
0.7 x V
CC
V
CC
V
V
IL
0 0.8 V

t
R
and t
F
— 1.0 µs
The ICC shall not be damaged by signal perturbations on the I/O
line in the range –0.3 V to V
CC
+ 0.3 V.


Symbol Conditions Minimum Maximum Unit
new card
values from
January
2014; see
Table 1
V
IH
0.7 x V
CC
V
CC
V
V
IL
0 0.2 x V
CC
V

t
R
and t
F
— 1.0 µs
The ICC shall not be damaged by signal perturbations on the I/O
line in the range –0.3 V to V
CC
+ 0.3 V.

Table 3: Electrical Characteristics of I/O for ICC Reception
5 Electromechanical Interface EMV 4.2 Book 1
5.3 Electrical Characteristics of the ICC Application Independent ICC to
Terminal Interface Requirements
Page 42 June 2008
5.3.2.2 Transmission Mode
When in transmission mode, the ICC shall send data to the terminal with the
characteristics shown in Table 4:

Symbol Conditions Minimum Maximum Unit
class A
cards until
end
December
2013; see
Table 1
V
OH
–20 µA < I
OH
< 0,
V
CC
= min.
0.7 x V
CC
V
CC
V
V
OL
0 < I
OL
< 1 mA,
V
CC
= min.
0 0.4 V
t
R
and
t
F

C
IN (terminal)
=
30 pF max.
— 1.0 µs

Symbol Conditions Minimum Maximum Unit
new card
values
from
January
2014; see
Table 1
V
OH
–20 µA < I
OH
< 0 0.7 x V
CC
V
CC
V
V
OL
Class A:
0 < I
OL
< 1 mA
0 0.08 x
V
CC

V
Classes B and C:
0 < I
OL
< 0.5 mA
0 0.15 x
V
CC


t
R
and
t
F

C
IN (terminal)
=
30 pF max.
— 1.0 µs
Table 4: Electrical Characteristics of I/O for ICC Transmission
Unless transmitting, the ICC shall set its I/O line driver to reception mode. There
is no requirement for the ICC to have any current source capability to I/O.
5.3.3 Programming Voltage (VPP)
The ICC shall not require VPP (see note in section 5.4.3).
EMV 4.2 Book 1 5 Electromechanical Interface
Application Independent ICC to 5.3 Electrical Characteristics of the ICC
Terminal Interface Requirements
June 2008 Page 43
5.3.4 Clock (CLK)
With VCC in the range specified for the applicable class in section 5.3.6, the ICC
shall operate correctly with a CLK signal having the characteristics shown in
Table 5:

Symbol Conditions Minimum Maximum Unit
class A
cards
until end
December
2013; see
Table 1
V
IH
V
CC
– 0.7 V
CC
V
V
IL
0 0.5 V
t
R
and t
F
V
CC
= min. to
max.
— 9% of clock
period

The ICC shall not be damaged by signal perturbations on the CLK line
in the range –0.3 V to V
CC
+ 0.3 V.


Symbol Conditions Minimum Maximum Unit
new card
values
from
January
2014; see
Table 1
V
IH
0.7 x V
CC
V
CC
V

V
IL
0 0.2 x V
CC
V
t
R
and t
F
— 9% of clock
period

The ICC shall not be damaged by signal perturbations on the CLK line
in the range –0.3 V to V
CC
+ 0.3 V.

Table 5: Electrical Characteristics of CLK to ICC
The ICC shall operate correctly with a CLK duty cycle of between 44% and 56%
of the period during stable operation.
The ICC shall operate correctly with a CLK frequency in the range 1 MHz to
5 MHz.
Note: Frequency shall be maintained by the terminal to within ± 1% of that used
during the answer to reset throughout the card session.
5 Electromechanical Interface EMV 4.2 Book 1
5.3 Electrical Characteristics of the ICC Application Independent ICC to
Terminal Interface Requirements
Page 44 June 2008
5.3.5 Reset (RST)
With VCC in the range specified for the applicable class in section 5.3.6, the ICC
shall correctly interpret a RST signal having the characteristics shown in
Table 6:

Symbol Conditions Minimum Maximum Unit
class A
cards
until end
December
2013; see
Table 1
V
IH
V
CC
– 0.7 V
CC
V
V
IL
0 0.6 V
t
R
and t
F
V
CC
= min. to max. — 1.0 µs
The ICC shall not be damaged by signal perturbations on the RST line
in the range –0.3 V to V
CC
+ 0.3 V.


Symbol Conditions Minimum Maximum Unit
new card
values
from
January
2014; see
Table 1
V
IH
0.7 x V
CC
V
CC
V
V
IL
0 0.2 x V
CC
V
t
R
and t
F
V
CC
= min. to max. — 1.0 µs
The ICC shall not be damaged by signal perturbations on the RST line
in the range –0.3 V to V
CC
+ 0.3 V.

Table 6: Electrical Characteristics of RST to ICC
The ICC shall answer to reset asynchronously using active low reset.
EMV 4.2 Book 1 5 Electromechanical Interface
Application Independent ICC to 5.3 Electrical Characteristics of the ICC
Terminal Interface Requirements
June 2008 Page 45
5.3.6 Supply Voltage (VCC)
The ICC shall operate correctly with a supply voltage V
CC
of
5 V ± 0.5 V DC and have a maximum current requirement of
50 mA when operating at any frequency within the range specified
in section 5.3.4.

class A
cards
until end
December
2013; see
Table 1

Three classes of operation are defined based on the nominal supply
voltage applied to the ICC. These are defined in Table 7. The ICC
shall support class A and may optionally support one or more
additional consecutive classes. The ICC shall operate correctly on
any supply voltage lying within the range(s) specified for the
class(es) it supports.

Symbol Conditions Minimum Maximum Unit
V
CC
Class A
Class B
Class C
4.50
2.70
1.62
5.50
3.30
1.98
V
I
CC
Class A
Class B
Class C
50
50
30
mA
The maximum current consumptions shown apply when operating
at any frequency within the range specified in section 5.3.4.
Table 7: Classes of Operation

new card
values
from
January
2014; see
Table 1

5 Electromechanical Interface EMV 4.2 Book 1
5.3 Electrical Characteristics of the ICC Application Independent ICC to
Terminal Interface Requirements
Page 46 June 2008
The ICC shall not be damaged if it is operated under
classes that it does not support (the ICC is considered to
be damaged if it no longer operates as specified, or if it
contains corrupt data).
If the ICC supports more than one class, it may
optionally operate correctly on any supply voltage lying
between the ranges specified for the supported classes
(see Table 8 below).

Supported
Classes
ICC Shall
Operate
ICC May
Operate
Unit
A and B 4.50–5.50
2.70–3.30
3.30–4.50 V
A, B, and C 4.50–5.50
2.70–3.30
1.62–1.98
3.30–4.50
1.98–2.70
V
Table 8: Mandatory and Optional Operating Voltage
Ranges

new card values from
January 2014; see
Table 1
For proprietary reasons terminals may support the capability to negotiate with
the ICC the voltage class to be used, but this is outside the scope of EMV, and
there is no requirement for ICCs conforming to this specification to support such
negotiation. If the ICC returns a class indicator in the ATR as defined in
ISO/IEC 7816-3, the ATR may be rejected in an EMV compliant terminal. To
avoid interoperability problems, any class indicator used should be returned in
the cold ATR; to guarantee that the ICC will be accepted in the event that the
cold ATR is rejected, the warm ATR should be one of the basic ATRs defined in
section 8.

Note: It is strongly recommended that the current consumption of ICCs is maintained
at as low a value as possible, since the maximum current consumption allowable for the
ICC may be reduced in future versions of this specification. Issuers of ICCs bearing
multisector applications should ensure that the IC used has a current requirement
compatible with all terminals (from all sectors) in which the ICC might be used.
5.3.7 Contact Resistance
The contact resistance as measured across a pair of clean ICC and clean nominal
IFD contacts shall be less than 500 mO throughout the design life of an ICC (see
ISO/IEC 10373 for test method).
Note: A nominal IFD contact may be taken as a minimum of 1.25 µm of gold over
5.00 µm of nickel.
EMV 4.2 Book 1 5 Electromechanical Interface
Application Independent ICC to 5.4 Mechanical Characteristics of the Terminal
Terminal Interface Requirements
June 2008 Page 47
5.4 Mechanical Characteristics of the Terminal
This section describes the mechanical characteristics of the terminal interface
device.
5.4.1 Interface Device
The IFD into which the ICC is inserted shall be capable of accepting ICCs having
the following characteristics:
- Physical characteristics compliant with ISO/IEC 7816-1
- Contacts on the front, in the position compliant with Figure 2 of
ISO/IEC 7816-2
- Embossing compliant with ISO/IEC 7811-1 and ISO/IEC 7811-3
The IFD contacts shall be located such that if an ICC having contacts with the
dimensions and locations specified in Figure 3 is inserted into the IFD, correct
connection of all contacts shall be made. The IFD should have no contacts
present other than those needed to connect to ICC contacts C1 to C8.


Figure 3: Terminal Contact Location and Dimensions
Location guides and clamps (if used) should cause no damage to ICCs,
particularly in the areas of the magnetic stripe, signature panel, embossing, and
hologram.
Note: As a general principle, an ICC should be accessible to the cardholder at all times.
Where the ICC is drawn into the IFD, a mechanism should exist to return the ICC to the
cardholder in the event of a failure (for example, loss of power).
5 Electromechanical Interface EMV 4.2 Book 1
5.5 Electrical Characteristics of the Terminal Application Independent ICC to
Terminal Interface Requirements
Page 48 June 2008
5.4.2 Contact Forces
The force exerted by any one IFD contact on the corresponding ICC contact shall
be in the range 0.2 N to 0.6 N.
5.4.3 Contact Assignment
The assignment of the IFD contacts shall be as shown in Table 9:

C1 VCC C5 GND
C2 RST C6 Not used for class A
3

RFU for classes B and C
C3 CLK C7 I/O
C4 Not used; need not be
physically present
C8 Not used; need not be
physically present
Table 9: IFD Contact Assignment
5.5 Electrical Characteristics of the Terminal
This section describes the electrical characteristics of the signals as measured at
the IFD contacts.
5.5.1 Measurement Conventions
All measurements are made at the point of contact between the ICC and the IFD
contacts and are defined with respect to GND contact over an ambient
temperature range 5° C to 40° C unless otherwise specified by the manufacturer.
The internal temperature of the terminal should be limited to avoid damage to
ICCs.
All currents flowing out of the terminal are considered positive.

3
Defined in ISO/IEC 7816-3:1997 as programming voltage (VPP) for class A.
EMV 4.2 Book 1 5 Electromechanical Interface
Application Independent ICC to 5.5 Electrical Characteristics of the Terminal
Terminal Interface Requirements
June 2008 Page 49
5.5.2 Input/Output (I/O)
This contact is used as an output (transmission mode) to transmit data to the
ICC or as an input (reception mode) to receive data from the ICC. During
operation, the terminal and the ICC should not both be in transmission mode. In
the event that this condition occurs, the state (voltage level) of the contact is
indeterminate and no damage shall occur to the terminal.
When both the terminal and the ICC are in reception mode, the contact shall be
in the high state. The terminal shall not pull I/O high unless VCC is powered and
stable within the tolerances specified in section 5.5.6. See the contact activation
sequence specified in section 6.1.2.
The terminal shall limit the current flowing into or out of the I/O contact to
±15 mA at all times.
5 Electromechanical Interface EMV 4.2 Book 1
5.5 Electrical Characteristics of the Terminal Application Independent ICC to
Terminal Interface Requirements
Page 50 June 2008
5.5.2.1 Transmission Mode
When in transmission mode, the terminal shall send data to the ICC with the
characteristics shown in Table 10:

Symbol Conditions Minimum Maximum Unit
class A
terminals
until end
December
2013; see
Table 1
V
OH
0 < I
OH
< 20 µA,
V
CC
= min.
0.8 x V
CC
V
CC
V
V
OL
– 0.5 mA < I
OL
< 0,
V
CC
= min.
0 0.4 V
t
R
and t
F
C
IN(ICC)
= 30 pF
max.
— 0.8 µs
Signal
perturba-
tions
Signal low – 0.25 0.4 V
Signal high 0.8 x V
CC
V
CC
+
0.25
V

Symbol Conditions Minimum Maximum Unit
new
terminal
values
from
January
2014; see
Table 1
V
OH
0 < I
OH
< 20 µA 0.8 x V
CC
V
CC
V
V
OL
– 0.5 mA < I
OL
< 0 0 0.15 x
V
CC

V
t
R
and t
F
C
IN(ICC)
= 30 pF
max.
— 0.8 µs
Signal
perturba-
tions
Signal low – 0.25 0.15 x
V
CC

V
Signal high 0.8 x V
CC
V
CC
+
0.25
V
Table 10: Electrical Characteristics of I/O for Terminal Transmission
Unless transmitting, the terminal shall set its I/O line driver to reception mode.
EMV 4.2 Book 1 5 Electromechanical Interface
Application Independent ICC to 5.5 Electrical Characteristics of the Terminal
Terminal Interface Requirements
June 2008 Page 51
5.5.2.2 Reception Mode
When in reception mode, the terminal shall correctly interpret signals from the
ICC having the characteristics shown in Table 11:

Symbol Conditions Minimum Maximum Unit
class A
terminals
until end
December
2013; see
Table 1
V
IH
0.6 x V
CC
V
CC
V
V
IL
0 0.5 V
t
R
and t
F
— 1.2 µs

Symbol Conditions Minimum Maximum Unit new
terminal
values
from
January
2014; see
Table 1
V
IH
0.6 x V
CC
V
CC
V
V
IL
0 0.20 x V
CC
V
t
R
and t
F
— 1.2 µs
Table 11: Electrical Characteristics of I/O for Terminal Reception
5.5.3 Programming Voltage (VPP)
C6 shall be electrically isolated. Electrically isolated means that the resistance
measured between C6 and any other contact shall be >10MO with an applied
voltage of 5V DC. If connected in existing class A terminals, C6 shall be
maintained at a potential between GND and 1.05 x V
CC
throughout the card
session.
Note: Keeping C6 isolated in new class A terminals facilitates its use for other purposes
if so defined in future versions of this specification.
5 Electromechanical Interface EMV 4.2 Book 1
5.5 Electrical Characteristics of the Terminal Application Independent ICC to
Terminal Interface Requirements
Page 52 June 2008
5.5.4 Clock (CLK)
The terminal shall generate a CLK signal having the characteristics shown in
Table 12:

Symbol Conditions Minimum Maximum Unit
class A
terminals
until end
December
2013; see
Table 1
V
OH
0 < I
OH
< 50 µA,
V
CC
= min.
V
CC
– 0.5 V
CC
V
V
OL
– 50 µA < I
OL
< 0,
V
CC
= min.
0 0.4 V
t
R
and t
F
C
IN(ICC)
= 30 pF
max.
— 8% of
clock
period

Signal
perturba-
tions
Signal low – 0.25 0.4 V
Signal high V
CC
– 0.5 V
CC
+
0.25
V

Symbol Conditions Minimum Maximum Unit
new
terminal
values
from
January
2014; see
Table 1
V
OH
0 < I
OH
< 50 µA 0.8 x V
CC
V
CC
V
V
OL
– 50 µA < I
OL
< 0 0 0.15 x
V
CC

V
t
R
and t
F
C
IN(ICC)
= 30 pF
max.
— 8% of
clock
period

Signal
perturba-
tions
Signal low – 0.25 0.15 x
V
CC

V
Signal high 0.8 x V
CC
V
CC
+
0.25
V
Table 12: Electrical Characteristics of CLK from Terminal
Duty cycle shall be between 45% and 55% of the period during stable operation.
Frequency shall be in the range 1 MHz to 5 MHz and shall not change by more
than ± 1% throughout answer to reset and the following stages of a card session
(see section 6) unless changed following the answer to reset by means of a
proprietary negotiation technique.
EMV 4.2 Book 1 5 Electromechanical Interface
Application Independent ICC to 5.5 Electrical Characteristics of the Terminal
Terminal Interface Requirements
June 2008 Page 53
5.5.5 Reset (RST)
The terminal shall generate a RST signal having the characteristics shown in
Table 13:

Symbol Conditions Minimum Maximum Unit
class A
terminals
until end
December
2013; see
Table 1
V
OH
0 < I
OH
< 50 µA,
V
CC
= min.
V
CC
– 0.5 V
CC
V
V
OL
– 50 µA < I
OL
< 0,
V
CC
= min.
0 0.4 V
t
R
and t
F
C
IN(ICC)
= 30 pF
max.
— 0.8 µs
Signal
perturba-
tions
Signal low – 0.25 0.4 V
Signal high V
CC
– 0.5 V
CC
+
0.25
V

Symbol Conditions Minimum Maximum Unit
new
terminal
values
from
January
2014; see
Table 1
V
OH
0 < I
OH
< 50 µA 0.8 x V
CC
V
CC
V
V
OL
– 50 µA < I
OL
< 0 0 0.15 x
V
CC

V
t
R
and t
F
C
IN(ICC)
= 30 pF
max.
— 0.8 µs
Signal
perturba-
tions
Signal low – 0.25 0.15 x
V
CC

V
Signal high 0.8 x V
CC
V
CC
+
0.25
V
Table 13: Electrical Characteristics of RST from Terminal
5 Electromechanical Interface EMV 4.2 Book 1
5.5 Electrical Characteristics of the Terminal Application Independent ICC to
Terminal Interface Requirements
Page 54 June 2008
5.5.6 Supply Voltage (VCC)
The terminal shall generate a V
CC
of 5 V ± 0.4 V DC and shall be
capable of delivering steady state output current in the range
0 to 55 mA whilst maintaining V
CC
within these tolerances. The
supply shall be protected from transients and surges caused by
internal operation of the terminal and from external interference
introduced via power leads, communications links, etc. V
CC
shall
never be less than –0.25V with respect to ground.
During normal operation of an ICC, current pulses cause voltage
transients on VCC as measured at the ICC contacts. The power
supply shall be able to counteract transients in the current
consumption of the ICC having a charge s30 nAs, a duration
s400 ns, an amplitude s100 mA, and a rate of change of current
s1 mA/ns, ensuring that VCC remains within the range specified.
See Figure 4 for the maximum envelope of the pulse.

class A
terminals
until end
Decembe
r 2013;
see
Table 1
100 200 300 400 500 -100
20
40
60
80
100
120
-20
t(ns)
Icc(mA)


Figure 4: Maximum Current Pulse Envelope


EMV 4.2 Book 1 5 Electromechanical Interface
Application Independent ICC to 5.5 Electrical Characteristics of the Terminal
Terminal Interface Requirements
June 2008 Page 55
The terminal shall generate a V
CC
within one of the range(s)
specified in Table 14 below for the class(es) supported, and shall be
capable of delivering the corresponding steady state output
current whilst maintaining V
CC
within that range. If the terminal
supports more than one class, it shall always generate a V
CC
from
the class containing the highest voltage range available.
For proprietary reasons terminals may support the capability to
negotiate with the ICC the voltage class to be used, but this is
outside the scope of EMV, and is not supported by ICCs
conforming to this specification. Attempting class negotiation with
such an ICC may result in the ICC being rejected.
The supply shall be protected from transients and surges caused
by internal operation of the terminal and from external
interference introduced via power leads, communications links,
etc. V
CC
shall never be less than –0.25V with respect to ground.

Symbol Conditions Minimum Maximum Unit
V
CC
Class A
Class B
Class C
4.60
2.76
1.66
5.40
3.24
1.94
V
I
CC
Class A
Class B
Class C
55
55
35
mA
Table 14: Terminal Supply Voltage and Current

new
terminal
values
from
January
2014; see
Table 1
5 Electromechanical Interface EMV 4.2 Book 1
5.5 Electrical Characteristics of the Terminal Application Independent ICC to
Terminal Interface Requirements
Page 56 June 2008
During normal operation of an ICC, current pulses cause voltage
transients on VCC as measured at the ICC contacts. The power
supply shall be able to counteract transients in the current
consumption of the ICC having characteristics within the
maximum charge envelope applicable to the class of operation as
shown in Figure 5, ensuring that VCC remains within the range
specified.
100 200 300 400 500 -100
20
40
60
80
100
120
-20
t(ns)
Icc(mA)
Class A, 30 nAs max
Class B, 17.5 nAs max
Class C, 11.1 nAs max


new
terminal
values
from
January
2014; see
Table 1
Figure 5: Maximum Current Pulse Envelopes


Note: Terminals may be designed to be capable of delivering more than required
current, but it is recommended that terminals limit the steady state current that can be
delivered to a maximum of 200 mA.
5.5.7 Contact Resistance
The contact resistance as measured across a pair of clean IFD and clean nominal
ICC contacts shall be less than 500 mO throughout the design life of a terminal
(see ISO/IEC 7816-1 for test method).
Note: A nominal ICC contact may be taken as 1.25 µm of gold over 5.00 µm of nickel.
5.5.8 Short Circuit Resilience
The terminal shall not be damaged in the event of fault conditions such as a
short circuit between any combinations of contacts. The terminal shall be capable
of sustaining a short circuit of any duration between any or all contacts without
suffering damage or malfunction, for example, if a metal plate is inserted.
EMV 4.2 Book 1 5 Electromechanical Interface
Application Independent ICC to 5.5 Electrical Characteristics of the Terminal
Terminal Interface Requirements
June 2008 Page 57
5.5.9 Powering and Depowering of Terminal with ICC in Place
If the terminal is powered on or off with an ICC in place, all signal voltages shall
remain within the limits specified in section 5.5, and contact activation and
deactivation sequences and timings, as described in sections 6.1.2 and 6.1.5
respectively, shall be respected.
5 Electromechanical Interface EMV 4.2 Book 1
5.5 Electrical Characteristics of the Terminal Application Independent ICC to
Terminal Interface Requirements
Page 58 June 2008

EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 59
6 Card Session
This section describes all stages involved in a card session from insertion of the
ICC into the IFD through the execution of the transaction to the removal of the
ICC from the IFD.
6.1 Normal Card Session
This section describes the processes involved in the execution of a normal
transaction.
6.1.1 Stages of a Card Session
A card session is comprised of the following stages:
1. Insertion of the ICC into the IFD and connection and activation of the
contacts.
2. Reset of the ICC and establishment of communication between the
terminal and the ICC.
3. Execution of the transaction(s).
4. Deactivation of the contacts and removal of the ICC.
6 Card Session EMV 4.2 Book 1
6.1 Normal Card Session Application Independent ICC to
Terminal Interface Requirements
Page 60 June 2008
6.1.2 ICC Insertion and Contact Activation Sequence
On insertion of the ICC into the IFD, the terminal shall ensure that all signal
contacts are in state L with values of V
OL
as defined in section 5.5 and that V
CC

is 0.4 V or less at the instant galvanic contact is made. When the ICC is correctly
seated within the IFD, the contacts shall be activated as follows (see Figure 6):
- RST shall be maintained by the terminal in state L throughout the activation
sequence.
- Following establishment of galvanic contact but prior to activation of I/O or
CLK, VCC shall be powered.
- Following verification by the terminal that V
CC
is stable and within the limits
defined in section 5.5.6, the terminal shall set its I/O line driver to reception
mode and shall provide CLK with a suitable and stable clock as defined in
section 5.5.4. The I/O line driver in the terminal may be set to reception mode
prior to application of the clock but shall be set to reception mode no later
than 200 clock cycles after application of the clock.
Note: The terminal may verify the state of V
CC
by measurement, by waiting sufficient
time for it to stabilise according to the design of the terminal, or otherwise. The state of
the I/O line after the terminal has set its I/O line driver to reception mode is dependent
upon the state of the I/O line driver in the ICC (see section 6.1.3.1).

VCC
RST
CLK
I/O
Indeterminate
200cycles Cardinserted
here

Figure 6: Contact Activation Sequence
EMV 4.2 Book 1 6 Card Session
Application Independent ICC to 6.1 Normal Card Session
Terminal Interface Requirements
June 2008 Page 61
6.1.3 ICC Reset
The ICC shall answer to reset asynchronously using active low reset.
The means of transportation of the answer to reset (ATR) are described in
section 7 and its contents are described in sections 8.2 and 8.3.
6.1.3.1 Cold Reset
Following activation of the contacts according to section 6.1.2, the terminal shall
initiate a cold reset and obtain an ATR from the ICC as follows (see Figure 7):
- The terminal shall apply CLK at a notional time T0.
- Within a maximum of 200 clock cycles following T0, the ICC shall set its
I/O line driver to reception mode. Since the terminal shall also have set its
I/O line driver to reception mode within this period, the I/O line is guaranteed
to be in state H no later than 200 clock cycles following time T0.
- The terminal shall maintain RST in state L through time T0 and for a period
of between 40,000 and 45,000 clock cycles following time T0 to time T1, when
it shall set RST to state H.
- The answer to reset on I/O from the ICC shall begin between 400 and 40,000
clock cycles after time T1 (time t1 in Figure 7).
- The terminal shall have a reception window which is opened no later than
380 clock cycles after time T1 and closed no earlier than 42,000 clock cycles
after time T1 (time t1 in Figure 7). If no answer to reset is received from the
ICC, the terminal shall initiate the deactivation sequence no earlier than
42,001 clock cycles after time T1, and no later than 42,000 clock cycles plus
50ms after time T1.

VCC
RST
CLK
I/O
T0 T1
t1
Indeterminate Answer toReset
200cycles

Figure 7: Cold Reset Sequence
6 Card Session EMV 4.2 Book 1
6.1 Normal Card Session Application Independent ICC to
Terminal Interface Requirements
Page 62 June 2008
6.1.3.2 Warm Reset
If the ATR received following a cold reset as described in section 6.1.3.1 does not
conform to the specification in section 8, the terminal shall initiate a warm reset
and obtain an ATR from the ICC as follows (see Figure 8):
- A warm reset shall start at a notional time T0', at which time the terminal
shall set RST to state L.
- The terminal shall maintain VCC and CLK stable and within the limits
defined in sections 5.5.4 and 5.5.6 throughout the warm reset sequence.
- Within a maximum of 200 clock cycles following T0', the ICC and terminal
shall set their I/O line drivers to reception mode. The I/O line therefore is
guaranteed to be in state H no later than 200 clock cycles following time T0'.
- The terminal shall maintain RST in state L from time T0' for a period of
between 40,000 and 45,000 clock cycles following time T0' to time T1', when it
shall set RST to state H.
- The answer to reset on I/O from the ICC shall begin between 400 and 40,000
clock cycles after time T1' (time t1' in Figure 8).
- The terminal shall have a reception window which is opened no later than
380 clock cycles after time T1' and closed no earlier than 42,000 clock cycles
after time T1' (time t1' in Figure 8). If no answer to reset is received from the
ICC, the terminal shall initiate the deactivation sequence no earlier than
42,001 clock cycles after time T1', and no later than 42,000 clock cycles plus
50ms after time T1'.

VCC
RST
CLK
T0' T1'
t1'
Indeterminate Answer toReset
200cycles
I/O

Figure 8: Warm Reset Sequence
Note: Figure 8 indicates that the terminal may initiate the warm reset sequence during
the time that the card is still transmitting the cold ATR, and in the event that it does,
the card shall be able to respond correctly with the warm ATR.
EMV 4.2 Book 1 6 Card Session
Application Independent ICC to 6.1 Normal Card Session
Terminal Interface Requirements
June 2008 Page 63
6.1.4 Execution of a Transaction
Selection of the application in the ICC and the subsequent exchange of
information between the ICC and the terminal necessary to perform a
transaction are described in section 12 and in Book 3.
6.1.5 Contact Deactivation Sequence
As the final step in the card session, upon normal or abnormal termination of the
transaction (including withdrawal of the ICC from the IFD during a card
session), the terminal shall deactivate the IFD contacts as follows (see Figure 9):
- The terminal shall initiate the deactivation sequence by setting RST to
state L.
- Following the setting of RST to state L but prior to depowering VCC, the
terminal shall set CLK and I/O to state L.
- Following the setting of RST, CLK, and I/O to state L but prior to galvanic
disconnection of the IFD contacts, the terminal shall depower VCC. V
CC
shall
be 0.4 V or less prior to galvanic disconnection of the IFD contacts.
- The deactivation sequence shall be completed within 100 ms. This period is
measured from the time that RST is set to state L to the time that V
CC

reaches 0.4 V or less.

VCC
RST
CLK
Indeterminate
Cardremoved
here
I/O

Figure 9: Contact Deactivation Sequence
6 Card Session EMV 4.2 Book 1
6.2 Abnormal Termination of Transaction Process Application Independent ICC to
Terminal Interface Requirements
Page 64 June 2008
6.2 Abnormal Termination of Transaction Process
If an ICC is prematurely removed from a terminal during execution of a
transaction at speeds of up to 1 m/s, the terminal shall be capable of sensing the
movement of the ICC relative to the IFD contacts, and of deactivating all IFD
contacts in the manner described in section 6.1.5 before the relative movement
exceeds 1 mm. No electrical or mechanical damage shall be caused to the ICC
under these conditions.
Note: For ‗sliding carriage‘ type IFDs, it may be possible for the terminal to sense the
movement of the ICC/IFD contact sub-assembly relative to the main body of the IFD. In
this event, it is not mandatory to be able to sense the movement of the ICC relative to
the IFD contacts, but deactivation of the contacts shall be complete before any electrical
contact is broken between the ICC and IFD.
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 65
7 Physical Transportation of Characters
During the transaction process, data is passed bi-directionally between the
terminal and the ICC over the I/O line in an asynchronous half duplex manner. A
clock signal is provided to the ICC by the terminal, and this shall be used to
control the timing of this exchange. The mechanism of exchanging bits and
characters is described below. It applies during the answer to reset and is also
used by both transmission protocols as described in section 9.
7.1 Bit Duration
The bit duration used on the I/O line is defined as an elementary time unit (etu).
A linear relationship exists between the etu on the I/O line and CLK
frequency (f).
During the answer to reset, the bit duration is known as the initial etu, and is
given by the following equation:
initial etu
372
=
f
seconds, where f is in Hertz

Following the answer to reset (and establishment of the global parameters
F and D, as described in section 8), the bit duration is known as the current etu,
and is given by the following equation:
current etu
F
D
=
f
seconds, where f is in Hertz

Note: For the basic answer(s) to reset described in this specification, only values of
F = 372 and D = 1 are supported. In the following sections, ―etu‖ indicates current etu
unless otherwise specified.
7 Physical Transportation of Characters EMV 4.2 Book 1
7.2 Character Frame Application Independent ICC to
Terminal Interface Requirements
Page 66 June 2008
7.2 Character Frame
Data is passed over the I/O line in a character frame as described below. The
convention used is specified in the initial character (TS) transmitted by the ICC
in the ATR (see section 8.3.1).
Prior to transmission of a character, the I/O line shall be in state H.
A character consists of 10 consecutive bits (see Figure 10):
- 1 start bit in state L
- 8 bits, which comprise the data byte
- 1 even parity checking bit
The start bit is detected by the receiving end by periodically sampling the I/O
line. The sampling time should be less than or equal to 0.2 etu.
The number of logic ones in a character shall be even. The 8 bits of data and the
parity bit itself are included in this check but the start bit is not.
The time origin is fixed as midway between the last observation of state H and
the first observation of state L. The existence of a start bit should be verified
within 0.7 etu. Subsequent bits should be received at intervals of (n + 0.5 ±
0.2) etu (n being the rank of the bit). The start bit is bit 1.
Within a character, the time from the leading edge of the start bit to the trailing
edge of the nth bit is (n ± 0.2) etu.
The interval between the leading edges of the start bits of two consecutive
characters is comprised of the character duration (10 ± 0.2) etu, plus a
guardtime. Under error free transmission, during the guardtime both the ICC
and the terminal shall be in reception mode (I/O line in state H). For T=0 only, if
the ICC or terminal as receiver detects a parity error in a character just received,
it shall set I/O to state L to indicate the error to the sender (see section 9.2.3).
H
L
Start
Parity
Start
8 data bits
Guardtime
Character Duration
10 ± 0.2 etu
I/O

Figure 10: Character Frame
At the terminal transport layer (TTL), data shall always be passed over the I/O
line most significant (m.s.) byte first. The order of bits within a byte (that is,
whether the least significant (l.s.) or m.s. bit is transferred first) is specified in
character TS returned in the answer to reset (see section 8.3).
EMV 4.2 Book 1 7 Physical Transportation of Characters
Application Independent ICC to 7.2 Character Frame
Terminal Interface Requirements
June 2008 Page 67
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 69
8 Answer to Reset
After being reset by the terminal as described in section 6.1.3, the ICC answers
with a string of bytes known as the ATR. These bytes convey information to the
terminal that defines certain characteristics of the communication to be
established between the ICC and the terminal. The method of transporting these
bytes, and their meaning, is described below.
Note: In sections 8 and 9, the m.s. bit of a character refers to bit b8 and the l.s. bit
refers to bit b1. A value in straight single quotes is coded in hexadecimal notation; for
example, 'A' or '3F'.
8.1 Physical Transportation of Characters Returned
at Answer to Reset
This section describes the structure and timing of the characters returned at the
answer to reset.
The bit duration is defined in section 7.1, and the character frame is defined in
section 7.2.
During the answer to reset, the minimum interval between the leading edges of
the start bits of two consecutive characters shall be 12 initial etus, and the
maximum interval between the leading edges of the start bits of two consecutive
characters shall be 9600 initial etus.
The ICC shall transmit all the characters to be returned during an answer to
reset (warm or cold) within 19,200 initial etus.
4
This time is measured between
the leading edge of the start bit of the first character (TS) and 12 initial etus
after the leading edge of the start bit of the last character.

4
The maximum time allowed for the answer to reset varies according to clock
frequency, since the period represented by an etu is frequency dependent (see section
7.1).
8 Answer to Reset EMV 4.2 Book 1
8.2 Characters Returned by ICC at Answer to Reset Application Independent ICC to
Terminal Interface Requirements
Page 70 June 2008
8.2 Characters Returned by ICC at Answer to Reset
The number and coding of the characters returned by the ICC at the answer to
reset varies depending upon the transmission protocol(s) and the values of the
transmission control parameters supported. This section describes two basic
answers to reset, one for ICCs supporting T=0 only and the other for ICCs
supporting T=1 only. It defines the characters to be returned and the allowable
ranges of values for the transmission control parameters. ICCs returning one of
the two answers to reset described here are assured correct operation and
interoperability in terminals conforming to this specification.
For proprietary reasons ICCs may optionally support more than one
transmission protocol, but one of the supported protocols shall be T=0 or T=1.
The first offered protocol shall be T=0 or T=1, and the terminal shall continue the
card session using the first offered protocol unless for proprietary reasons it
supports a mechanism for selecting an alternative protocol offered by the ICC.
Support for such a mechanism is not required by, and is beyond the scope of
these specifications.
Note: This specification does not support ICCs having both T=0 and T=1 protocols
present at the same time. This can only be achieved by proprietary means beyond the
scope of this specification.
Also for proprietary reasons ICCs may optionally support other values of the
transmission control parameters at the issuer‘s discretion. However, such
support is considered outside the scope of this specification and such ICCs may be
rejected at terminals conforming to this specification, which need not have the
corresponding additional proprietary functionality required to support the ICC.
The characters returned by the ICC at the answer to reset for the two basic
answers to reset are shown in Table 15 and Table 16. The characters are shown
in the order in which they are sent by the ICC, that is, TS first.
If protocol type T=0 only is supported (character-oriented asynchronous
transmission protocol), the characters returned shall be as shown in Table 15:

Character Value Remarks
TS '3B' or '3F' Indicates direct or inverse convention
T0 '6x' TB1 and TC1 present; x indicates the
number of historical bytes present
TB1 '00' VPP not required
TC1 '00' to 'FF' Indicates the amount of extra guardtime
required. Value 'FF' has a special
meaning (see section 8.3.3.3)
Table 15: Basic ATR for T=0 Only
EMV 4.2 Book 1 8 Answer to Reset
Application Independent ICC to 8.2 Characters Returned by ICC at Answer to Reset
Terminal Interface Requirements
June 2008 Page 71
If protocol type T=1 only is supported (block-oriented asynchronous transmission
protocol), the characters returned shall be as shown in Table 16:

Character Value Remarks
TS '3B' or '3F' Indicates direct or inverse convention
T0 'Ex' TB1 to TD1 present; x indicates the
number of historical bytes present
TB1 '00' VPP not required
TC1 '00' to 'FF' Indicates amount of extra guardtime
required. Value 'FF' has special meaning
(see section 8.3.3.3)
TD1 '81' TA2, TB2, and TC2 absent; TD2
present; T=1 to be used
TD2 '31' TA3 and TB3 present; TC3 and TD3
absent; T=1 to be used
TA3 '10' to 'FE' Returns IFSI, which indicates initial
value for information field size for the
ICC and IFSC of 16–254 bytes
TB3 m.s. nibble '0' to '4'
l.s. nibble '0' to '5'
BWI = 0 to 4
CWI = 0 to 5
TCK See section 8.3.4 Check character
Table 16: Basic ATR for T=1 Only
8 Answer to Reset EMV 4.2 Book 1
8.3 Character Definitions Application Independent ICC to
Terminal Interface Requirements
Page 72 June 2008
8.3 Character Definitions
This section provides detailed descriptions of the characters that may be
returned at the answer to reset.
Each character description includes the following information:
- title
- explanation of usage as described in ISO/IEC 7816-3
- basic response (This response should always be used in a warm ATR to
ensure interoperability.)
- required terminal behaviour in the event that a terminal receives characters
outside the range allowed by EMV
The ‗basic response‘ indicates the presence or absence of the character, and the
allowable range of values it may take (if present) if it is to conform to one of the
basic ATRs. The description of a basic response (even though indicated by ‗shall‘)
is not intended to preclude the use of other values of the characters, nor the
omission/inclusion of a character at the issuer‘s discretion. For example, the ICC
may return additional characters if it supports more than one transmission
protocol (see section 9). However, only ICCs returning a basic ATR, or an ATR
supported by the minimum required terminal functionality described below, are
guaranteed to be supported correctly in interchange.
Terminals conforming to this specification are only required (as a minimum) to
support the basic ATRs described here together with any additional
requirements specified in ‗terminal behaviour‘. Terminals may thus reject an
ATR containing interface bytes not described in, or having values not specified
in, this specification. However, terminals may correctly interpret such an ATR if
it is returned by an ICC for proprietary (for example, national) use. Such
terminal functionality is not mandatory and is beyond the scope of this
specification. As a general principle, a terminal should accept a non-basic ATR if
it is able to function correctly with it.
Terminals shall be capable of checking the parity of characters returned in the
answer to reset, but not necessarily as they are received. If the terminal detects a
parity error, it shall reject the ICC.
EMV 4.2 Book 1 8 Answer to Reset
Application Independent ICC to 8.3 Character Definitions
Terminal Interface Requirements
June 2008 Page 73
Table 17 describes the action indicated by several terms in the following
character descriptions:

If it is indicated that a
terminal shall:
then:
reject an ATR - If the terminal is rejecting a cold ATR, the
terminal shall issue a warm reset.
- If the terminal is rejecting a warm ATR, the
terminal shall terminate the card session by
deactivating the ICC contacts.
reject an ICC The terminal shall terminate the card session by
deactivating the ICC contacts.
accept an ATR The terminal shall accept the ATR, but only if the
requirements specified in this section for all other
characters are also met.
Table 17: Terminal Behaviour
8.3.1 TS - Initial Character
TS performs two functions. It provides a known bit pattern to the terminal to
facilitate bit synchronisation, and it indicates the logic convention to be used for
the interpretation of the subsequent characters.
Using inverse logic convention, a low state L on the I/O line is equivalent to a
logic one, and the m.s. bit of the data byte is the first bit sent after the start bit.
Using direct logic convention, a high state H on the I/O line is equivalent to a
logic one, and the l.s. bit of the data byte is the first bit sent after the start bit.
The first four bits LHHL are used for bit synchronisation.
Basic responses: The ICC shall return an ATR containing TS having one of two
values:
- (H)LHHLLLLLLH inverse convention value '3F'
- (H)LHHLHHHLLH direct convention value '3B'
The convention used may differ between cold and warm resets.
Terminal behaviour: The terminal shall be capable of supporting both inverse
and direct convention and shall accept an ATR containing TS having a value of
either '3B' or '3F'. An ICC returning an ATR containing TS having any other
value shall be rejected.
Note: It is strongly recommended that a value of '3B' is returned by the ICC since a
value of '3F' may not be supported in future versions of this specification.
8 Answer to Reset EMV 4.2 Book 1
8.3 Character Definitions Application Independent ICC to
Terminal Interface Requirements
Page 74 June 2008
8.3.2 T0 - Format Character
T0 is comprised of two parts. The m.s. nibble (b5–b8) is used to indicate whether
the subsequent characters TA1 to TD1 are present. Bits b5–b8 are set to the
logic one state to indicate the presence of TA1 to TD1, respectively. The l.s.
nibble (b1–b4) indicates the number of optional historical bytes present (0 to 15).
(See Table 18 for the basic response coding of character T0.)
Basic responses: If T=0 only is to be used, the ATR shall contain T0 = '6x',
indicating that characters TB1 and TC1 are present. If T=1 only is to be used,
the ATR shall contain T0 = 'Ex', indicating that characters TB1 to TD1 are
present. The value of 'x' represents the number of optional historical bytes to be
returned.
5

Terminal behaviour: The terminal shall accept an ATR containing T0 of any
value provided that the value returned correctly indicates and is consistent with
the interface characters TA1 to TD1 and historical bytes actually returned.

b8 b7 b6 b5 b4 b3 b2 b1
T=0 only 0 1 1 0 x x x x
T=1 only 1 1 1 0 x x x x
Table 18: Basic Response Coding of Character T0
8.3.3 TA1 to TC3 - Interface Characters
TA1 to TC3 convey information that shall be used during exchanges between the
terminal and the ICC subsequent to the answer to reset. They indicate the
values of the transmission control parameters F, D, I, P, and N, and the IFSC,
block waiting time integer (BWI), and character waiting time integer (CWI)
applicable to T=1 as defined in ISO/IEC 7816-3. The information contained in
TA1, TB1, TC1, TA2, and TB2 shall apply to all subsequent exchanges
irrespective of the protocol type to be used.

5
Although their use is not forbidden, the EMV Specifications do not explicitly support
the use of historical bytes, and their usage, structure and meaning are outside the scope
of EMV. However, if used, it is strongly recommended that they are encoded to have a
structure and meaning according to ISO/IEC 7816-4. EMV-compliant terminals should
ignore any historical bytes present in the ATR. However, if an EMV-compliant terminal
does support historical bytes, it should never be designed in such a way that non-
recognition or misinterpretation of any historical bytes present in the ATR causes
termination of the transaction. Since Issuers are free to encode the historical bytes in
any way they choose, they should recognise that unintentional conflict of coding between
cards may exist, leading to misinterpretation at terminals. Great care should be
exercised by the terminal that it is able to unambiguously identify a card before
interpreting any historical bytes returned in the ATR.
EMV 4.2 Book 1 8 Answer to Reset
Application Independent ICC to 8.3 Character Definitions
Terminal Interface Requirements
June 2008 Page 75
8.3.3.1 TA1
TA1 conveys the values of FI and DI where:
- the m.s. nibble FI is used to determine the value of F, the clock rate
conversion factor, which may be used to modify the frequency of the clock
provided by the terminal subsequent to the answer to reset
- the l.s. nibble DI is used to determine the value of D, the bit rate adjustment
factor, which may be used to adjust the bit duration used subsequent to the
answer to reset
See section 7.1 for calculation of the bit duration subsequent to the answer to
reset (current etu).
Default values of FI = 1 and DI = 1 indicating values of F = 372 and D = 1,
respectively, shall be used during the answer to reset.
Basic response: The ATR shall not contain TA1 and thus the default values of
F = 372 and D = 1 shall continue be used during all subsequent exchanges.
Terminal behaviour: If TA1 is present in the ATR (indicated by b5 of T0 set to 1)
and TA2 is returned with b5 = 0 (specific mode, parameters defined by the
interface bytes), the terminal shall:
- Accept the ATR if the value of TA1 is in the range '11' to '13',
6
and
immediately implement the values of F and D indicated (F=372 and
D = 1, 2, or 4).
- Reject the ATR if the value of TA1 is not in the range '11' to '13', unless it is
able to support and immediately implement the conditions indicated.
If TA1 is present in the ATR (indicated by b5 of T0 set to 1) and TA2 is not
returned (negotiable mode), the terminal shall accept the ATR and shall continue
using the default values of D = 1 and F = 372 during all subsequent exchanges,
unless it supports a proprietary technique for negotiating the parameters to be
used.
If TA1 is absent from the ATR, the default values of D = 1 and F = 372 shall be
used during all subsequent exchanges.

6
Terminals compliant to version 3.1.1 of the EMV Specifications may reject an ATR (not
an ICC) if TA1 is present and coded other than '11'. ATRs indicating the higher
allowable values of D will include TA1 coded '12' or '13', and thus may be rejected in
3.1.1 compliant terminals. Therefore, to ensure that an ICC supporting higher data
transfer rates is always accepted in 3.1.1 compliant terminals (albeit operating at basic
data transfer rates), it is essential that any TA1 indicating higher data rates is present
in the cold ATR only, and that a warm ATR is always present which either does not
contain TA1, or includes a TA1 having the value '11'.
8 Answer to Reset EMV 4.2 Book 1
8.3 Character Definitions Application Independent ICC to
Terminal Interface Requirements
Page 76 June 2008
8.3.3.2 TB1
TB1 conveys the values of PI1 and II where:
- PI1 is specified in bits b1 to b5 and is used to determine the value of the
programming voltage P required by the ICC. PI1 = 0 indicates that VPP is
not connected in the ICC.
- II is specified in bits b6 and b7 and is used to determine the maximum
programming current, I
pp
, required by the ICC. This parameter is not used if
PI1 = 0.
- Bit 8 is not used and shall be set to logic zero.
Basic response: The ATR shall contain TB1 = '00', indicating that VPP is not
connected in the ICC.
Terminal behaviour: In response to a cold reset, the terminal shall accept only
an ATR containing TB1 = '00'. In response to a warm reset the terminal shall
accept an ATR containing TB1 of any value (provided that b6 of T0 is set to 1) or
not containing TB1 (provided that b6 of T0 is set to 0) and shall continue the card
session as though TB1 = '00' had been returned. V
PP
shall never be generated.
Note: Existing terminals may maintain V
PP
in the idle state (see section 5.4.3).
The basic response coding of character TB1 is shown in Table 19:

b8 b7 b6 b5 b4 b3 b2 b1
0 0 0 0 0 0 0 0
Table 19: Basic Response Coding of Character TB1
EMV 4.2 Book 1 8 Answer to Reset
Application Independent ICC to 8.3 Character Definitions
Terminal Interface Requirements
June 2008 Page 77
8.3.3.3 TC1
TC1 conveys the value of N, where N is used to indicate the extra guardtime that
shall be added to the minimum duration between the leading edges of the start
bits of two consecutive characters for subsequent exchanges from the terminal to
the ICC. N is binary coded over bits b1–b8 of TC1, and its value represents the
number of etus to be added as extra guardtime. TC1='FF' has a special meaning
and indicates that the minimum delay between the leading edges of the start bits
of two consecutive characters shall be reduced to 12 etus if T=0 is to be used, or
11 etus if T=1 is to be used.
Note: TC1 applies only to the timing between two consecutive characters sent from the
terminal to the ICC. It does not apply to the timing between consecutive characters sent
from the ICC to the terminal, nor does it apply to the timing between two characters
sent in opposite directions (see sections 9.2.2.1 and 9.2.4.2.2).
N may take any value between 0 and 255.
If the value of TC1 is in the range '00' to 'FE', between 0 and 254 etus of extra
guardtime shall be added to the minimum character to character duration, which
for subsequent transmissions shall be between 12 and 266 etus.
If the value of TC1 = 'FF', then the minimum character to character duration for
subsequent transmissions shall be 12 etus if T=0 is to be used, or 11 etus if T=1
is to be used.
Basic response: The ATR shall contain TC1 having a value in the range '00' to
'FF'.
Terminal behaviour: The terminal shall accept an ATR not containing TC1
(provided that b7 of T0 is set to 0), and shall continue the card session as though
TC1 = '00' had been returned.
The basic response coding of character TC1 is shown in Table 20:

b8 b7 b6 b5 b4 b3 b2 b1
x x x x x x x x
Table 20: Basic Response Coding of Character TC1
Note: It is strongly recommended that the value of TC1 be set to the minimum
acceptable for the ICC. Large values of TC1 lead to very slow communication between
the terminal and the ICC, and thus lengthy transaction times.
8 Answer to Reset EMV 4.2 Book 1
8.3 Character Definitions Application Independent ICC to
Terminal Interface Requirements
Page 78 June 2008
8.3.3.4 TD1
TD1 indicates whether any further interface bytes are to be transmitted and
information concerning the protocol type(s) where:
- The m.s. nibble is used to indicate whether the characters TA2 to TD2 are
present. These bits (b5–b8) are set to the logic one state to indicate the
presence of TA2 to TD2 respectively.
- The l.s. nibble provides information concerning the protocol type(s) to be used
for subsequent exchanges.
Basic responses: The ATR shall not contain TD1 if T=0 only is to be used, and
protocol type T=0 shall be used as a default for all subsequent transmissions. The
ATR shall contain TD1 = '81' if T=1 only is to be used, indicating that TD2 is
present and that protocol type T=1 shall be used for all subsequent
transmissions.
Terminal behaviour: The terminal shall accept an ATR containing TD1 with the
m.s. nibble having any value (provided that the value returned correctly
indicates and is consistent with the interface characters TA2 to TD2 actually
returned), and the l.s. nibble having a value of '0' or '1'. The terminal shall reject
an ATR containing other values of TD1.
The basic response coding of character TD1 is shown in Table 21:

b8 b7 b6 b5 b4 b3 b2 b1
T=1 1 0 0 0 0 0 0 1
Table 21: Basic Response Coding of Character TD1
EMV 4.2 Book 1 8 Answer to Reset
Application Independent ICC to 8.3 Character Definitions
Terminal Interface Requirements
June 2008 Page 79
8.3.3.5 TA2
The presence or absence of TA2 indicates whether the ICC will operate in specific
mode or negotiable mode respectively following the answer to reset. When
present, TA2 conveys information regarding the specific mode of operation where:
- b8 indicates whether the ICC is capable of changing its mode of operation. It
is capable of changing if b8 is set to 0, and unable to change if b8 is set to 1.
- b7–b6 are RFU (set to 00).
- b5 indicates whether the transmission parameters to be used following
Answer to Reset are defined in the interface characters or are implicitly
known by the terminal. The transmission parameters are defined by the
interface characters if b5 is set to 0, or are implicitly known by the terminal if
b5 is set to 1.
- l.s. nibble b4-b1 indicates the protocol to be used in specific mode.
Basic response: The ATR shall not contain TA2; the absence of TA2 indicates the
negotiable mode of operation.
Terminal behaviour: The terminal shall accept an ATR containing TA2 provided
that all the following conditions are met:
- The protocol indicated in the l.s. nibble is also the first indicated protocol in
the ATR.
- b5 = 0
- The terminal is able to support the exact conditions indicated in the
applicable interface characters and immediately uses those conditions.
Otherwise, the terminal shall reject an ATR containing TA2.
8.3.3.6 TB2
TB2 conveys PI2, which is used to determine the value of programming voltage P
required by the ICC. When present it overrides the value indicated by PI1
returned in TB1.
Basic response: The ATR shall not contain TB2.
Terminal behaviour: The terminal shall reject an ATR containing TB2.
Note: Existing terminals may maintain VPP in the idle state (see section 5.4.3).
8 Answer to Reset EMV 4.2 Book 1
8.3 Character Definitions Application Independent ICC to
Terminal Interface Requirements
Page 80 June 2008
8.3.3.7 TC2
TC2 is specific to protocol type T=0 and conveys the work waiting time integer
(WI) that is used to determine the maximum interval between the leading edge
of the start bit of any character sent by the ICC and the leading edge of the start
bit of the previous character sent either by the ICC or the terminal (the work
waiting time). The work waiting time is given by 960 x D x WI.
Basic response: The ATR shall not contain TC2 and a default value of WI = 10
shall be used during subsequent communication.
Terminal behaviour: The terminal shall:
- reject an ATR containing TC2 = '00'
- accept an ATR containing TC2 = '0A'
- reject an ATR containing TC2 having any other value unless it is able to
support it.
8.3.3.8 TD2
TD2 indicates whether any further interface bytes are to be transmitted and the
protocol type to be used for subsequent transmissions, where:
- The m.s. nibble is used to indicate whether the characters TA3 to TD3 are
present. These bits (b5–b8) are set to the logic one state to indicate the
presence of TA3 to TD3, respectively.
- The l.s. nibble indicates the protocol type to be used for subsequent
exchanges. It shall take the value '1' as T=1 is to be used.
Basic responses: The ATR shall not contain TD2 if T=0 is to be used, and the
protocol type T=0 shall be used as a default for all subsequent transmissions. The
ATR shall contain TD2 = '31' if T=1 is to be used, indicating that TA3 and TB3
are present and that protocol type T=1 shall be used for all subsequent
transmissions.
Terminal behaviour: The terminal shall accept an ATR containing TD2 with the
m.s. nibble having any value (provided that the value returned correctly
indicates and is consistent with the interface characters TA3 to TD3 actually
returned), and the l.s. nibble having a value of '1' (or 'E' if the l.s. nibble of TD1 is
'0'). The terminal shall reject an ATR containing other values of TD2.
The basic response coding of character TD2 is shown in Table 22:

b8 b7 b6 b5 b4 b3 b2 b1
T=1 0 0 1 1 0 0 0 1
Table 22: Basic Response Coding of Character TD2
EMV 4.2 Book 1 8 Answer to Reset
Application Independent ICC to 8.3 Character Definitions
Terminal Interface Requirements
June 2008 Page 81
8.3.3.9 TA3
TA3 (if T=1 is indicated in TD2) returns the information field size integer for the
ICC (IFSI), which determines the IFSC, and specifies the maximum length of the
information field (INF) of blocks that can be received by the card. It represents
the length of IFSC in bytes and may take any value between '01' and 'FE'.
Values of '00' and 'FF' are reserved for future use.
Basic response: If T=1 is to be used, the ATR shall contain TA3 having a value in
the range '10' to 'FE' indicating an initial IFSC in the range 16 to 254 bytes.
Terminal behaviour: The terminal shall accept an ATR not containing TA3
(provided that b5 of TD2 is set to 0), and shall continue the card session using a
value of '20' for TA3. The terminal shall reject an ATR containing TA3 having a
value in the range '00' to '0F' or a value of 'FF'.
The basic response coding of character TA3 is shown in Table 23:

b8 b7 b6 b5 b4 b3 b2 b1
T=1 x x x x x x x x
'00' to '0F' and 'FF' not allowed
Table 23: Basic Response Coding of Character TA3
8 Answer to Reset EMV 4.2 Book 1
8.3 Character Definitions Application Independent ICC to
Terminal Interface Requirements
Page 82 June 2008
8.3.3.10 TB3
TB3 (if T=1 is indicated in TD2) indicates the values of the CWI and the BWI
used to compute the CWT and BWT respectively. The l.s. nibble (b1–b4) is used
to indicate the value of CWI, whilst the m.s. nibble (b5–b8) is used to indicate the
value of BWI.
Basic response: If T=1 is to be used, the ATR shall contain TB3 having the l.s.
nibble in the range '0' to '5', and the m.s. nibble in the range '0' to '4', indicating
values of 0 to 5 for CWI and 0 to 4 for BWI.
The basic response coding of character TB3 is shown in Table 24:

b8 b7 b6 b5 b4 b3 b2 b1
T=1 0 x x x 0 y y y
xxx is in the range 000 to 100
yyy is in the range 000 to 101
Table 24: Basic Response Coding of Character TB3
Terminal behaviour: The terminal shall reject an ATR not containing TB3, or
containing a TB3 indicating BWI greater than 4 and/or CWI greater than 5, or
having a value such that 2
CWI
s (N + 1). It shall accept an ATR containing a TB3
having any other value.
Note: N is the extra guardtime indicated in TC1. When using T=1, if TC1='FF', the
value of N shall be taken as –1. Since the maximum value for CWI allowed by these
specifications is 5, note that when T=1 is used, TC1 shall have a value in the range '00'
to '1E' or a value of 'FF' in order to avoid a conflict between TC1 and TB3.
8.3.3.11 TC3
TC3 (if T=1 is indicated in TD2) indicates the type of block error detection code to
be used. The type of code to be used is indicated in b1, and b2 to b8 are not used.
Basic response: The ATR shall not contain TC3, thus indicating longitudinal
redundancy check (LRC) as the error code to be used.
Terminal behaviour: The terminal shall accept an ATR containing TC3 = '00'. It
shall reject an ATR containing TC3 having any other value.
EMV 4.2 Book 1 8 Answer to Reset
Application Independent ICC to 8.4 Terminal Behaviour during Answer to Reset
Terminal Interface Requirements
June 2008 Page 83
8.3.4 TCK - Check Character
TCK has a value that allows the integrity of the data sent in the ATR to be
checked. The value of TCK is such that the exclusive-OR‘ing of all bytes from T0
to TCK inclusive is null.
Basic responses: The ATR shall not contain TCK if T=0 only is to be used. In all
other cases TCK shall be returned in the ATR.
Terminal behaviour: The terminal shall be able to evaluate TCK when
appropriately returned. It shall accept an ICC returning an ATR not containing
TCK if T=0 only is indicated. In all other cases, the terminal shall reject an ICC
returning an ATR not containing TCK, or containing an incorrect TCK.
8.4 Terminal Behaviour during Answer to Reset
Following activation of the ICC contacts as described in section 6.1.2 the
terminal shall initiate a cold reset as described in section 6.1.3.1. Subsequently
the following shall apply:
- If the terminal rejects the ICC as described in section 8.3, it shall initiate the
deactivation sequence within 24,000 initial etus (19,200 + 4,800 initial etus)
measured from the leading edge of the start bit of the TS character of the
ATR.
- If the terminal rejects a cold ATR as described in section 8.3, it shall not
immediately abort the card session but shall initiate a warm reset within
24,000 initial etus (19,200 + 4,800 initial etus) measured from the leading
edge of the start bit of the TS character of the cold ATR to the time that RST
is set low. The terminal shall not initiate the warm reset until the T0
character has been received.
- If the terminal rejects a warm ATR as described in section 8.3, it shall
initiate the deactivation sequence within 24,000 initial etus (19,200 + 4,800
initial etus) measured from the leading edge of the start bit of the TS
character of the warm ATR.
- The terminal shall be able to receive an ATR having a minimum interval
between the leading edges of the start bits of two consecutive characters of
11.8 initial etus.
- The terminal shall be able to receive an ATR having maximum interval
between two consecutive characters of 10,080 initial etus (9,600 + 480 initial
etus). If a character is not received, the terminal shall abort the card session
by initiating the deactivation sequence within 14,400 initial etus
(9,600 + 4,800 initial etus) following the leading edge of the start bit of the
last received character (the character from which timeout occurred).
8 Answer to Reset EMV 4.2 Book 1
8.4 Terminal Behaviour during Answer to Reset Application Independent ICC to
Terminal Interface Requirements
Page 84 June 2008
- The terminal shall be able to receive an ATR having a duration of less than
or equal to 20,160 initial etus. If the ATR (warm or cold) is not completed the
terminal shall abort the card session by initiating the deactivation sequence
within 24,000 initial etus (19,200 + 4,800 initial etus) following the leading
edge of the start bit of the TS character.
- If the terminal detects a parity error in a character returned in the ATR, it
shall initiate the deactivation sequence within 24,000 initial etus
(19,200 + 4,800 initial etus) measured from the leading edge of the start bit of
the TS character of the ATR.
- Upon receipt of a valid cold or warm reset complying with the timings
described above, the terminal shall proceed with the card session using the
returned parameters. It may continue the card session as soon as the last
character of the valid ATR (as indicated by the bit map characters T0 and/or
TDi) and TCK, if present, has been received. Before transmitting, it shall
wait at least the guardtime applicable to the protocol to be used (16 etus for
T=0, BGT for T=1) measured from the leading edge of the start bit of the last
character of the valid ATR.
EMV 4.2 Book 1 8 Answer to Reset
Application Independent ICC to 8.5 Answer to Reset - Flow at the Terminal
Terminal Interface Requirements
June 2008 Page 85
8.5 Answer to Reset - Flow at the Terminal
Figure 11 illustrates an example of the process of an ICC returning an ATR to
the terminal and the checks performed by the terminal to ensure conformance to
section 8.

START
Set Case = 1
(See Note 1)
Is
ATR check 1
OK?
Cold Reset
Warm Reset Set Case = 2
Continue using
parameters
determined above
OR
(See Note 4)
Is
ATR check 2
OK?
Is Case = 1?
Yes
No No
Yes No
ABORT
(See Note 2)
ABORT
(See Note 3)
Yes
ATR check 1 is OK
if parity and TCK
(if returned) are
correct, and the
timings specified in
section 8.4 are
respected
ATR check 2 is OK if
the parameters and
structure of the ATR
conform to the
requirements of
section 8
OR
if a proprietary ATR is
recognised
Note 1: „Case‟ is a process variable used to indicate whether a
cold or warm reset is operative. Case = 1 for a cold reset, and
Case = 2 for a warm reset.
Note 2: If the process aborts at this point, the ICC may be
acceptable in this terminal by business agreement. The terminal
should be primed to accept the ICC prior to insertion. Any
subsequent processing is proprietary and beyond the scope of
this specification.
Note 3: If the process aborts at this point, reset may be retried
after removing the ICC from the terminal and taking corrective
action as required. An appropriate message should be displayed
on the terminal.
Note 4: A proprietary card session beyond the scope of this
specification may be started at this point.

Figure 11: ATR - Example Flow at the Terminal
8 Answer to Reset EMV 4.2 Book 1
8.5 Answer to Reset - Flow at the Terminal Application Independent ICC to
Terminal Interface Requirements
Page 86 June 2008

EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 87
9 Transmission Protocols
This section defines the structure and processing of commands initiated by the
terminal for transmission control and for specific control in asynchronous half
duplex transmission protocols.
Two types of protocol are defined, character protocol (T=0) and block protocol
(T=1). ICCs shall support either protocol T=0 or protocol T=1. Terminals shall
support both protocol T=0 and T=1. The protocol to be used for subsequent
communication between the ICC and terminal is indicated in TD1, and shall be
T=0 or T=1. If TD1 is absent in the ATR, T=0 is assumed. The protocol indicated
by the ICC applies immediately after the answer to reset, as there is no PTS
procedure. Other parameters returned in the ATR and relevant to a specific
protocol are defined in sections 9.2 through 9.4.
The protocols are defined according to the following layering model:
- Physical layer, which describes the exchanges of bits and is common to both
protocols.
- Data link layer, which includes the following sub-definitions:
 Character frame, defining the exchanges of characters common to both
protocols.
 Character protocol T=0, defining the exchange of characters specific to
T=0.
 Error detection and correction specific to T=0.
 Block protocol T=1, defining the exchanges of blocks specific to T=1.
 Error detection and correction specific to T=1.
- Transport layer, which defines the transmission of application-oriented
messages specific to each protocol.
- Application layer, which defines the exchange of messages according to an
application protocol that is common to both transmission protocols.
9.1 Physical Layer
Both protocols T=0 and T=1 use the physical layer and character frame as
defined in section 7.
9 Transmission Protocols EMV 4.2 Book 1
9.2 Data Link Layer Application Independent ICC to
Terminal Interface Requirements
Page 88 June 2008
9.2 Data Link Layer
This section describes the timing, specific options, and error handling for
protocols T=0 and T=1.
9.2.1 Character Frame
The character frame as defined in section 7.2 applies to all messages exchanged
between the ICC and the terminal.
EMV 4.2 Book 1 9 Transmission Protocols
Application Independent ICC to 9.2 Data Link Layer
Terminal Interface Requirements
June 2008 Page 89
9.2.2 Character Protocol T=0
9.2.2.1 Specific Options - Character Timing for T=0
The minimum interval between the leading edges of the start bits of two
consecutive characters sent by the terminal to the ICC shall be between 12 and
266 etus as determined by the value of TC1 returned at the answer to reset (see
sections 8.2 and 8.3). This interval may be less than the minimum interval of 16
etus allowed between two characters sent in opposite directions. If the value
returned in TC1 is N, the ICC shall be able to correctly interpret characters sent
by the terminal with a minimum interval between the leading edges of the start
bits of two consecutive characters of 11.8 + N etus.
The minimum interval between the leading edges of the start bits of two
consecutive characters sent by the ICC to the terminal shall be 12 etus. The
terminal shall be able to correctly interpret characters sent by the ICC with a
minimum interval between the leading edges of the start bits of two consecutive
characters of 11.8 etus.
The maximum interval between the leading edge of the start bit of any character
sent by the ICC and the leading edge of the start bit of the previous character
sent either by the ICC or the terminal (the Work Waiting Time, or WWT) shall
not exceed 960 x D x WI etus (D and WI are returned in TA1 and TC2,
respectively).
The terminal shall be able to correctly interpret a character sent by the ICC with
a maximum interval between the leading edge of the start bit of the character
and the leading edge of the start bit of the previous character sent either by the
ICC or the terminal of {WWT + (D x 480)} etus. If no character is received, the
terminal shall initiate the deactivation sequence within {WWT + (D x 9600)} etus
following the leading edge of the start bit of the character from which the timeout
occurred.
For the ICC or terminal, the minimum interval between the leading edges of the
start bits of the last character received and the first character sent in the
opposite direction shall be 16 etus. The ICC or terminal shall be able to correctly
interpret a character received within 15 etus timed from the leading edge of the
start bit of the last character sent to the leading edge of the start bit of the
received character. These timings do not apply during character repetition.
9 Transmission Protocols EMV 4.2 Book 1
9.2 Data Link Layer Application Independent ICC to
Terminal Interface Requirements
Page 90 June 2008
9.2.2.2 Command Header
A command is always initiated by the terminal application layer (TAL) which
sends an instruction via the TTL to the ICC in the form of a five byte header
called the command header. The command header is comprised of five
consecutive bytes, CLA, INS, P1, P2, and P3, where:
- CLA is the command class.
- INS is the instruction code.
- P1 and P2 contain additional instruction-specific parameters.
- P3 indicates either the length of data to be sent with the command to the
ICC, or the maximum length of data expected in the response from the ICC,
depending on the coding of INS.
These bytes together with any data to be sent with the command constitute the
command transport protocol data unit (C-TPDU) for T=0. The mapping of the
command application protocol data unit (C-APDU) onto the C-TPDU is described
in section 9.3.
The TTL transmits the five-byte header to the ICC and waits for a procedure
byte.
9.2.2.3 Command Processing
Following reception of a command header by the ICC, the ICC shall return a
procedure byte or status bytes SW1 SW2 (hereafter referred to as ‗status‘) to the
TTL. Both the TTL and ICC shall know implicitly at any point during exchange
of commands and data between the TTL and the ICC what the direction of data
flow is and whether it is the TTL or the ICC that is driving the I/O line.
EMV 4.2 Book 1 9 Transmission Protocols
Application Independent ICC to 9.2 Data Link Layer
Terminal Interface Requirements
June 2008 Page 91
9.2.2.3.1 Procedure Byte
The procedure byte indicates to the TTL what action it shall take next. The
coding of the byte and the action that shall be taken by the TTL is shown in
Table 25.

Procedure Byte Value Action
Equal to INS byte All remaining data bytes shall be transferred by
the TTL, or the TTL shall be ready to receive all
remaining data bytes from the ICC
Equal to complement of
INS byte ( INS)
The next data byte shall be transferred by the
TTL, or the TTL shall be ready to receive the
next data byte from the ICC
'60' The TTL shall provide additional work waiting
time as defined in this section
'61' The TTL shall wait for a second procedure byte
then send a GET RESPONSE command header
to the ICC with a maximum length of 'xx', where
'xx' is the value of the second procedure byte
'6C' The TTL shall wait for a second procedure byte
then immediately resend the previous command
header to the ICC using a length of 'xx', where
'xx' is the value of the second procedure byte
Table 25: Terminal Response to Procedure Byte
In all cases, after the action has taken place the TTL shall wait for a further
procedure byte or status.
9 Transmission Protocols EMV 4.2 Book 1
9.2 Data Link Layer Application Independent ICC to
Terminal Interface Requirements
Page 92 June 2008
9.2.2.3.2 Status Bytes
The status bytes indicate to the TTL that command processing by the ICC is
complete. The meaning of the status bytes is related to the command being
processed and is defined in section 11 and in Book 3. The coding of the first
status byte and the action that shall be taken by the TTL are shown in Table 26.

First Status Byte Value Action
'6x' or '9x' (except '60', '61' and
'6C') - status byte SW1
TTL shall wait for a further status byte
(status byte SW2)
Table 26: Status Byte Coding
Following receipt of the second status byte, the TTL shall return the status bytes
(together with any appropriate data - see section 9.3.1) to the TAL in the
response APDU (R-APDU) and await a further C-APDU.
9.2.2.4 Transportation of C-APDUs
A C-APDU containing only command data to be sent to the ICC, or only
expecting data in response from the ICC (cases 2 and 3 in section 9.4), is mapped
without change onto a T=0 C-TPDU. A C-APDU that contains and expects no
data, or a C-APDU that requires data transmission to and from the ICC (cases 1
and 4 in section 9.4) is translated according to the rules defined in section 9.3 for
transportation by a C-TPDU for T=0.
EMV 4.2 Book 1 9 Transmission Protocols
Application Independent ICC to 9.2 Data Link Layer
Terminal Interface Requirements
June 2008 Page 93
9.2.3 Error Detection and Correction for T=0
This procedure is mandatory for T=0 but does not apply during the answer to
reset.
If a character is received with a parity error, the receiver shall indicate an error
by setting the I/O line to state L at time (10.5 ± 0.2) etus following the leading
edge of the start bit of the character for a minimum of 1 etu and a maximum of
2 etus.
The transmitter shall test the I/O line (11 ± 0.2) etus after the leading edge of the
start bit of a character was sent, and assumes that the character was correctly
received if the I/O line is in state H.
If the transmitter detects an error, it shall repeat the disputed character after a
delay of at least 2 etus following detection of the error. The transmitter shall
repeat the same disputed character a maximum of three more times, and shall
therefore send a character up to a maximum of five times in total (the original
transmission followed by the first repeat and then three further repeats) in an
attempt to achieve error free transmission.
If the last repetition is unsuccessful, the terminal shall initiate the deactivation
sequence within (D x 960) etus following reception of the leading edge of the start
bit of the invalid character (if it is the receiver), or within (D x 960) etus following
detection of the signalling of the parity error by the ICC (if it is the transmitter).
Character repetition timing is illustrated in Figure 12.

Start of
character
9
.
8

e
t
u
s

-

e
a
r
l
i
e
s
t

e
n
d
1
0
.
2

e
t
u
s

-

l
a
t
e
s
t

e
n
d
E
a
r
l
i
e
s
t

l
o
w

-

1
0
.
3

e
t
u
s
E
a
r
l
i
e
s
t

h
i
g
h

-

1
1
.
3

e
t
u
s
L
a
t
e
s
t

h
i
g
h

-

1
2
.
7

e
t
u
s
L
a
t
e
s
t

l
o
w

-

1
0
.
7

e
t
u
s
Character with
parity error
1
2
.
8

e
t
u
s

-

e
a
r
l
i
e
s
t

l
o
w
Transmitter
tests I/O here
(11 ± 0.2 etus)
I/O may be high or low
Parity signalling
Times are relative to start of character
0
.
8

e
t
u
s

-

e
a
r
l
i
e
s
t

h
i
g
h
I/O is guaranteed low between 10.7 etus
and 11.3 etus if a parity error is signalled
Repeated
character

Figure 12: Character Repetition Timing
When awaiting a procedure byte or status byte, if the byte returned by the ICC
has a value other than specified in sections 9.2.2.3.1 and 9.2.2.3.2, the terminal
shall initiate the deactivation sequence within 9,600 etus following the leading
edge of the start bit of the (invalid) byte received.
9 Transmission Protocols EMV 4.2 Book 1
9.2 Data Link Layer Application Independent ICC to
Terminal Interface Requirements
Page 94 June 2008
9.2.4 Block Protocol T=1
The protocol consists of blocks transmitted between the TAL and the ICC to
convey command and R-APDUs and transmission control information (for
example, acknowledgment).
The data link layer block frame structure, specific options of the protocol, and
protocol operations (including error handling) are defined below.
9.2.4.1 Block Frame Structure
The character frame as defined in section 7.2 applies.
The block is structured as illustrated in Table 27:

Prologue Field
- Mandatory -
Information Field
- Optional -
Epilogue Field
- Mandatory -
Node
Address
(NAD)
Protocol
Control Byte
(PCB)
Length
(LEN)
APDU or Control
Information (INF)
Error
Detection
Code (EDC)
1 byte 1 byte 1 byte 0–254 bytes 1 byte
Table 27: Structure of a Block
9.2.4.1.1 Prologue Field
The Prologue Field is mandatory and consists of three mandatory bytes:
- Node address (NAD) to identify source and intended destination of the block
and to provide VPP state control
- Protocol control byte (PCB) to control data transmission
- Length (LEN) of the optional information field
EMV 4.2 Book 1 9 Transmission Protocols
Application Independent ICC to 9.2 Data Link Layer
Terminal Interface Requirements
June 2008 Page 95
Node Address
NAD is mandatory. Bits b1–b3 of NAD indicate the source node address (SAD) of
the block, whilst bits b5–b7 indicate the intended destination node address
(DAD) of the block. Bits b4 and b8
7
are unused and shall be set to 0.
These specifications do not support node addressing. The first block sent by the
terminal following the ATR and all following blocks transmitted by either the
terminal or ICC shall have the NAD = '00'.
If during the card session the terminal or ICC receives a block with a NAD = '00',
it may treat the block as invalid. In this event, it shall apply the error detection
and correction techniques described in section 9.2.5.
Protocol Control Byte
The PCB is mandatory, and indicates the type of block. There are three types of
blocks, as defined in Table 28:

Type of Block Short Name Purpose
Information block I-block to convey APDUs
Receive-ready block R-block to convey acknowledgments
(ACK or NAK)
Supervisory block S-block to exchange control
information
Table 28: Types of Blocks

7
Defined in ISO/IEC 7816-3:1997 as VPP control for class A. A value of 0 indicates that
VPP shall be maintained in the idle state.
9 Transmission Protocols EMV 4.2 Book 1
9.2 Data Link Layer Application Independent ICC to
Terminal Interface Requirements
Page 96 June 2008
The coding of the PCB depends on its type and is defined in Table 29, Table 30,
and Table 31.

b8 0
b7 Sequence number
b6 Chaining (more data)
b5–b1 Reserved for future use (RFU)
Table 29: Coding of the PCB of an I-block

b8 1
b7 0
b6 0
b5 Sequence number
b4–b1 0 = Error free
1 = EDC and/or parity error
2 = Other error(s)
Other values RFU
Table 30: Coding of the PCB of a R-block

b8 1
b7 1
b6 0 = Request
1 = Response
b5–b1 0 = Resynchronisation request
1 = Information field size request
2 = Abort request
3 = Extension of BWT request
4 = VPP error
8

Other values RFU
Table 31: Coding of the PCB of a S-block

8
Not used by ICCs and terminals conforming to this specification.
EMV 4.2 Book 1 9 Transmission Protocols
Application Independent ICC to 9.2 Data Link Layer
Terminal Interface Requirements
June 2008 Page 97
Length
The Length (LEN) is mandatory, and indicates the length of the INF part of the
block; it may range from 0 to 254 depending on the type of block.
Note: This specification does not support I-blocks with LEN = 0.
9.2.4.1.2 Information Field
The Information Field (INF) is conditional.
- When present in an I-block, it conveys application data.
- When present in a S-block, it conveys control information.
- A R-block shall not contain an INF.
9.2.4.1.3 Epilogue Field
The Epilogue Field is mandatory, and contains the EDC of the transmitted block.
A block is invalid when a parity error and/or an EDC error occurs. This
specification supports only the LRC as EDC. The LRC is one byte in length and is
calculated as the exclusive-OR of all the bytes starting with the NAD and
including the last byte of INF, if present.
Note: TCi (i > 2), which indicates the type of error detection code to be used, is not
returned by the ICC in the ATR. The normal default of the LRC is thus used for the
EDC.
9.2.4.1.4 Block Numbering
I-blocks are numbered using a modulo-2 number coded on one bit. The
numbering system is maintained independently at the ICC and the terminal as
senders. The value of the number starts with zero for the first I-block sent after
the answer to reset by a sender and is incremented by one after sending each
I-block. The number is reset to zero by the sender after resynchronisation.
R-blocks are numbered using a modulo-2 number coded on one bit. A R-block is
used to acknowledge a chained I-block or to request retransmission of an invalid
block. In either case, b5 of the PCB of the R-block carries the sequence number of
the next I-block its sender expects to receive.
A S-block carries no number.
9 Transmission Protocols EMV 4.2 Book 1
9.2 Data Link Layer Application Independent ICC to
Terminal Interface Requirements
Page 98 June 2008
9.2.4.2 Specific Options
This section defines the information field sizes and timings to be used with
protocol type T=1.
9.2.4.2.1 Information Field Sizes
The IFSC is the maximum length of the information field of blocks that can be
received by the ICC, and is defined as follows. At the answer to reset the IFSI is
returned by the ICC in TA3 indicating the size of the IFSC that can be
accommodated by the ICC. IFSI may take values in the range '10' to 'FE' that
indicate values for IFSC in the range 16 to 254 bytes. The maximum block size
that can be received by the ICC is therefore (IFSC + 3 + 1) bytes including the
prologue and epilogue fields. The size established during the answer to reset
shall be used throughout the rest of the card session or until a new value is
negotiated by the ICC by sending a S(IFS request) block to the terminal.
The information field size for the terminal (IFSD) is the maximum length of the
information field of blocks that can be received by the terminal. The initial size
immediately following the answer to reset shall be 254 bytes, and this size shall
be used throughout the rest of the card session.
EMV 4.2 Book 1 9 Transmission Protocols
Application Independent ICC to 9.2 Data Link Layer
Terminal Interface Requirements
June 2008 Page 99
9.2.4.2.2 Timing for T=1
The minimum interval between the leading edges of the start bits of two
consecutive characters sent by the terminal to the ICC shall be between 11 and
42 etus as indicated by the value of TC1 returned at the answer to reset (see
sections 8.2 and 8.3). If the value returned in TC1 is N, the ICC shall be able to
correctly interpret characters sent by the terminal with a minimum interval
between the leading edges of the start bits of two consecutive characters of
11.8 + N etus.
The minimum interval between the leading edges of the start bits of two
consecutive characters sent by the ICC to the terminal shall be 11 etus. The
terminal shall be able to correctly interpret characters sent by the ICC with a
minimum interval between the leading edges of the start bits of two consecutive
characters of 10.8 etus.
The maximum interval between the leading edges of the start bits of two
consecutive characters sent in the same block (the character waiting time, CWT)
shall not exceed (2
CWI
+ 11) etus. The character waiting time integer, CWI shall
have a value of 0 to 5 as described in section 8.3.3.10, and thus CWT lies in the
range 12 to 43 etus. The receiver shall be able to correctly interpret a character
having a maximum interval between the leading edge of the start bit of the
character and the leading edge of the start bit of the previous character of
(CWT + 4) etus.
The maximum interval between the leading edge of the start bit of the last
character that gave the right to send to the ICC and the leading edge of the start
bit of the first character sent by the ICC (the block waiting time, BWT) shall not
exceed {(2
BWI
x 960) + 11} etus. The block waiting time integer, BWI shall have a
value in the range 0 to 4 as described in section 8.3.3.10, and thus BWT lies in
the range 971 to 15,371 etus for a D of 1.
The terminal shall be able to correctly interpret the first character of a block sent
by the ICC following a time BWT + (D x 960) etus.
For the ICC or terminal, the minimum interval between the leading edges of the
start bits of the last received character and the first character sent in the
opposite direction (the block guard time, BGT) shall be 22 etus. The ICC or
terminal shall be able to correctly interpret a character received within 21 etus
timed from the leading edge of the start bit of the last character that it sent to
the leading edge of the start bit of the received character.
Note: In general, for values of FI and DI other than 1, BWT is calculated using the
formula:
BWT
D
F
etu
BWI
= × ×
|
\

|
.
|
+
|
\

|
.
| 2 960
372
11
9 Transmission Protocols EMV 4.2 Book 1
9.2 Data Link Layer Application Independent ICC to
Terminal Interface Requirements
Page 100 June 2008
9.2.4.3 Error Free Operation
The protocol rules for error free operation are as follows:
1. The first block transmitted after the answer to reset shall be sent by the
terminal to the ICC and shall be a S(IFS request) block with PCB = 'C1' and
with IFSD = 254 (value indicated in the single byte INF field). No further
S(IFS request) blocks shall be sent by the terminal during the card session.
2. The ICC shall return a S(IFS response) block to the terminal acknowledging
the change to the size of the IFSD. The PCB of the S(IFS response) block sent
in response shall have the value 'E1', and the INF field shall have the same
value as the INF field of the block requesting the change.
3. If the ICC wishes to change the size of the IFSC from the initial value
indicated at the answer to reset, it shall send a S(IFS request) block to the
terminal. The PCB of the S(IFS request) block shall have the value 'C1'
indicating a request to change the IFSC. The INF field shall contain a byte
the value of which indicates the size in bytes of the requested new IFSC. This
byte shall have a value in the range '10' to 'FE'. The terminal shall return a
S(IFS response) block to the ICC acknowledging the change to the size of the
IFSC. The PCB of the S(IFS response) block sent in response shall have the
value 'E1', and the INF field shall have the same value as the INF field of the
block requesting the change.
4. During the card session, only blocks as defined in this section shall be
exchanged. The half duplex block protocol consists of blocks transmitted
alternately by the terminal and the ICC. When the sender has transmitted a
complete block, the sender switches to the receiving state.
5. When the receiver has received the number of characters in accordance with
the value of LEN and the EDC, the receiver gains the right to send.
6. The ICC shall acknowledge an I-block transmitted by the terminal. The
acknowledgment is indicated in the sequence number of the I-block, or the
R-block if chaining is in use (except the last block of the chain), that the ICC
returns to the terminal.
7. A non-chained I-block or the last I-block of a chain is considered by the sender
to be acknowledged when the sequence number of the I-block received in
response differs from the sequence number of the previously received I-block.
If no I-block was previously received, the sequence number of the I-block sent
in response shall be 0.
8. When a R-block is received, b5 shall be evaluated. The receiver is not
required to evaluate bits b4–b1 of the PCB. Optional evaluation of bits b4–b1
shall not result in any action which contradicts the protocol rules defined in
this specification
EMV 4.2 Book 1 9 Transmission Protocols
Application Independent ICC to 9.2 Data Link Layer
Terminal Interface Requirements
June 2008 Page 101
9. During chaining, a chained I-block (except the last I-block of a chain) is
considered by the sender to be acknowledged when the sequence number of
the R-block sent in response differs from the sequence number of the I-block
being acknowledged.
10. If the ICC requires more than the BWT to process the previously received
I-block, it shall send a waiting time extension request S(WTX request) block,
where the INF contains the one-byte binary integer multiplier of the BWT
value requested. The terminal shall acknowledge by sending a waiting time
extension response S(WTX response) block with the same value in the INF.
The time allocated (which is the time requested in the S(WTX request) block,
and which replaces BWT for this instance only) starts at the leading edge of
the last character of the S(WTX response) block. After the ICC responds,
BWT is again used as the time allowed for the ICC to process the I-block.
11. S-blocks are used only in pairs. A S(request) block is always followed by a
S(response) block.
When synchronisation as outlined above is lost, the procedure described in
section 9.2.5 shall apply.
9.2.4.4 Chaining
When the sender has to transmit data of length greater than IFSC or IFSD
bytes, it shall divide it into several consecutive I-blocks. The transmission of
these multiple I-blocks is achieved using the chaining function described below.
The chaining of I-blocks is controlled by b6 of the PCB. The coding of b6 is as
follows:
- b6 = 0 Last block of the chain
- b6 = 1 Subsequent block follows
Any I-block with b6 = 1 shall be acknowledged by a R-block according to
section 9.2.4.1.
The last block of a chain sent by the terminal shall be acknowledged by either an
I-block if correctly received, or a R-block if incorrectly received. The last block of a
chain sent by the ICC shall be acknowledged by a R-block if incorrectly received;
if correctly received, the terminal will only transmit further I-blocks if another
command is to be processed.
9 Transmission Protocols EMV 4.2 Book 1
9.2 Data Link Layer Application Independent ICC to
Terminal Interface Requirements
Page 102 June 2008
9.2.4.4.1 Rules for Chaining
The TTL shall support chaining for both transmitted and received blocks. The
ICC may optionally chain blocks sent to the terminal. Chaining is only possible
in one direction at a time. The following rules for chaining apply:
- When the terminal is the receiver, the terminal shall accept a sequence of
chained I-blocks sent from the ICC of length s IFSD bytes per block.
- When the ICC is the receiver, the ICC shall accept a sequence of chained
I-blocks sent from the terminal all having length LEN = IFSC except the last
block, whose length may be in the range 1 to IFSC bytes inclusive.
- When the ICC is the receiver, if an I-block sent by the terminal has
length > IFSC, the ICC shall reject it using a R-block.
- If the ICC as sender chains blocks sent to the terminal it shall send I-blocks
of length sIFSD bytes per block.
- When the terminal is the sender, all I-blocks of a chain sent to the ICC shall
have LEN = IFSC bytes except the last, which shall have a length in the
range 1 to IFSC bytes inclusive.
- During chaining, the ICC shall not attempt to negotiate a new IFSC by
sending a S(IFSC request) block to the terminal.
EMV 4.2 Book 1 9 Transmission Protocols
Application Independent ICC to 9.2 Data Link Layer
Terminal Interface Requirements
June 2008 Page 103
9.2.4.4.2 Construction of Chained Blocks
C-APDUs are transported from the TTL to the ICC in the INF field of I-blocks
(see section 9.3.2). If a C-APDU is too large to fit in one block, it is chained over
several as illustrated in Figure 13.

Block(1) CLA INS P1 P2 Lc Data Data

Block(2) Data Data Data

Block(n) Data Data Le
Figure 13: Chaining C-APDU
The data and status returned by the ICC may optionally be chained over several
I-blocks as illustrated in Figure 14.

Block(1) Data Data Data

Block(2) Data Data Data

Block(n) Data Data SW1 SW2
Figure 14: Chaining I-Blocks
Note: The above examples are for a case 4 command and show only the INF fields of the
chained blocks. Each block also has a prologue and epilogue field. All chained blocks
shall contain an INF field having a length in the range 1 to IFSD bytes if the ICC is the
sender, or IFSC bytes during chaining and 1 to IFSC bytes in the last block of the chain
if the terminal is the sender.
9 Transmission Protocols EMV 4.2 Book 1
9.2 Data Link Layer Application Independent ICC to
Terminal Interface Requirements
Page 104 June 2008
9.2.5 Error Detection and Correction for T=1
The following errors shall be detected by the TTL:
- Transmission error including parity error, EDC error, and BWT time-out.
- Loss of synchronisation assumed when the actual block size is inconsistent
with the size indicated by the value in LEN.
- Protocol error (infringement of the rules of the protocol).
- Abort request for a chain of blocks.
If a parity error is detected, character repetition shall not be implemented when
using T=1.
Error recovery is attempted in the following manner.
The TTL shall attempt error recovery by trying the following techniques in the
order shown.
1. Retransmission of blocks
Deactivation of the ICC contacts
The ICC shall attempt error recovery by trying retransmission of blocks.
If a block is retransmitted, the retransmitted block shall be identical to the
originally transmitted block.
Note: In some terminals the TTL may not be solely responsible for error handling.
Where 'TTL' is used it includes any functionality present in the terminal as applicable.
The following types of block are considered invalid:
- Blocks containing transmission errors, i.e. parity/EDC incorrect
- Blocks that have formatting errors, i.e. blocks constructed incorrectly by the
sender (syntax error)
- Blocks that are unexpected according to the rules of the protocol at any
particular point in an exchange, for example, a S(Response) block received in
response to an I-block.
A R-block received indicating an error condition is not an invalid block.
EMV 4.2 Book 1 9 Transmission Protocols
Application Independent ICC to 9.2 Data Link Layer
Terminal Interface Requirements
June 2008 Page 105
9.2.5.1 Protocol Rules for Error Handling
The following rules apply for error handling and correction. In each case where a
R-block is sent, the error coding bits b4–b1 may optionally be evaluated, but
shall not result in any action which contradicts the protocol rules defined in this
specification.
1. If the first block received by the ICC after the answer to reset is invalid, it
shall return a R-block to the TTL with b5 = 0 and NAD = 0.
2. If there is no response from the ICC to a block sent by the TTL, the terminal
shall:
(a) initiate the deactivation sequence
OR
(b) if the block not responded to was an I-block, R-block, or S(Response)
block, transmit a R-block with its sequence number coded as specified
in section 9.2.4.1.4
OR
(c) if the block not responded to was a S(Request) block, retransmit the
S(Request) block
between {BWT + (D x 960)} and {BWT + (D x 4,800)} etus (or between
{WTX + (n x D x 960)} and {WTX + (n x D x 4,800)} etus if a waiting time
extension has been negotiated) from the leading edge of the start bit of the
last character of the block to which there was no response.
3. If during reception of a block by the terminal an expected character is not
received, the terminal shall:
(a) initiate the deactivation sequence
OR
(b) if the block not responded to was an I-block, R-block, or S(Response)
block, transmit a R-block with its sequence number coded as specified
in section 9.2.4.1.4
OR
(c) if the block not responded to was a S(Request) block, retransmit the
S(Request) block
within (CWT + 4) and (CWT + 4,800) etus from the leading edge of the start
bit of the last character received.
9 Transmission Protocols EMV 4.2 Book 1
9.2 Data Link Layer Application Independent ICC to
Terminal Interface Requirements
Page 106 June 2008
4. If an invalid block is received in response to an I-block, the sender shall
transmit a R-block with its sequence number coded as specified in
section 9.2.4.1.4.
5. If an invalid block is received in response to a R-block, the sender shall
retransmit the R-block.
6. If a correct S(... response) block is not received in response to a S(... request)
block, the sender shall retransmit the S(... request) block.
7. If an invalid block is received in response to a S(... response) block, the sender
shall transmit a R-block with its sequence number coded as specified in
section 9.2.4.1.4.
8. If the TTL has sent three consecutive blocks of any type without obtaining a
valid response, it shall initiate the deactivation sequence within
{BWT + (D x 14,400)} etus following the leading edge of the start bit of the
last character of the block requesting retransmission.
9. Note: Resynchronisation is not required by this specification. If for
proprietary reasons the terminal supports resynchronisation, it may attempt
this by sending a S(RESYNCH request) block, then behave as specified in
ISO/IEC 7816-3.
10. If the ICC has sent a block a maximum of twice in succession (the original
transmission followed by one repeat) without obtaining a valid response, it
shall remain in reception mode.
11. A S(ABORT request) shall not be sent by the terminal. If the terminal
receives a S(ABORT request) from the ICC, it shall terminate the card
session by initiating the deactivation sequence within (D x 9,600) etus
following reception of the leading edge of the start bit of the last character of
the S(ABORT request) block.
Note: Transaction abortion is not required by this specification. If an ICC or
terminal supports abortion for proprietary reasons, it may issue a S(ABORT
request), but note that it will receive an invalid response if the receiver does not
support abortion. In this event, the card session will be terminated according to the
rules above. If a terminal optionally supporting abortion receives a S(ABORT
request) from an ICC, it may return a S(ABORT response) rather than terminating
the card session.
EMV 4.2 Book 1 9 Transmission Protocols
Application Independent ICC to 9.3 Terminal Transport Layer (TTL)
Terminal Interface Requirements
June 2008 Page 107
9.3 Terminal Transport Layer (TTL)
This section describes the mechanism by which command and response APDUs
are transported between the terminal and the ICC. APDUs are command or
response messages, and since both command and response messages may contain
data, the TTL shall be capable of managing the four cases defined in section 9.4.
The construction of C-APDUs and R-APDUs are described in sections 9.4.1
and 9.4.2, respectively.
The C-APDU is passed from the TAL to the TTL where it is mapped in a manner
appropriate to the transmission protocol to be used before being sent to the ICC.
Following processing of the command by the ICC, data (if present) and status are
returned by the ICC to the TTL, which maps it onto the R-APDU.
9.3.1 Transport of APDUs by T=0
This section describes the mapping of C-APDUs and R-APDUs, the mechanism
for exchange of data between the TTL and the ICC, and the use of the
GET RESPONSE command for retrieval of data from the ICC when case 2 or 4
commands are used.
9.3.1.1 Mapping of C-APDUs and R-APDUs and Data Exchange
The mapping of the C-APDU onto the T=0 command header is dependent upon
the case of the command. The mapping of the data (if present) and status
returned by the ICC onto the R-APDU is dependent upon the length of the data
returned and the meaning of the status bytes.
Procedure bytes '61xx' and '6Cxx' are returned by the ICC to control exchanges
between the TTL and the ICC, and should never be returned to the TAL.
Command processing in the ICC is not complete if it has returned procedure
bytes '61xx' or '6Cxx'.
Note: For proprietary reasons, the TTL may in addition be capable of accepting data
from the ICC without using the '61' and '6C' procedure bytes. Such functionality is not
required and is beyond the scope of these specifications.
9 Transmission Protocols EMV 4.2 Book 1
9.3 Terminal Transport Layer (TTL) Application Independent ICC to
Terminal Interface Requirements
Page 108 June 2008
Normal status on completion of processing a command is indicated if the ICC
returns status bytes SW1 SW2 = '9000' to the TTL. The TTL shall discontinue
processing of a command (i.e. pass the R-APDU to the TAL and wait for a further
C-APDU from the TAL) on receipt of any other status (but not on receipt of
procedure bytes '61xx' and '6Cxx') from the ICC. (For case 4 commands only,
immediately following successful transmission of command data to the ICC, the
TTL shall continue processing the command if warning status bytes ('62xx' or
'63xx') or application related status bytes ('9xxx' except '9000') are received.)
The following descriptions of the mapping of data and status returned by the ICC
onto the R-APDU are for information, and apply only after the ICC has
completed processing of the command, successfully or otherwise, and all data (if
present) has been returned by the ICC under the control of '61xx' and '6Cxx'
procedure bytes. Detailed use of the INS, INS, and '60' procedure bytes is not
described.
The status returned by the ICC shall relate to the most recently received
command; where a GET RESPONSE command is used to complete the
processing of a case 2 or case 4 command, any status returned by the ICC after
receipt of the GET RESPONSE command shall relate to the GET RESPONSE
command, not to the case 2 or case 4 command which it completes.
9.3.1.1.1 Case 1
The C-APDU header is mapped onto the first four bytes of the T=0 command
header, and P3 of the T=0 command header is set to '00'.
The flow of the exchange is as follows:
1. The TTL shall send the T=0 command header to the ICC.
2. On receipt of the command header the ICC, under normal or abnormal
processing, shall return status to the TTL.
(The ICC shall analyse the T=0 command header to determine whether it is
processing a case 1 command or a case 2 command requesting all data up to
the maximum length available.)
3. On receipt of status from the ICC, the TTL shall discontinue processing of the
command.
See Annex A1 for details of the exchanges between the TTL and the ICC.
The status returned to the TTL from the ICC after completion of processing of
the command is mapped onto the mandatory trailer of the R-APDU without
change.
EMV 4.2 Book 1 9 Transmission Protocols
Application Independent ICC to 9.3 Terminal Transport Layer (TTL)
Terminal Interface Requirements
June 2008 Page 109
9.3.1.1.2 Case 2
The C-APDU header is mapped onto the first four bytes of the T=0 command
header, and length byte 'Le' from the conditional body of the C-APDU is mapped
onto P3 of the T=0 command header. READ RECORD commands issued during
application selection and all case 2 commands issued according to Book 3 shall
have Le = '00'.
The flow of the exchange is as follows:
1. The TTL shall send the T=0 command header to the ICC.
2. On receipt of the command header:
(a) under normal processing, the ICC shall return data and status to the
TTL, using procedure bytes '6Cxx' (and if required, procedure bytes
'61xx') to control the return of data
OR
(b) under abnormal processing, the ICC shall return status only to the
TTL.
3. On receipt of the data (if present) and status from the ICC, the TTL shall
discontinue processing the command.
See Annex A2 and Annex A5, for details of the exchanges between the TTL and
the ICC, including use of the '61xx' and '6Cxx' procedure bytes.
The data (if present) and status returned to the TTL from the ICC after
completion of processing of the command, or the status returned by the ICC that
caused the TTL to discontinue processing of the command, are mapped onto the
R-APDU as follows:
- The data returned (if present) is mapped onto the conditional body of the
R-APDU. If no data is returned, the conditional body of the R-APDU is left
empty.
- The status returned is mapped onto the mandatory trailer of the R-APDU
without change.
9 Transmission Protocols EMV 4.2 Book 1
9.3 Terminal Transport Layer (TTL) Application Independent ICC to
Terminal Interface Requirements
Page 110 June 2008
9.3.1.1.3 Case 3
The C-APDU header is mapped onto the first four bytes of the T=0 command
header, and length byte 'Lc' from the conditional body of the C-APDU is mapped
onto P3 of the T=0 command header.
The flow of the exchange is as follows:
1. The TTL shall send the T=0 command header to the ICC.
2. On receipt of the command header:
(a) If the ICC returns a procedure byte, the TTL shall send the data
portion of the conditional body of the C-APDU to the ICC under the
control of procedure bytes returned by the ICC.
OR
(b) If the ICC returns status, the TTL shall discontinue processing of the
command.
3. If processing was not discontinued in step 2(b), the ICC shall return status
following receipt of the conditional body of the C-APDU and completion of
processing the command.
4. On receipt of status from the ICC, the TTL shall discontinue processing the
command.
See Annex A3, for details of the exchanges between the TTL and the ICC.
The status returned to the TTL from the ICC after completion of processing of
the command, or the status returned by the ICC that caused the TTL to
discontinue processing of the command, is mapped onto the R-APDU without
change.
EMV 4.2 Book 1 9 Transmission Protocols
Application Independent ICC to 9.3 Terminal Transport Layer (TTL)
Terminal Interface Requirements
June 2008 Page 111
9.3.1.1.4 Case 4
The C-APDU header is mapped onto the first four bytes of the T=0 command
header, and length byte 'Lc' from the conditional body of the C-APDU is mapped
onto P3 of the T=0 command header. SELECT commands issued during
application selection and all case 4 commands issued according to Book 3 shall
have Le = '00'.
The flow of the exchange is as follows:
1. The TTL shall send the T=0 command header to the ICC.
2. On receipt of the command header:
(a) If the ICC returns a procedure byte, the TTL shall send the data
portion of the conditional body of the C-APDU to the ICC under the
control of procedure bytes returned by the ICC.
OR
(b) If the ICC returns status, the TTL shall discontinue processing of the
command.
3. If processing was not discontinued in step 2(b), following receipt of the
conditional body of the C-APDU:
(a) under normal processing, the ICC shall return procedure bytes '61xx'
to the TTL requesting the TTL to issue a GET RESPONSE command
to retrieve the data from the ICC.
OR
(b) under abnormal processing, the ICC shall return status only to the
TTL.
4. On receipt of the procedure bytes or status returned in step 3:
(a) If the ICC returned '61xx' procedure bytes as in step 3(a), the TTL
shall send a GET RESPONSE command header to the ICC with P3
set to a value less than or equal to the value contained in the 'xx' byte
of '61xx' procedure bytes.
OR
(b) If the ICC returned status as in step 3(b) that indicates a warning
('62xx' or '63xx'), or which is application related ('9xxx' but not '9000'),
the TTL shall send a GET RESPONSE command with Le='00'.
OR
(c) If the ICC returned status as in step 3(b) other than that described in
step 4(b), the TTL shall discontinue processing of the command.
5. If processing was not discontinued in step 4(c), the GET RESPONSE
command shall be processed according to the rules for case 2 commands in
section 9.3.1.1.2.
9 Transmission Protocols EMV 4.2 Book 1
9.3 Terminal Transport Layer (TTL) Application Independent ICC to
Terminal Interface Requirements
Page 112 June 2008
See Annex A4 and Annex A6, for details of the exchanges between the TTL and
the ICC, including use of the '61xx' and '6Cxx' procedure bytes.
The data (if present) and status returned to the TTL from the ICC after
completion of processing of the command, or the status returned by the ICC that
caused the TTL to discontinue processing of the command, are mapped onto the
R-APDU as follows:
- The data returned (if present) is mapped onto the conditional body of the
R-APDU. If no data is returned, the conditional body of the R-APDU is left
empty.
- The first status returned during processing of the entire case 4 command,
including the GET RESPONSE command if used, is mapped onto the
mandatory trailer of the R-APDU without change.
9.3.1.2 Use of Procedure Bytes '61xx' and '6Cxx'
The ICC returns procedure bytes '61xx' and '6Cxx' to the TTL to indicate to it the
manner in which it should retrieve the data requested by the command currently
being processed. These procedure bytes are only used when processing case 2 and
4 commands.
Procedure bytes '61xx' instruct the TTL to issue a GET RESPONSE command to
the ICC. P3 of the GET RESPONSE command header is set to s 'xx'.
Procedure bytes '6Cxx' instruct the TTL to immediately resend the previous
command header setting P3 = 'xx'.
Usage of these procedure bytes during error free processing with case 2 and 4
commands is as follows. In the case of an error, the ICC may return status
indicating error or warning conditions instead of the '61xx' or '6Cxx' response.
EMV 4.2 Book 1 9 Transmission Protocols
Application Independent ICC to 9.3 Terminal Transport Layer (TTL)
Terminal Interface Requirements
June 2008 Page 113
9.3.1.2.1 Case 2 Commands
1. If the ICC receives a case 2 command header and Le = '00' or Le > Licc, it
shall return:
(a) procedure bytes '6C Licc' instructing the TTL to immediately resend
the command header with P3 = Licc
OR
(b) status indicating a warning or error condition (but not SW1 SW2 =
'90 00').
Note: If Le = '00' and the ICC has 256 bytes of data to return, it should proceed as
defined in the following rule for Le = Licc.
2. If the ICC receives a case 2 command header and Le = Licc, it shall return:
(a) data of length Le (= Licc) under the control of the INS, INS, or '60'
procedure bytes followed by the associated status
OR
(b) procedure bytes '61xx' instructing the TTL to issue a
GET RESPONSE command with a maximum length of 'xx'
OR
(c) status indicating a warning or error condition (but not SW1 SW2 =
'90 00').
3. If the ICC receives a case 2 command header and Le < Licc, it shall return:
(a) data of length Le under the control of the INS, INS, or '60' procedure
bytes followed by procedure bytes '61xx' instructing the TTL to issue
a GET RESPONSE command with a maximum length of 'xx'
OR
(b) procedure bytes '6C Licc' instructing the TTL to immediately resend
the command header with P3 = Licc
OR
(c) status indicating a warning or error condition (but not SW1 SW2 =
'90 00').
3(b) above is not a valid response by the ICC to a GET RESPONSE command.
9 Transmission Protocols EMV 4.2 Book 1
9.3 Terminal Transport Layer (TTL) Application Independent ICC to
Terminal Interface Requirements
Page 114 June 2008
9.3.1.2.2 Case 4 Commands
1. If the ICC receives a case 4 command, after processing the data sent with the
C-APDU, it shall return:
(a) procedure bytes '61 xx' instructing the TTL to issue a
GET RESPONSE command with a maximum length of 'xx'
OR
(b) status indicating a warning or error condition (but not SW1 SW2 =
'90 00').
The GET RESPONSE command so issued is then treated as described in
section 9.3.1.2.1 for case 2 commands.
9.3.1.3 GET RESPONSE Command
The GET RESPONSE command is issued by the TTL to obtain available data
from the ICC when processing case 2 and 4 commands. It is employed only when
the T=0 protocol type is in use.
The structure of the command message is shown in Table 32:

CLA '00'
INS 'C0'
P1 '00'
P2 '00'
Le Maximum length of data expected
Table 32: Structure of Command Message
Following normal processing, the ICC returns status bytes SW1 SW2 = '9000'
and Licc bytes of data.
In the event that an error condition occurs, the coding of the error status bytes
(SW1 SW2) is shown in Table 33:

SW1 SW2 Meaning
'62' '81' Part of returned data
may be corrupted
'67' '00' Length field incorrect
'6A' '86' P1 P2 = '00'
'6F' '00' No precise diagnosis
Table 33: GET RESPONSE Error Conditions
EMV 4.2 Book 1 9 Transmission Protocols
Application Independent ICC to 9.4 Application Layer
Terminal Interface Requirements
June 2008 Page 115
9.3.2 Transportation of APDUs by T=1
The C-APDU is sent from the TAL to the TTL. The TTL maps the C-APDU onto
the INF field of an I-block without change, and sends the I-block to the ICC.
Response data (if present) and status are returned from the ICC to the TTL in
the INF field of an I-block. If The ICC returns status indicating normal
processing ('61xx'), a warning ('62xx' or '63xx'), which is application related
('9xxx'), or is '9000', it shall also return data (if available) associated with
processing of the command.
No data shall be returned with any other status. The contents of the INF field of
the I-block are mapped onto the R-APDU without change and returned to the
TAL.
Note: C-APDUs and response data/status may be chained over the INF fields of
multiple blocks if required.
9.4 Application Layer
The application protocol consists of an ordered set of exchanges between the TAL
and the TTL. Each step in an application layer exchange consists of a
command-response pair, where the TAL sends a command to the ICC via the
TTL, and the ICC processes it and sends a response via the TTL to the TAL.
Each specific command has a specific response. An APDU is defined as a
command message or a response message.
Both command and response messages may contain data. Thus, four cases shall
be managed by the transmission protocols via the TTL, as shown in Table 34:

Case Command Data Response Data
1 Absent Absent
2 Absent Present
3 Present Absent
4 Present Present
Table 34: Definition of Cases for Data in APDUs
Note: When secure messaging is used only case 3 and case 4 commands exist since data
(as a minimum, the MAC) is always sent to the ICC. When using secure messaging,
case 1 commands will become case 3, and case 2 commands will become case 4.
9 Transmission Protocols EMV 4.2 Book 1
9.4 Application Layer Application Independent ICC to
Terminal Interface Requirements
Page 116 June 2008
9.4.1 C-APDU
The C-APDU consists of a mandatory header of four consecutive bytes denoted
CLA, INS, P1, and P2, followed by a conditional body of variable length.
These mandatory header bytes are defined as follows:
- CLA: Instruction class; may take any value except 'FF'.
- INS: Instruction code within the instruction class. The INS is only valid if
the l.s. bit is 0, and the m.s. nibble is neither '6' nor '9'.
- P1, P2: Reference bytes completing the INS.
Note: The full coding of the headers for each command is covered in section 11.
The conditional body consists of a string of bytes defined as follows:
- 1 byte, denoted by Lc, defining the number of data bytes to be sent in the
C-APDU. The value of Lc may range from 1 to 255.
- String of bytes sent as the data field of the C-APDU, the number of bytes sent
being as defined by Lc.
- 1 byte, denoted by Le, indicating the maximum number of data bytes
expected in the R-APDU. The value of Le may range from 0 to 255; if Le = 0,
the maximum number of bytes expected in the response is 256.
Note: The full coding of the data field of the conditional body for each command is
covered in section 11.
The four possible C-APDU structures are defined in Table 35:

Case Structure
1 CLA INS P1 P2
2 CLA INS P1 P2 Le
3 CLA INS P1 P2 Lc Data
4 CLA INS P1 P2 Lc Data Le
Table 35: C-APDU Structures
EMV 4.2 Book 1 9 Transmission Protocols
Application Independent ICC to 9.4 Application Layer
Terminal Interface Requirements
June 2008 Page 117
9.4.2 R-APDU
The R-APDU is a string of bytes consisting of a conditional body followed by a
mandatory trailer of two bytes denoted SW1 SW2.
The conditional body is a string of data bytes with a maximum length as defined
by Le in the C-APDU.
The mandatory trailer indicates the status of the ICC after processing the
command.
The coding of SW1 SW2 is defined in section 11.
9 Transmission Protocols EMV 4.2 Book 1
9.4 Application Layer Application Independent ICC to
Terminal Interface Requirements
Page 118 June 2008

EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 119
Part III

Files, Commands, and
Application Selection
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page 120 June 2008
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 121
10 Files
An application in the ICC includes a set of items of information, often contained
within files. These items of information may be accessible to the terminal after a
successful application selection.
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.
It is up to the issuer to ensure that data in the card is of the correct format.
The data element directory defined in Annex B includes those data elements that
may be used for application selection. Data elements used during application
selection that are not specified in Annex B are outside the scope of these
specifications.
10.1 File Structure
The file organisation applying to this specification is deduced from and complies
with the basic organisations as defined in ISO/IEC 7816-4.
This section describes the file structure of applications conforming to this
specification.
The files within the ICC are seen from the terminal as a tree structure. Every
branch of the tree is an Application Definition File (ADF) or a Directory
Definition File (DDF). An ADF is the entry point to one or more Application
Elementary Files (AEFs). An ADF and its related data files are seen as being on
the same branch of the tree. A DDF is an entry point to other ADFs or DDFs.
10.1.1 Application Definition Files
The tree structure of ADFs:
- Enables the attachment of data files to an application.
- Ensures the separation between applications.
- Allows access to the logical structure of an application by its selection.
An ADF is seen from the terminal as a file containing only data objects
encapsulated in its file control information (FCI) as shown in Table 45.
10 Files EMV 4.2 Book 1
10.1 File Structure Application Independent ICC to
Terminal Interface Requirements
Page 122 June 2008
10.1.2 Application Elementary Files
The structure and use of AEFs is application dependent. For the EMV
Debit/Credit application, the files are described in Book 3.
10.1.3 Mapping of Files Onto ISO/IEC 7816-4 File Structure
The following mapping onto ISO/IEC 7816-4 applies:
- A dedicated file (DF) as defined in ISO/IEC 7816-4 and containing a FCI is
mapped onto an ADF or a DDF. It may give access to elementary files and
DFs. The DF at the highest level of the card is the master file (MF).
- An elementary file (EF) as defined in ISO/IEC 7816-4 is mapped onto the
AEF. An EF is never used as an entry point to another file.
If DFs are embedded, retrieval of the attached EF is transparent to this
specification.
10.1.4 Directory Structure
When the Payment System Environment (PSE) as described in section 12.2.2 is
present, the ICC shall maintain a directory structure for the list of applications
within the PSE that the issuer wants to be selected by a directory. In that case,
the directory structure consists of a Payment System Directory file (DIR file) and
optional additional directories introduced by a DDF as described in this section.
The directory structure allows for the retrieval of an application using its
Application Identifier (AID) or the retrieval of a group of applications using the
first n bytes of their AID as DDF name.
The presence of the DIR file shall be coded in the response message to the
selection of the PSE (see the SELECT command).
The DIR file is an AEF (in other words, an EF) with a record structure according
to this specification including the following data objects according to
ISO/IEC 7816-4:
- One or more Application Templates (tag '61') as described in section 12.
- Optionally, other data objects present within a Directory Discretionary
Template (tag '73'). The data objects contained in this template are outside
the scope of this specification.
Directories are optional within an ICC, and when present there is no defined
limit to the number of such directories that may exist. Each such directory is
located by a directory SFI data object contained in the FCI of each DDF.
EMV 4.2 Book 1 10 Files
Application Independent ICC to 10.2 File Referencing
Terminal Interface Requirements
June 2008 Page 123
10.2 File Referencing
A file may be referred to by a name or a SFI depending on its type.
10.2.1 Referencing by Name
Any ADF or DDF in the card is referenced by its DF name. A DF name for an
ADF corresponds to the AID or contains the AID as the beginning of the DF
name. Each DF name shall be unique within a given card.
10.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. A SFI shall be unique within an
application.
10 Files EMV 4.2 Book 1
10.2 File Referencing Application Independent ICC to
Terminal Interface Requirements
Page 124 June 2008

EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 125
11 Commands
11.1 Message Structure
Messages are transported between the terminal and the card according to the
transmission protocol selected at the ATR (see Part II). The terminal and the
card shall also implement the physical, data link, and transport layers as defined
in Part II.
To run an application, an additional layer called application protocol is
implemented in the terminal. It includes steps consisting of sending a command
to the card, processing it in the card, and sending back the response to the
terminal. All commands and responses referred to in the remainder of this Book
are defined at the application layer.
The command message sent from the application layer and the response message
returned by the card to the application layer are called Application Protocol Data
Units (APDU). A specific response corresponds to a specific command. These are
referred to as APDU command-response pairs. In an APDU command-response
pair, the command message and the response message may contain data.
This section describes the structure of the APDU command-response pairs
necessary to the application protocols defined in this specification. This Book
describes only those commands necessary to the functioning of application
selection. All other commands shall be implemented as required by specific
applications, but shall conform to the APDU structures (formats) defined in
Book 3, Part II.
11 Commands EMV 4.2 Book 1
11.1 Message Structure Application Independent ICC to
Terminal Interface Requirements
Page 126 June 2008
11.1.1 Command APDU Format
The command APDU consists of a mandatory header of four bytes followed by a
conditional body of variable length, as shown in Figure 15:

CLA INS P1 P2 Lc Data Le
÷ Mandatory Header ÷ ÷ Conditional Body ÷
Figure 15: Command APDU Structure
The number of data bytes sent in the command APDU is denoted by Lc (length of
command data field).
The maximum number of data bytes expected in the response APDU is denoted
by Le (length of expected data). When Le is present and contains the value zero,
the maximum number of data bytes available (s 256) is requested. READ
RECORD and SELECT commands issued during application selection and all
case 2 and case 4 commands issued according to Book 3 shall have Le = '00'.
The content of a command APDU message is as shown in Table 36:

Code Description Length
CLA Class of instruction 1
INS Instruction code 1
P1 Instruction parameter 1 1
P2 Instruction parameter 2 1
Lc Number of bytes present in command data field 0 or 1
Data String of data bytes sent in command (= Lc) var.
Le Maximum number of data bytes expected in data
field of response
0 or 1
Table 36: Command APDU Content
The different cases of command APDU structure are described in Table 35.
EMV 4.2 Book 1 11 Commands
Application Independent ICC to 11.2 READ RECORD Command-Response APDUs
Terminal Interface Requirements
June 2008 Page 127
11.1.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 16:

Data SW1 SW2
÷ Body ÷ ÷ Trailer ÷
Figure 16: Response APDU Structure
The number of data bytes received in the response APDU is denoted by Lr
(length of response data field). Lr is not returned by the transport layer. The
application layer may rely on the object oriented structure of the response
message data field to calculate Lr if needed.
The trailer indicates in two bytes the processing state of the command as
returned by the transport layer.
The content of a response APDU message is as shown in Table 37:

Code Description Length
Data String of data bytes received in response var(= Lr)
SW1 Command processing status 1
SW2 Command processing qualifier 1
Table 37: Response APDU Content
11.2 READ RECORD Command-Response APDUs
11.2.1 Definition and Scope
The READ RECORD command reads a file record in a linear file.
The response from the ICC consists of returning the record.
11 Commands EMV 4.2 Book 1
11.2 READ RECORD Command-Response APDUs Application Independent ICC to
Terminal Interface Requirements
Page 128 June 2008
11.2.2 Command Message
The READ RECORD command message is coded according to Table 38:

Code Value
CLA '00'
INS 'B2'
P1 Record number
P2 Reference control parameter (see Table 39)
Lc Not present
Data Not present
Le '00'
Table 38: READ RECORD Command Message
Table 39 defines the reference control parameter of the command message:

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x x x x x SFI
1 0 0 P1 is a record number
Table 39: READ RECORD Command Reference Control Parameter
11.2.3 Data Field Sent in the Command Message
The data field of the command message is not present.
11.2.4 Data Field Returned in the Response Message
The data field of the response message of any successful READ RECORD
command contains the record read. Records read during application selection are
directory records which are formatted as in section 12.2.3. The format of records
read during application processing is application dependent.
11.2.5 Processing State Returned in the Response
Message
'9000' indicates a successful execution of the command.
EMV 4.2 Book 1 11 Commands
Application Independent ICC to 11.3 SELECT Command-Response APDUs
Terminal Interface Requirements
June 2008 Page 129
11.3 SELECT Command-Response APDUs
11.3.1 Definition and Scope
The SELECT command is used to select the ICC PSE, DDF, or ADF
corresponding to the submitted file name or AID. The selection of an application
is described in section 12.
A successful execution of the command sets the path to the PSE, DDF, or ADF.
Subsequent commands apply to AEFs associated with the selected PSE, DDF, or
ADF using SFIs.
The response from the ICC consists of returning the FCI.
11 Commands EMV 4.2 Book 1
11.3 SELECT Command-Response APDUs Application Independent ICC to
Terminal Interface Requirements
Page 130 June 2008
11.3.2 Command Message
The SELECT command message is coded according to Table 40:

Code Value
CLA '00'
INS 'A4'
P1 Reference control parameter (see Table 41)
P2 Selection options (see Table 42)
Lc '05'–'10'
Data File name
Le '00'
Table 40: SELECT Command Message
Table 41 defines the reference control parameter of the SELECT command
message:

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 0 0 0 0
1 Select by name
0 0
Table 41: SELECT Command Reference Control Parameter
Table 42 defines the selection options P2 of the SELECT command message:

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 0 First or only
occurrence
1 0 Next occurrence
Table 42: SELECT Command Options Parameter
11.3.3 Data Field Sent in the Command Message
The data field of the command message contains the PSE name or the DF name
or the AID to be selected.
EMV 4.2 Book 1 11 Commands
Application Independent ICC to 11.3 SELECT Command-Response APDUs
Terminal Interface Requirements
June 2008 Page 131
11.3.4 Data Field Returned in the Response Message
The data field of the response message contains the FCI specific to the selected
PSE, DDF, or ADF. The tags defined in Table 43, Table 44, and Table 45 apply
to this specification. No additional data elements shall be present in the FCI
template (tag '6F') returned in the response to the SELECT command other than
those contained in template 'BF0C'. Data elements present in templates '6F'
and/or 'BF0C' that are not expected or understood by the terminal because the
terminal does not support any issuer-specific processing shall be ignored.
Table 43 defines the FCI returned by a successful selection of the PSE:

Tag Value Presence
'6F' FCI Template M
'84' DF Name M
'A5' FCI Proprietary Template M
'88' SFI of the Directory Elementary File M
'5F2D' Language Preference O
'9F11' Issuer Code Table Index O
'BF0C' FCI Issuer Discretionary Data O
'XXXX'
(Tag
constructed
according
to Book 3,
Annex B)
1 or more additional
proprietary data
elements from an
application provider,
issuer, or IC card
supplier, or EMV-defined
tags that are specifically
allocated to 'BF0C'
O
Table 43: SELECT Response Message Data Field (FCI) of the PSE
11 Commands EMV 4.2 Book 1
11.3 SELECT Command-Response APDUs Application Independent ICC to
Terminal Interface Requirements
Page 132 June 2008
Table 44 defines the FCI returned by a successful selection of a DDF:

Tag Value Presence
'6F' FCI Template M
'84' DF Name M
'A5' FCI Proprietary Template M
'88' SFI of the Directory Elementary File M
'BF0C' FCI Issuer Discretionary Data O
'XXXX'
(Tag
constructed
according to
Book 3,
Annex B)
1 or more additional
proprietary data elements
from an application
provider, issuer, or IC card
supplier, or EMV-defined
tags that are specifically
allocated to 'BF0C'
O
Table 44: SELECT Response Message Data Field (FCI) of a DDF
EMV 4.2 Book 1 11 Commands
Application Independent ICC to 11.3 SELECT Command-Response APDUs
Terminal Interface Requirements
June 2008 Page 133
Table 45 defines the FCI returned by a successful selection of an ADF:

Tag Value Presence
'6F' FCI Template M
'84' DF Name M
'A5' FCI Proprietary Template M
'50' Application Label O
'87' Application Priority Indicator O
'9F38' PDOL O
'5F2D' Language Preference O
'9F11' Issuer Code Table Index O
'9F12' Application Preferred Name O
'BF0C' FCI Issuer Discretionary Data O
'9F4D' Log Entry O
'XXXX'
(Tag
constructed
according to
Book 3,
Annex B)
1 or more additional
proprietary data elements
from an application
provider, issuer, or IC card
supplier, or EMV-defined
tags that are specifically
allocated to 'BF0C'
O
Table 45: SELECT Response Message Data Field (FCI) of an ADF
Note: For multi-application ICCs, it is strongly recommended that the Application
Label data element be included in the response message in order to facilitate cardholder
choice/confirmation of the application to be used when a terminal employs the List of
AIDs method for application selection.
11 Commands EMV 4.2 Book 1
11.3 SELECT Command-Response APDUs Application Independent ICC to
Terminal Interface Requirements
Page 134 June 2008
11.3.5 Processing State Returned in the Response
Message
'9000' indicates a successful execution of the command.
ICC support for the selection of a DF file using only a partial DF name is not
mandatory. However, if the ICC does support partial name selection, it shall
comply with the following:
- If, after a DF file has been successfully selected, the terminal repeats the
SELECT command having P2 set to the Next Occurrence option (see
Table 42) and with the same partial DF name, the card shall select a
different DF file matching the partial name, if such other DF file exists.
- Repeated issuing of the same command with no intervening application level
commands shall retrieve all such files, but shall retrieve no file twice.
- After all matching DF files have been selected, repeating the same command
again shall result in no file being selected, and the card shall respond with
SW1 SW2 = '6A82' (file not found).
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 135
12 Application Selection
12.1 Overview of Application Selection
During an EMV card session as defined in section 6.1.1, application selection
using the commands and techniques described in sections 11 and 12 shall be the
first process performed immediately after contact activation/reset of the card and
prior to the first application function. If a proprietary processing session
(including any proprietary application selection method) is performed
immediately before or after an EMV card session, there is no requirement to
remove/reinsert the card between the sessions. However, if proprietary
processing occurs before the EMV card session, the card contacts shall be
deactivated before starting the EMV card session.
This section describes the application selection process from the standpoint of
both the card and the terminal. It specifies the logical structure of data and files
within the card that are required for the process, then describes the terminal
logic using the card structure.
It is not recommended that the ICC and the terminal use implicit selection as
defined in ISO 7816, as it is not useful in an interchange environment. If used, it
shall be performed outside the EMV card session as defined in section 6.1.1.
The application selection process described in this section is the process by which
the terminal uses data in the ICC according to protocols defined herein to
determine the terminal program and the ICC application to be used in processing
a transaction. The process is described in two steps:
1. Create a list of ICC applications that are supported by the terminal. (This list
is referred to below using the name ‗candidate list.‘) This process is described
in section 12.3.
2. Select the application to be run from the list generated above. This process is
described in section 12.4.
This section of the specification describes the necessary information in the card
and two terminal selection algorithms that yield the correct results. Other
terminal selection algorithms that yield the same results are permitted in place
of the selection algorithms described here.
12 Application Selection EMV 4.2 Book 1
12.1 Overview of Application Selection Application Independent ICC to
Terminal Interface Requirements
Page 136 June 2008
A payment system application is comprised of the following:
- A set of files in the ICC providing data customised by the issuer
- Data in the terminal provided by the acquirer or the merchant
- An application protocol agreed upon by both the ICC and the terminal
Applications are uniquely identified by AIDs conforming to ISO/IEC 7816-4 (see
section 12.2.1).
The techniques chosen by the payment systems and described herein are
designed to meet the following key objectives:
- Ability to work with ICCs with a wide range of capabilities.
- Ability for terminals with a wide range of capabilities to work with all ICCs
supporting payment system applications according to this specification.
- Conformance with ISO standards.
- Ability of ICCs to support multiple applications, not all of which need to be
payment system applications.
- Ability for ICCs to provide multiple sets of applications to be supported by a
single terminal program. (For example, a card may contain multiple
credit/debit applications, each representing a different type or level of service
or a different account).
- As far as possible, provide the capability for applications conforming with this
specification to co-reside on cards with presently existing applications.
- Minimum overhead in storage and processing.
- Ability for the issuer to optimise the selection process.
The set of data that the ICC contains in support of a given application is defined
by an ADF selected by the terminal using a SELECT command and an
Application File Locator (AFL) returned by the ICC in response to a GET
PROCESSING OPTIONS command.
EMV 4.2 Book 1 12 Application Selection
Application Independent ICC to 12.2 Data in the ICC Used for Application Selection
Terminal Interface Requirements
June 2008 Page 137
12.2 Data in the ICC Used for Application Selection
12.2.1 Coding of Payment System Application Identifier
The structure of the AID is according to ISO/IEC 7816-4 and consists of two
parts:
1. A Registered Application Provider Identifier (RID) of 5 bytes, unique to an
application provider and assigned according to ISO/IEC 7816-4.
2. An optional field assigned by the application provider of up to 11 bytes. This
field is known as a Proprietary Application Identifier Extension (PIX) and
may contain any 0–11 byte value specified by the provider. The meaning of
this field is defined only for the specific RID and need not be unique across
different RIDs.
Additional ADFs defined under the control of other application providers may be
present in the ICC but shall avoid duplicating the range of RIDs assigned to
payment systems. Compliance with ISO/IEC 7816-4 will assure this avoidance.
12 Application Selection EMV 4.2 Book 1
12.2 Data in the ICC Used for Application Selection Application Independent ICC to
Terminal Interface Requirements
Page 138 June 2008
12.2.2 Structure of the PSE
The PSE begins with a DDF given the name ‗1PAY.SYS.DDF01‘. The presence of
this DDF in the ICC is optional but, if present, it shall comply with this
specification. If it is present, this DDF is mapped onto a DF within the card,
which may or may not be the MF. As with all DDFs, this DDF shall contain a
Payment System Directory. The FCI of this DDF shall contain at least the
information defined for all DDFs in section 11 and, optionally, the Language
Preference (tag '5F2D') and the Issuer Code Table Index (tag '9F11').
The Language Preference and Issuer Code Table Index are optional data objects
that may occur in two places: the FCI of the PSE and the FCI of ADF files. If
either of these data elements is present in one location but not the other, the
terminal shall use the data element that is present. If either data element is
present in both locations but has different values in the two locations, the
terminal may use either value.
9

The directory attached to this initial DDF contains entries for ADFs that are
formatted according to this specification, although the applications defined by
those ADFs may or may not conform to this specification. The directory may also
contain entries for other payment system‘s DDFs, which shall conform to this
specification.
The directory is not required to have entries for all DDFs and ADFs in the card,
and following the chain of DDFs may not reveal all applications supported by the
card. However, if the PSE exists, only applications that are revealed by following
the chain of DDFs beginning with the initial directory can be assured of
international interoperability.
See Annex C for examples of the internal logic structure of an ICC containing the
PSE.

9
A terminal building a candidate list using the process described in section 12.3.2 will
encounter the values specified in the FCI of the PSE and will not see the values specified
in the FCI of the ADF until the application to be run has been chosen. A terminal
building the candidate list using the process described in section 12.3.3 will encounter
the values specified in the FCI of the ADFs. To ensure consistent interface to the
cardholder, the values must be the same.
EMV 4.2 Book 1 12 Application Selection
Application Independent ICC to 12.2 Data in the ICC Used for Application Selection
Terminal Interface Requirements
June 2008 Page 139
12.2.3 Coding of a Payment System Directory
A Payment System Directory is a linear EF file identified by a SFI in the range
1 to 10. The SFI for the Payment System Directory is contained in the FCI of the
DDF to which the directory is attached. The Payment System Directory is read
using the READ RECORD command as defined in section 11. A record may have
several entries, but a single entry shall always be encapsulated in a single
record.
Each record in the Payment System Directory is a constructed data object, and
the value field is comprised of one or more directory entries as described below.
Each record is formatted as shown in Table 46:

Tag
'70'
Data
Length
(L)
Tag
'61'
Length
of
directory
entry 1
Directory
entry 1
(ADF or
DDF)
... Tag
'61'
Length
of
directory
entry n
Directory
entry n
(ADF or
DDF)
Table 46: Payment System Directory Record Format
Each entry in a Payment System Directory is the value field of an Application
Template (tag '61') and contains the information according to Table 47 or
Table 48. No additional data elements shall be present in the Payment System
Directory Record (tag ‗70‘) other than those contained in template ‗73‘. Data
elements present in the Payment System Directory Record, template '61', or
template '73' that are not expected or understood by the terminal because the
terminal does not support any issuer-specific processing, shall be ignored.

Tag Length Value Presence
'9D' 5–16 DDF Name M
'73' var. Directory Discretionary Template O
10

'XXXX'
(Tag
construct-
ed
according
to Book 3,
Annex B)
var. 1 or more additional proprietary data
elements from an application provider,
issuer, or IC card supplier, or
EMV-defined tags that are specifically
allocated to template '73'
O
Table 47: DDF Directory Entry Format

10
Other data objects not relevant to this specification may appear in this constructed
data object.
12 Application Selection EMV 4.2 Book 1
12.2 Data in the ICC Used for Application Selection Application Independent ICC to
Terminal Interface Requirements
Page 140 June 2008

Tag Length Value Presence
'4F' 5–16 ADF Name M
'50' 1–16 Application Label M
'9F12' 1–16 Application Preferred Name O
'87' 1 Application Priority Indicator (see Table 49) O
'73' var. Directory Discretionary Template O
11

'XXXX'
(Tag
construct-
ed
according
to Book 3,
Annex B)
var. 1 or more additional proprietary data
elements from an application provider,
issuer, or IC card supplier, or
EMV-defined tags that are specifically
allocated to template '73'
O
Table 48: ADF Directory Entry Format

b8 b7–b5 b4–b1 Definition
1 Application cannot be selected without confirmation
of cardholder
0 Application may be selected without confirmation of
cardholder
xxx RFU
0000 No priority assigned
xxxx
(except
0000)
Order in which the application is to be listed or
selected, ranging from 1–15, with 1 being highest
priority
Table 49: Format of Application Priority Indicator

11
Other data objects not relevant to this specification may appear in this constructed
data object.
EMV 4.2 Book 1 12 Application Selection
Application Independent ICC to 12.3 Building the Candidate List
Terminal Interface Requirements
June 2008 Page 141
12.2.4 Coding of Other Directories
Each directory in an ICC is contained by a separate DDF. DDFs and directories
in the card are optional, and when present there is no defined limit to the
number that may exist. Each directory is located by a Directory SFI data object
which must be contained in the FCI of the DDF (see section 11.3 for a description
of the SELECT command). The low order five bits of the Directory SFI contain
the SFI to be used in READ RECORD commands for reading the directory. The
SFI shall be valid for reading the directory when the DDF containing the
directory is the current file selected.
All directories, including the initial directory, have the same format, as described
in section 12.2.3.
12.2.5 Error Handling for FCI Response Data
The data elements Application Label, Application Preferred Name, Issuer Code
Table Index, and Language Preference are present for the convenience of the
cardholder and are not critical to the successful processing of application
selection. If these data elements are present in the FCI, the issuer is responsible
for their correct encoding.
Terminals shall not enforce the correct formatting of these data elements. If
Application Preferred Name or Application Label contains a character that is not
valid for the defined format, the terminal shall display the character if it is able
to, or if the terminal is unable to display the invalid character, it should omit the
character or substitute a space character or any other appropriate character.
Otherwise, if the terminal detects format errors in any of these data elements,
the terminal shall disregard these errors and act as if the response provided by
the card did not contain these data elements. More specifically, the terminal
shall not terminate the card session but shall proceed with application selection.
If the terminal does not understand the value in Issuer Code Table Index or
Language Preference, it shall treat the data element as not present.
12.3 Building the Candidate List
The terminal shall maintain a list of applications supported by the terminal and
their AIDs. This section describes two procedures for determining which of those
applications is to be run. If the card contains no PSE, the procedure described in
section 12.3.3 must be followed.
The terminal may know other ways that are not described in this section to
locate proprietary applications or to eliminate specific applications in the ICC
from consideration. This is permitted as long as all interoperable applications can
be located in the ICC using the techniques described here.
12 Application Selection EMV 4.2 Book 1
12.3 Building the Candidate List Application Independent ICC to
Terminal Interface Requirements
Page 142 June 2008
12.3.1 Matching Terminal Applications to ICC Applications
The terminal determines which applications in the ICC are supported by
comparing the AIDs for applications in the terminal with AIDs for applications
within the ICC.
In some cases, the terminal supports the ICC application only if the AID in the
terminal has the same length and value as the AID in the ICC. This case limits
the ICC to at most one matching ADF.
In other cases, the terminal supports the ICC application if the AID in the ICC
begins with the entire AID kept within the terminal. This allows the ICC to have
multiple ADFs matching the terminal application by adding unique information
to the AID used by each of the ADFs. If the card has only one ADF matching the
terminal AID, it should identify that ADF with the exact AID known to the
terminal. If the ICC has multiple ADFs supported by a single terminal AID, the
following requirements must be met by the ICC:
- The ICC must support partial name selection as described in section 11.3.5
(see SELECT command).
- All of the matching AIDs in the ICC must be distinguished by adding unique
data to the PIX. None of the ICC AIDs shall be the same length as the AID in
the terminal.
For each of the AIDs within the list of applications supported by the terminal,
the terminal shall keep an indication of which matching criterion to use.
EMV 4.2 Book 1 12 Application Selection
Application Independent ICC to 12.3 Building the Candidate List
Terminal Interface Requirements
June 2008 Page 143
12.3.2 Using the PSE
If a terminal chooses to support application selection using the PSE method, it
shall follow the procedure described in this section to determine the applications
supported by the card. Figure 17 is a flow diagram of the logic described here.
The terminal performs the following steps:
1. The terminal begins by selecting the PSE using a SELECT command as
described in section 11 and a file name of ‗1PAY.SYS.DDF01‘. This
establishes the PSE and makes the initial Payment System Directory
accessible.
If the card is blocked or the SELECT command is not supported (both
conditions represented by SW1 SW2 = '6A81'), the terminal terminates the
session.
If there is no PSE in the ICC, the ICC shall return '6A82' (‗File not found‘) in
response to the SELECT command for the PSE. In this case, the terminal
shall use the List of AIDs method described in section 12.3.3.
If the PSE is blocked, the ICC shall return '6283'. In this case, the terminal
shall use the List of AIDs method described in section 12.3.3.
If the ICC returns SW1 SW2 = '9000', the terminal proceeds to step 2.
If the card returns any other value in SW1 SW2, the terminal shall use the
List of AIDs method described in section 12.3.3.
If any error, including a SW1 SW2 different from '90 00' or '6A 83', occurs in
steps 2 through 5, the terminal shall clear the candidate list and restart the
application selection process using the List of AIDs method described in
section 12.3.3 to find the matching applications.
2. The terminal uses the Directory SFI from the FCI returned and reads all the
records in the Payment System Directory beginning with record number 1
and continuing with successive records until the card returns SW1 SW2 =
'6A83', which indicates that the record number requested does not exist. (The
card shall return '6A83' if the record number in the READ RECORD
command is greater than the number of the last record in the file). If the card
returns SW1 SW2 = '6A83' in response to a READ RECORD for record
number 1 for the Payment System Directory, no directory entries exist, and
step 6 (below) applies.
For each record in the Payment System Directory, the terminal begins with
the first directory entry and processes each directory entry in turn as
described in steps 3 through 5. If there are no directory entries in the record,
the terminal proceeds to the next directory record.
12 Application Selection EMV 4.2 Book 1
12.3 Building the Candidate List Application Independent ICC to
Terminal Interface Requirements
Page 144 June 2008
3. If the entry is for an ADF and the ADF name matches one of the applications
supported by the terminal as defined in section 12.3.1, the application joins
the candidate list for final application selection under control of the
Application Selection Indicator (ASI) maintained in the terminal for that
AID.
The ASI indicates whether the AID in the terminal shall match exactly (both
in length and name) or need only partially match the associated ADF name in
the card (tag '4F').
The application is added to the candidate list in either of the following cases:
 the AID entry retrieved is an exact match, or
 the ASI for the AID in the terminal indicates that a partial match is
allowed.
The application is not added to the candidate list if the ADF entry retrieved is
not an exact match and the ASI for the AID in the terminal indicates that an
exact match is required.
4. If the entry is for a DDF, the terminal interrupts processing of the current
directory record, places resumption information on the stack, and selects the
DDF indicated using the DDF name. The new directory is read and processed
according to steps 2 through 5, after which the terminal resumes processing
the previously interrupted directory at the point of interruption.
5. When the terminal finishes processing all entries in the last record of the
Payment System Directory, all ADFs that can be found by this procedure
have been determined. The search and the candidate list are complete. If at
least one matching AID was found, the terminal continues processing as
described in section 12.4.
6. If steps 1 through 5 yield no directory entries that match applications
supported by the terminal, the terminal shall use the list of AIDs method
described in section 12.3.3 to find a match.
EMV 4.2 Book 1 12 Application Selection
Application Independent ICC to 12.3 Building the Candidate List
Terminal Interface Requirements
June 2008 Page 145

Figure 17: Terminal Logic Using Directories
Begin Application
Selection
Terminal
Supports
PSE?
Select DFNAME =
' 1PAY.SYS.DDF01 '
SW1 SW2
= ' 6A81 ' ?
PSE
Found?
No
Yes
No
PSE
Blocked?
Selection
from terminal
list
No
Yes
Yes
Terminate
Session
See “Using a List of
AIDs” in next section
Empty candidate list
No
Get SFI for directory from FCI
Set record number for read to 1
Read directory record
Record
found?
Is there
an entry in this
record?
Get first entry from record
Is entry for
an ADF?
Terminal
supports
application?
Add to candidate list
Yes
Is there an
entry on the
directory stack?
Yes
Get previous directory
entry from stack
Resume processing
previous directory
Interrupt current directory
& place resumption
information on stack
Get DDF name from entry
Select new DDF
Is there
another entry in
this record?
Get next entry
Increment record
number for next
read by 1
Yes
Are there any
entries on the
candidate list?
No
Candidate list is
complete. Choose
application from
candidate list.
Yes Yes
Yes
No
ADF is exact
match of AID?
Yes
Check terminal‟s
Application Selection
Indicator
Partial match
allowed?
Yes
No
If the terminal and card support implicit
selection as defined by ISO 7816-4, it is
performed prior to this step.
No
No
No
Yes
No
No
Yes No
12 Application Selection EMV 4.2 Book 1
12.3 Building the Candidate List Application Independent ICC to
Terminal Interface Requirements
Page 146 June 2008
12.3.3 Using a List of AIDs
If either the card or the terminal does not support the PSE method or if the
terminal is unable to find a matching application using the Payment System
Directory selection method, the terminal shall use a list of AIDs that it supports
to build the candidate list. Figure 18 is a flow diagram of the logic described here.
The terminal performs the following steps:
1. The terminal issues a SELECT command using the first AID
12
in the
terminal list as the file name.
2. If the SELECT command fails because the card is blocked or the command is
not supported by the ICC (SW1 SW2 = '6A81'), the terminal terminates the
card session.
3. If the SELECT command is successful (SW1 SW2 = '9000' or '6283'), the
terminal compares the AID with the DF Name field returned in the FCI. The
DF Name will either be identical to the AID (including the length), or the DF
Name will start with the AID but will be longer. If the names are identical,
the terminal proceeds with step 4. If the DF Name is longer, the card
processed the command as a partial name selection, and the terminal
proceeds to step 6.
If the card returns any other status or if mandatory data is missing from the
SELECT response or if the FCI contains formatting errors not described in
Section 12.2.5, the terminal proceeds to Step 5 without adding the DF Name
to the candidate list.
4. If the SELECT command is successful (SW1 SW2 = '9000'), the terminal adds
the FCI information from the selected file to the candidate list 13 and
proceeds to step 5. If the application is blocked (SW1 SW2 = '6283'), the
terminal proceeds to step 5 without adding the DF Name to the candidate
list.
5. The terminal issues another SELECT command using the next AID in its list
and returns to step 3. If there are no more AIDs in the list, the candidate list
is complete, and the terminal proceeds as specified in section 12.4.

12
To assist in a clear understanding of the process described in this section, it is
necessary to distinguish between the AID kept in the terminal and the AID kept in the
ICC. As can be seen in section 12.3.1, these might not be identical even for matching
applications. In this procedure, the term AID is used for the application identifier kept
in the terminal, and DF Name is used for the application identifier in the card.
13
The Application Label and Application Preferred Name must also be saved if the
cardholder will be provided a list during final selection. The DF Name and the
Application Priority Indicator will be required in any case.
EMV 4.2 Book 1 12 Application Selection
Application Independent ICC to 12.3 Building the Candidate List
Terminal Interface Requirements
June 2008 Page 147
6. Along with the AID list, the terminal keeps an Application Selection Indicator
that indicates whether the card may have multiple occurrences of the
application within the card. The terminal checks this indicator. If the
indicator says that an exact match (in both length and name) is required, the
terminal does not add the file to the candidate list, but proceeds to step 5.
If multiple occurrences are permitted, the partial name match is sufficient. If
the application is not blocked (SW1 SW2 = '9000'), the terminal adds the FCI
information to the candidate list and proceeds to step 7.
If multiple occurrences are permitted but the application is blocked
(SW1 SW2 = '9000'), the terminal proceeds to step 7 without adding the FCI
information to the candidate list.
7. The terminal repeats the SELECT command using the same command data
as before, but changes P2 in the command to '02' (Select Next). If the ICC
returns SW1 SW2 = '9000', '62xx', or '63xx', the terminal returns to step 3. If
it returns a different SW1 SW2, the terminal goes to step 5.
12 Application Selection EMV 4.2 Book 1
12.3 Building the Candidate List Application Independent ICC to
Terminal Interface Requirements
Page 148 June 2008


Figure 18: Using the List of AIDs in the Terminal
Begin Application
Selection
Get first AID from
terminal list
SW1 SW2
= ' 6A81 ' ?
DFname in
FCI = AID?
Yes
No
Finished. Go to
final selection
No
Check Application
Selection Indicator in
terminal
No
Add FCI information
to candidate list
No
Yes
Empty candidate list
SELECT File using
DF name = AID
Must be identical,
including length
Application
blocked?
Partial name
match allowed?
File found
including all
mandatory
data?
Yes
Add FCI
information to
candidate list
No
Is there
another AID
in list?
Get next AID
from list
Yes
SELECT File using
DF name = AID
Application
blocked?
SELECT NEXT
with DF name =
terminal AID
No
No
Yes
Yes
SW1 SW2 =
9000, 62xx, or
63xx
Yes
No
Yes
Terminate Session
EMV 4.2 Book 1 12 Application Selection
Application Independent ICC to 12.4 Final Selection
Terminal Interface Requirements
June 2008 Page 149
12.4 Final Selection
Once the terminal determines the list of mutually supported applications, it
proceeds as follows:
1. If there are no mutually supported applications, the transaction is
terminated.
2. If there is only one mutually supported application, the terminal checks b8 of
the Application Priority Indicator for that application if present.
 If b8 = '0', the terminal selects the application.
 If b8 = '1' and the terminal provides for confirmation by the
cardholder, the terminal requests confirmation and selects the
application if the cardholder approves. If the terminal does not provide
for confirmation by the cardholder, or if the terminal requests
confirmation and the cardholder does not approve, the terminal
terminates the session.
3. If multiple applications are supported, the terminal may offer a selection to
the cardholder as described in step 4, or make the selection itself as described
in step 5. Step 4 is the preferred method.
4. If a list is presented to the cardholder, it shall be in priority sequence, with
the highest priority application listed first. If there is no priority sequence
specified in the card, the list should be in the order in which the applications
were encountered in the card, unless the terminal has its own preferred
order. The same applies where duplicate priorities are assigned to multiple
applications or individual entries are missing the Application Priority
Indicator; that is, in this case, the terminal may use its own preferred order
or display the duplicate priority or non-prioritised applications in the order
encountered in the card.
5. The terminal may select the application without cardholder assistance. In
this case, the terminal shall select the highest priority application from the
list of mutually supported applications, except that if the terminal does not
provide for confirmation of the selected application, applications prohibiting
such selection (b8 = '1' in the Application Priority Indicator) shall be excluded
from possible selection.
12 Application Selection EMV 4.2 Book 1
12.4 Final Selection Application Independent ICC to
Terminal Interface Requirements
Page 150 June 2008
Once the application to be run is determined by the terminal or by the
cardholder, the application shall be selected. A SELECT command coded
according to section 11 shall be issued by the terminal for the application using
the ADF Name field (if the directories were read) or the DF Name field from the
FCI (if the List of AIDs method was used) found during the building of the
candidate list. If the command returns other than '9000' in SW1 SW2 or the
SELECT response contains format errors other than those described in
section 12.2.5, the application shall be removed from the candidate list, and
processing shall resume at step 1. If the cardholder selects or confirms the
selection of an application that is subsequently removed from the candidate list
due to its being blocked or for any other reason, no application is to be selected
without cardholder confirmation.
In any case, the terminal shall inform the cardholder of the action taken, if
appropriate.
EMV 4.2 Book 1 12 Application Selection
Application Independent ICC to 12.4 Final Selection
Terminal Interface Requirements
June 2008 Page 151

EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 153
Part IV

Annexes
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page 154 June 2008
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 155
Annex A Examples of Exchanges Using T=0
The following examples illustrate exchanges of data and procedure bytes between
the TTL and ICC.
Note the following:
- The use of procedure bytes '60' and INS is not illustrated.
- [Data(x)] means x bytes of data.
- Case 2 and 4 commands have Le = '00' requesting the return of all data from
the ICC up to the maximum available. Le = '00' is used in these examples to
illustrate typical exchanges that may be observed when executing the
application specified in Book 3. Le may take other values when executing a
proprietary application.
Sections A1 to A4 illustrate typical exchanges using case 1 to 4 commands.
Sections A5 and A6 illustrate the more extensive use of procedure bytes '61 xx'
when used with case 2 and 4 commands. Section A7 illustrates a warning
condition with a case 4 command.
A1 Case 1 Command
A C-APDU of {CLA INS P1 P2} is passed from the TAL to the TTL (note that P3
of the C-TPDU is set to '00').

TTL ICC
[CLA INS P1 P2 00] ¬
: 90 00

A R-APDU of {90 00} is returned from the TTL to the TAL.
Annex A Examples of Exchanges Using T=0 EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page 156 June 2008
A2 Case 2 Command
A C-APDU of {CLA INS P1 P2 00} is passed from the TAL to the TTL.

TTL ICC
[CLA INS P1 P2 00] ¬
: 6C Licc
[CLA INS P1 P2 Licc] ¬
: INS [Data(Licc)] 90 00

A R-APDU of {[Data(Licc)] 90 00} is returned from the TTL to the TAL.
A3 Case 3 Command
A C-APDU of {CLA INS P1 P2 Lc [Data(Lc)]} is passed from the TAL to the TTL.

TTL ICC
[CLA INS P1 P2 Lc] ¬
: INS
[Data(Lc)] ¬
: 90 00

A R-APDU of {90 00} is returned from the TTL to the TAL.
EMV 4.2 Book 1 Annex A Examples of Exchanges Using T=0
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 157
A4 Case 4 Command
A C-APDU of {CLA INS P1 P2 Lc [Data (Lc)] 00} is passed from the TAL to the
TTL.

TTL ICC
[CLA INS P1 P2 Lc] ¬
: [INS]
[Data(Lc)] ¬
: 61 Licc
[00 C0 00 00 Licc] ¬
: C0 [Data(Licc)] 90 00

A R-APDU of {[Data(Licc)] 90 00} is returned from the TTL to the TAL.
A5 Case 2 Command Using the '61' and '6C'
Procedure Bytes
A C-APDU of {CLA INS P1 P2 00} is passed from the TAL to the TTL.

TTL ICC
[CLA INS P1 P2 00] ¬
: 6C Licc
[CLA INS P1 P2 Licc] ¬
: 61 xx
[00 C0 00 00 yy] ¬
: C0 [Data(yy)] 61 zz
[00 C0 00 00 zz] ¬
: C0 [Data(zz)] 90 00

Where yy s xx
A R-APDU of {[Data(yy + zz)] 90 00} is returned from the TTL to the TAL.
Annex A Examples of Exchanges Using T=0 EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page 158 June 2008
A6 Case 4 Command Using the '61' Procedure Byte
A C-APDU of {CLA INS P1 P2 Lc [Data Lc] 00} is passed from the TAL to the
TTL.

TTL ICC
[CLA INS P1 P2 Lc] ¬
: [INS]
[Data(Lc)] ¬
: 61 xx
[00 C0 00 00 xx] ¬
: C0 [Data(xx)] 61 yy
[00 C0 00 00 yy] ¬
: C0 [Data(yy)] 90 00

A R-APDU of {[Data(xx + yy)] 90 00} is returned from the TTL to the TAL.
A7 Case 4 Command with Warning Condition
A C-APDU of {CLA INS P1 P2 Lc [Data Lc] 00} is passed from the TAL to the
TTL.

TTL ICC
[CLA INS P1 P2 Lc] ¬
: [INS]
[Data(Lc)] ¬
: 62 xx
[00 C0 00 00 00] ¬
: 6C Licc
[00 C0 00 00 Licc] ¬
: C0 [Data(Licc)] 90 00

A R-APDU of {[Data(Licc)] 62 xx} is returned from the TTL to the TAL
containing the data returned together with the warning status bytes.
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 159
Annex B Data Elements Table
Table 50 defines those data elements that may be used for application selection and their mapping onto data objects
and files.
14
Table 51 lists the data elements in tag sequence.
The characters used in the ―Format‖ column are described in section 4.3, Data Element Format Convention.
B1 Data Elements by Name
Name Description Source Format Template Tag Length
Application
Identifier (AID) -
card
Identifies the application as described
in ISO/IEC 7816-4
ICC b '61' '4F' 5–16
Application
Identifier (AID) -
terminal
Identifies the application as described
in ISO/IEC 7816-4
Terminal b — '9F06' 5–16
Table 50: Data Elements Table

14
Annex A of Book 3 provides a complete data elements table, defining all data elements that may be used for financial transaction
interchange and their mapping onto data objects and files.
EMV 4.2 Book 1 Annex B Data Elements Table
Application Independent ICC to B1 Data Elements by Name
Terminal Interface Requirements
June 2008 Page 160
Name Description Source Format Template Tag Length
Application
Label
Mnemonic associated with the AID
according to ISO/IEC 7816-4
ICC ans with the
special
character
limited to
space
'61' or 'A5' '50' 1–16
Application
Preferred Name
Preferred mnemonic associated with the
AID
ICC ans (see
section 4.3)
'61' or 'A5' '9F12' 1–16
Application
Priority
Indicator
Indicates the priority of a given
application or group of applications in a
directory
ICC b '61' or 'A5' '87' 1
Application
Selection
Indicator
For an application in the ICC to be
supported by an application in the
terminal, the Application Selection
Indicator indicates whether the
associated AID in the terminal must
match the AID in the card exactly,
including the length of the AID, or only
up to the length of the AID in the
terminal
There is only one Application Selection
Indicator per AID supported by the
terminal
Terminal At the
discretion of
the
terminal.
The data is
not sent
across the
interface
— — See
Format
Application
Template
Contains one or more data objects
relevant to an application directory
entry according to ISO/IEC 7816-4
ICC

b '70' '61' var. up
to 252
Table 50: Data Elements Table, continued
EMV 4.2 Book 1 Annex B Data Elements Table
Application Independent ICC to B1 Data Elements by Name
Terminal Interface Requirements
June 2008 Page 161
Name Description Source Format Template Tag Length
Bank Identifier
Code (BIC)
Uniquely identifies a bank as defined in
ISO 9362.
ICC var. 'BF0C' or
'73'
'5F54' 8 or 11
Dedicated File
(DF) Name
Identifies the name of the DF as
described in ISO/IEC 7816-4
ICC b '6F' '84' 5–16
Directory
Definition File
(DDF) Name
Identifies the name of a DF associated
with a directory
ICC b '61' '9D' 5–16
Directory
Discretionary
Template
Issuer discretionary part of the
directory according to ISO/IEC 7816-4
ICC var. '61' '73' var. up
to 252
File Control
Information
(FCI) Issuer
Discretionary
Data
Issuer discretionary part of the FCI ICC var. 'A5' 'BF0C' var. up
to 222
File Control
Information
(FCI)
Proprietary
Template
Identifies the data object proprietary to
this specification in the FCI template
according to ISO/IEC 7816-4
ICC var. '6F' 'A5' var.
File Control
Information
(FCI) Template
Identifies the FCI template according to
ISO/IEC 7816-4
ICC var. — '6F' var. up
to 252
Table 50: Data Elements Table, continued
EMV 4.2 Book 1 Annex B Data Elements Table
Application Independent ICC to B1 Data Elements by Name
Terminal Interface Requirements
June 2008 Page 162
Name Description Source Format Template Tag Length
International
Bank Account
Number (IBAN)
Uniquely identifies the account of a
customer at a financial institution as
defined in ISO 13616.
ICC var. 'BF0C' or
'73'
'5F53' Var. up
to 34
Issuer Code
Table Index
Indicates the code table according to
ISO/IEC 8859 for displaying the
Application Preferred Name
ICC n 2 'A5' '9F11' 1
Issuer Country
Code (alpha2
format)
Indicates the country of the issuer as
defined in ISO 3166 (using a
2 character alphabetic code)
ICC a 2 'BF0C' or
'73'
'5F55' 2
Issuer Country
Code (alpha3
format)
Indicates the country of the issuer as
defined in ISO 3166 (using a
3 character alphabetic code)
ICC a 3 'BF0C' or
'73'
'5F56' 3
Industry
Identification
Number (IIN)
The number that identifies the major
industry and the card issuer and that
forms the first part of the Primary
Account Number (PAN)
ICC n 6 'BF0C' or
'73'
'42' 3
Issuer URL The URL provides the location of the
issuer‘s Library Server on the Internet
ICC ans 'BF0C' or
'73'
'5F50' var.
Table 50: Data Elements Table, continued
EMV 4.2 Book 1 Annex B Data Elements Table
Application Independent ICC to B1 Data Elements by Name
Terminal Interface Requirements
June 2008 Page 163
Name Description Source Format Template Tag Length
Language
Preference
1–4 languages stored in order of
preference, each represented by
2 alphabetical characters according to
ISO 639
Note: EMVCo strongly recommends that
cards be personalised with data element
'5F2D' coded in lowercase, but that
terminals accept the data element whether
it is coded in upper or lower case.
ICC an 2 'A5' '5F2D' 2–8
Log Entry Provides the SFI of the Transaction Log
file and its number of records
ICC b 'BF0C' or
'73'
'9F4D' 2
Processing
Options Data
Object List
(PDOL)
Contains a list of terminal resident data
objects (tags and lengths) needed by the
ICC in processing the GET
PROCESSING OPTIONS command
ICC b 'A5' '9F38' var.
READ RECORD
Response
Message
Template
Contains the contents of the record
read. (Mandatory for SFIs 1-10.
Response messages for SFIs 11-30 are
outside the scope of EMV, but may use
template '70'.)
ICC var. — '70' var. up
to 252
Short File
Identifier (SFI)
Identifies the AEF referenced in
commands related to a given ADF or
DDF. It is a binary data object having a
value in the range 1 – 30 and with the
three high order bits set to zero.
ICC b 'A5' '88' 1
Table 50: Data Elements Table, continued
EMV 4.2 Book 1 Annex B Data Elements Table
Application Independent ICC to B1 Data Elements by Name
Terminal Interface Requirements
June 2008 Page 164
When the length defined for the data object is greater than the length of the actual data, the following rules apply:
- A data element in format n is right justified and padded with leading hexadecimal zeroes.
- A data element in format a, an, or ans is left justified and padded with trailing hexadecimal zeroes.
When data is moved from one entity to another (for example, card to terminal), it shall always be passed in order from
high order to low order, regardless of how it is internally stored. The same rule applies when concatenating data.
EMV 4.2 Book 1 Annex B Data Elements Table
Application Independent ICC to B2 Data Elements by Tag
Terminal Interface Requirements
June 2008 Page 165
B2 Data Elements by Tag
Name Template Tag
Industry Identification Number (IIN) 'BF0C' or '73' '42'
Application Identifier (AID) - card '61' '4F'
Application Label '61' or 'A5' '50'
Language Preference 'A5' '5F2D'
Issuer URL 'BF0C' or '73' '5F50'
International Bank Account Number (IBAN) 'BF0C' or '73' '5F53'
Bank Identifier Code (BIC) 'BF0C' or '73' '5F54'
Issuer Country Code (alpha2 format) 'BF0C' or '73' ‗5F55‘
Issuer Country Code (alpha3 format) 'BF0C' or '73' '5F56'
Application Template '70' '61'
File Control Information (FCI) Template — '6F'
READ RECORD Response Message Template — '70'
Directory Discretionary Template '61' '73'
Dedicated File (DF) Name '6F' '84'
Application Priority Indicator '61' or 'A5' '87'
Short File Identifier (SFI) 'A5' '88'
Directory Definition File (DDF) Name '61' '9D'
Application Identifier (AID) - terminal — '9F06'
Issuer Code Table Index 'A5' '9F11'
Application Preferred Name '61' or 'A5' '9F12'
Processing Options Data Object List (PDOL) 'A5' '9F38'
Log Entry 'BF0C' or '73' '9F4D'
File Control Information (FCI) Proprietary
Template
'6F' 'A5'
File Control Information (FCI) Issuer
Discretionary Data
'A5' 'BF0C'
Table 51: Data Elements Tags
Annex B Data Elements Table EMV 4.2 Book 1
B2 Data Elements by Tag Application Independent ICC to
Terminal Interface Requirements
Page 166 June 2008

EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 167
Annex C Examples of Directory Structures
This annex illustrates some possible logical ICC file structures.
C1 Single Application Card
Figure 19 illustrates a single application card with only a single level directory.
In this example, the MF (with file identification of '3F00', as defined by
ISO/IEC 7816-4) acts as the only DDF in the card. The MF shall be given the
unique payment system‘s name assigned to the first level DDF as defined in
section 12.2, and the FCI of the MF shall contain the SFI data object.
‗DIR A‘ in this example may or may not be the ISO DIR file, but it shall conform
to this specification, including the requirement that it has a SFI in the range
1 to 10.

MF
ADF
EF
EF
DIR A

Figure 19: Simplest Card Structure Single Application
Annex C Examples of Directory Structures EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page 168 June 2008
C2 Single Level Directory
Figure 20 gives an example of a multi-application card with a single directory. In
this example, the root file (MF) does not support an application complying with
this specification, and no restrictions are placed on the function of the MF.
According to ISO/IEC 7816-4, a DIR file may be present but is not used by the
application selection algorithm defined in section 12. Also note that the directory
does not have entries for all ADFs (ADF2 to ADF5), as ADF5 is omitted. ADF5
can be selected only by a terminal that ‗knows‘ ADF5 may exist in the card. The
manner in which the terminal finds ADF5 is outside the scope of this
specification.

DDF1
ADF 5
ADF 4 ADF 3
EF
EF
EF
EF
EF
EF
DIR A
ADF 2
EF
MF

Figure 20: Single Level Directory
EMV 4.2 Book 1 Annex C Examples of Directory Structures
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 169
C3 Multi-Level Directory
Figure 21 is an example of a multi-application card with an n level directory
structure. The first level directory (‗DIR A‘) has entries for 2 ADFs ÷ ADF3 and
ADF4 ÷ and a single DDF ÷ DDF2. The directory attached to DDF2 (‗DIR B‘) has
entries for two ADFs ÷ ADF21 and ADF22 ÷ and a single DDF ÷ DDF6. DDF5
has no entry in the root directory and can be found only by a terminal that
‗knows‘ of the existence of DDF5. The manner in which the terminal finds and
selects DDF5 is outside the scope of this specification, but the directory attached
to DF5 (‗DIR C‘) may conform to this specification, and, if found by the terminal,
may lead the terminal to ADFs such as DF51, DF52, and DF53. DIR D, attached
to DDF6, is a third level directory and points to four files (not shown), which may
be either ADFs or more DDFs.

DDF1
ADF 53 ADF 52
ADF 22
ADF 51
ADF 21
DDF 5 ADF 4
ADF 3
DDF 2
EF
EF EF EF
EF
EF EF
EF EF
DIR A
DIR B
DIR C
DDF6
MF
DIR D

Figure 21: Third Level Directory
Annex C Examples of Directory Structures EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page 170 June 2008
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 171
Part V

Common Core
Definitions
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page 172 June 2008
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 173
Common Core Definitions
This Part describes an optional extension to this Book, to be used when
implementing the Common Core Definitions (CCD). It is to be used in
conjunction with Books 2, 3, and 4, including the Common Core Definitions part
of Books 2 and 3.
These Common Core Definitions specify a minimum common set of card
application implementation options, card application behaviours, and data
element definitions sufficient to accomplish an EMV transaction. Terminals
certified to be compliant with the existing EMV specifications will, without
change, accept cards implemented according to the Common Core Definitions,
since the Common Core Definitions are supported within the existing EMV
requirements. To be compliant with the Common Core Definitions, an
implementation shall implement all the additional requirements in the Common
Core Definitions sections of all affected Books.
Changed Sections
Each section heading below refers to the section in this Book to which the
additional requirements apply. The text defines requirements for a common core
implementation, in addition to the requirements already specified in the
referenced section of EMV.
Common Core Definitions EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page 174 June 2008
Part III - Files, Commands, and Application
Selection
10 Files
10.1 File Structure
10.1.4 Directory Structure
The directory structure within the PSE shall not contain any optional additional
directories introduced by a DDF.
11 Commands
11.3 SELECT Command-Response APDUs
11.3.5 Processing State Returned in the Response Message
The ICC shall support partial name selection and shall accept SELECT
command messages containing at least the 5 high-order bytes of the DF name
(that is, the RID). Select Next functionality shall be supported.
EMV 4.2 Book 1 Common Core Definitions
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 175
12 Application Selection
12.2 Data in the ICC Used for Application Selection
12.2.2 Structure of the PSE
If the card has a PSE, the PSE shall contain only one DDF, the highest level
DDF, ‗1PAY.SYS.DDF01‘. No other DDFs shall be present. A graphic example
of the internal logic structure of a CCD-compliant card can be found in Appendix
C, Figure 20, where DDF1 is ‗1PAY.SYS.DDF01‘.
12.2.3 Coding of a Payment System Directory
A Payment System Directory Record shall contain only ADF entries; DDF entries
are not allowed. Each record in the Payment System Directory shall be formatted
as in Table CCD 1:

Tag
'70'
Data
Length
(L)
Tag
'61'
Length of
directory
entry 1
Directory
entry 1
(ADF)
... Tag
'61'
Length of
directory
entry n
Directory
entry n
(ADF)
Table CCD 1: Payment System Directory Record Format for CCD-Compliant
Card
Common Core Definitions EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page 176 June 2008

Index
1
1PAY.SYS.DDF01 ................................... 138, 143
'
'60' . ..................................................................91
'61' . .................................................................91
'6C' . .................................................................91
A
Abbreviations .....................................................19
Abnormal Termination of Transaction Process ....64
Abort Request................................................... 104
Accept an ATR ...................................................73
ACK ...................................................................95
Acknowledged .................................................. 101
Additional Work Waiting Time ...........................91
ADF ................................................................. 121
Directory Entry Format ................................ 140
AEF...................... See Application Elementary File
AFL .................................................................. 136
AID .......................................................... 122, 136
Answer to Reset .................................................69
Basic..............................................................70
Character Definitions .....................................72
Characters Returned by ICC ...........................70
Flow at the Terminal ......................................85
Physical Transportation of Characters Ret’d ...69
Terminal Behaviour .......................................83
Application Definition File ....................... See ADF
Application Elementary File ..................... 121, 122
Application Identifier ................................. See AID
Application Label ..................................... 133, 146
Application Layer ....................................... 87, 115
C-APDU ...................................................... 116
R-APDU ...................................................... 117
Application Preferred Name.............................. 146
Application Priority Indicator ............................ 149
Format ......................................................... 140
Application Selection ........................................ 135
Building Candidate List ............................... 141
Final Selection ............................................. 149
List of AIDs Method .................................... 146
PSE Method ................................................. 143
Using Data in ICC ........................................ 137
Application Selection Indicator .................. See ASI
Application Template ....................... 122, 139, 160
ASI ........................................................... 144, 147
Assignment of Contacts ................................ 39, 48
Asynchronous Half Duplex .................................65
ATR ....................................... See Answer to Reset
B
Basic ATR .................................................... 70, 72
Basic ATR for T=0 Only .....................................70
Basic ATR for T=1 Only .....................................71
Basic Response ...................................................72
Basic Response Coding
Character T0 ..................................................74
Character TA3 ...............................................81
Character TB1 ...............................................76
Character TB3 ...............................................82
Character TC1 ...............................................77
Character TD1 ...............................................78
Character TD2 ...............................................80
Bit Duration .......................................................65
Bit Rate Adjustment Factor.................................75
Bit Synchronisation ............................................73
Block Protocol T=1 ....................................... 87, 94
Block Frame Structure ...................................94
Chaining ...................................................... 101
Error Detection and Correction ..................... 104
Error Free Operation .................................... 100
Information Field Sizes and Timings ..............98
Blocks, Types .....................................................95
Body ................................................................. 127
Building Candidate List for Application Selection
.................................................................... 141
BWI ............................................................. 74, 82
BWT .................................................... 82, 99, 101
BWT Time-out ................................................. 104
C
C-APDU ..................................................... 90, 116
Chaining ...................................................... 103
Content ........................................................ 126
Format ......................................................... 126
Structure ...................................................... 126
Structures .................................................... 116
Card Session Stages ............................................59
Cases for Data in APDUs.................................. 115
CCD ........................ See Common Core Definitions
Chaining ........................................................... 101
C-APDU ...................................................... 103
I-blocks ................................................ 101, 103
Character ............................................................93
Character Definitions ..........................................72
EMV 4.2 Book 1 Index
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 177
Character Frame ..................................... 66, 87, 88
Character Protocol T=0 ................................. 87, 89
Character Timing ...........................................89
Command Header ..........................................90
Command Processing .....................................90
Example Exchanges ..................................... 155
Transportation of C-APDUs ...........................92
Character Repetition ...........................................93
Characters Returned by ICC at Answer to Reset ..70
Check Character TCK .........................................83
CLA ........................................................... 90, 116
Classes of Operation ...........................................45
Clock
ICC Electrical Characteristics.........................43
Terminal Electrical Characteristics .................52
Clock Rate Conversion Factor .............................75
Coding PCB of
I-block ...........................................................96
R-block ..........................................................96
S-block ..........................................................96
Cold Reset ..........................................................61
Command
READ RECORD .......................................... 127
SELECT ...................................................... 129
Command Application Protocol Data Unit.....See C-
APDU
Command Class ..................................................90
Command Data ................................................. 115
Command Header ...............................................90
Command Message Structure .................... 114, 125
Command Processing Qualifier (SW2) .............. 127
Command Processing Status (SW1) .................. 127
Command Transport Protocol Data Unit........See C-
TPDU
Command-Response Pair .................................. 115
Common Core Definitions ................................ 173
Coding Payment System Directory................ 175
Data in ICC Used for Application Selection .. 175
Directory Structure ....................................... 174
PSE Structure .............................................. 175
SELECT Command-Response APDUs ......... 174
Conditional Body .............................................. 126
Contact
Activation Sequence .......................................60
Assignment .............................................. 39, 48
Deactivation Sequence ...................................63
Force .............................................................48
Layout............................................................39
Location ................................................... 38, 47
Resistance ................................................ 46, 56
C-TPDU .............................................................90
Current etu .........................................................65
Current Requirement
ICC Electrical Characteristics.........................45
Terminal Electrical Characteristics .................54
CWI ............................................................. 74, 82
CWT ..................................................................82
D
D . .............................................................. 74, 75
DAD...................................................................95
Data Byte ...........................................................66
Data Element .................................................... 121
Data Element Format Conventions ......................29
Data Elements Table ........................................ 159
Data in ICC Used for Application Selection ...... 137
Data Link Layer ............................................ 87, 88
Character Frame ............................................88
Data Transfer Rates ............................................75
DDF ......................................................... 121, 167
Directory Entry Format ................................ 139
Definitions .......................................................... 9
Destination Node Address ....................... See DAD
DF Name .................................................. 123, 146
DI . ...................................................................75
DIR .................................................................. 122
Direct Logic Convention .....................................73
Directory Definition File ........................... See DDF
Directory Discretionary Template ..................... 122
Directory SFI .................................................... 141
Directory Structure ........................................... 122
Examples ..................................................... 167
Disputed Character .............................................93
E
EDC ........................................................... 97, 100
EDC Error .................................................. 97, 104
Electrical Characteristics, ICC ............................40
Clock .............................................................43
Contact Resistance .........................................46
Current Requirement......................................45
I/O Reception .................................................41
I/O Transmission............................................42
Reset .............................................................44
Temperature Range ........................................40
VCC ..............................................................45
VPP ...............................................................42
Electrical Characteristics, Terminal ....................48
Clock .............................................................52
Contact Resistance .........................................56
Current Requirement......................................54
I/O Current Limit ...........................................49
I/O Reception .................................................51
I/O Transmission............................................50
Powering and Depowering .............................57
Reset .............................................................53
Short Circuit Resilience .................................56
Temperature Range ........................................48
VCC ..............................................................54
VPP ...............................................................51
Electromechanical Interface ................................35
Elementary Time Unit .................................See etu
Index EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page 178 June 2008
Error Detection and Correction for T=0 ...............93
Error Recovery ................................................. 104
etu ......................................................................65
Even Parity Checking Bit ....................................66
Exact Match ..................................................... 147
Examples of Directory Structures ...................... 167
Examples of Exchanges Using T=0 ................... 155
Extra Guardtime .................................................77
F
F . .............................................................. 74, 75
FCI ................................................................... 122
FCI Template ................................................... 131
FI . ...................................................................75
File Referencing ............................................... 123
File Structure.................................................... 121
Application Definition Files ......................... 121
Application Elementary Files ....................... 122
Directory Structure ....................................... 122
Mapping onto ISO/IEC 7816-4 ..................... 122
First Block Transmitted .................................... 100
Format Character T0 ...........................................74
G
GET PROCESSING OPTIONS ......................... 136
GET RESPONSE ............................... 91, 108, 112
Error Conditions .......................................... 114
Guardtime ..........................................................66
H
Historical Bytes ..................................................74
I
I . .....................................................................74
I/O Current Limit................................................49
I/O Reception ............................................... 41, 51
I/O Transmission .......................................... 42, 50
I-block ................... 95, 97, 100, 101, 104, 105, 115
Chaining .............................................. 101, 103
Coding PCB ...................................................96
IC Module Height ...............................................37
ICC Clock...........................................................43
ICC Contact
Assignment ....................................................39
Layout............................................................39
Location .........................................................38
Resistance ......................................................46
ICC Current Requirement ...................................45
ICC Electrical Characteristics .............................40
ICC I/O Reception ..............................................41
ICC I/O Transmission .........................................42
ICC Insertion and Contact Activation Sequence...60
ICC Mechanical Characteristics ..........................37
ICC Reset ..................................................... 44, 61
ICC Temperature Range .....................................40
ICC VCC ............................................................45
IFD Contact Assignment .....................................48
IFSC ........................................74, 81, 98, 100, 102
IFSD........................................................... 98, 102
IFSI .............................................................. 81, 98
II . ....................................................................76
Implicit Selection.............................................. 135
INF .....................................................................97
Information block .................................. See I-block
Initial Character ........................................... See TS
Initial etu ............................................................65
INS ....................................................... 90, 91, 116
INS ...................................................................91
Instruction Code .................................................90
Integrity ..............................................................83
Interface Characters, TA1 to TC3........................74
Invalid Block .................................................... 104
Inverse Logic Convention....................................73
Issuer Code Table Index ................................... 138
L
Language Preference ......................................... 138
Layout of Contacts ..............................................39
Le . ................................................................. 126
LEN ..................................................... 94, 97, 100
Length ...................................................... See LEN
Length of Expected Data .............................. See Le
List of AIDs Method ................................. 143, 146
Location of Contacts ...........................................38
Logic Convention
Direct ............................................................73
Inverse ...........................................................73
Longitudinal Redundancy Check ............... See LRC
Loss of Synchronisation .................................... 104
Lower Voltage ICC Migration .............................36
LRC ............................................................. 82, 97
M
Mandatory Header ............................................ 126
Matching Applications ...................................... 142
Maximum Block Size .........................................98
Maximum Current Pulse Envelope................ 54, 56
Maximum Interval ..............................................99
Mechanical Characteristics, ICC .........................37
Contact Assignment .......................................39
Contact Layout ...............................................39
EMV 4.2 Book 1 Index
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 179
Contact Location ............................................38
Module Height ...............................................37
Mechanical Characteristics, Terminal .................47
Contact Assignment .......................................48
Contact Force .................................................48
Contact Location ............................................47
Message Structure ............................................ 125
MF ................................................................... 167
Migration to Lower Voltage Cards ......................36
Minimum Interval ...............................................99
Module Height ...................................................37
Modulo-2............................................................97
Multi-application ICCs ..................................... 133
Multiple Applications ....................................... 149
Mutually Supported Applications ...................... 149
N
N . .............................................................. 74, 77
NAD............................................................. 94, 95
NAK...................................................................95
Negotiable Mode ................................................79
Node Address .......................................... See NAD
Normal Status ................................................... 108
Normative References .......................................... 5
Notations ............................................................27
O
Operating Voltage Ranges ..................................46
P
P . ....................................................................74
P1 ............................................................ 90, 116
P2 ............................................................ 90, 116
P3 ....................................................................90
Padding
Format a, an, ans .......................................... 164
Format n ...................................................... 164
Parity..................................................................72
Parity Bit ............................................................66
Parity Error........................................... 93, 97, 104
Partial Name Selection ..................................... 142
Payment System Application ............................. 136
Payment System Directory File ......................... 122
Payment System Directory Record Format ........ 139
Payment System Environment ........................... 122
PCB ............................................................. 94, 95
Physical Layer ....................................................87
Physical Transportation of Characters .................65
Physical Transportation of Characters Returned at
Answer to Reset .............................................69
PI1 .....................................................................76
PI2 .....................................................................79
PIX ................................................................... 137
Powering and Depowering ..................................57
Procedure Byte ............................. 90, 91, 107, 112
Programming Voltage ............................... See VPP
Proprietary Application Identifier Extension
............................................................. See PIX
Proprietary Data Elements ................................ 131
Protocol ........................ See Transmission Protocols
Protocol Control Byte ............................... See PCB
Protocol Error ................................................... 104
PSE .................................................................. 122
PSE Method ..................................................... 143
PTS ....................................................................87
R
R-APDU .............................................................92
Content ........................................................ 127
Format ......................................................... 127
Structure ...................................................... 127
R-block.......................... 95, 97, 100, 101, 104, 105
Coding PCB ...................................................96
READ RECORD ...................................... 126, 127
Command Message ...................................... 128
Command Reference Control Parameter ....... 128
Command-Response APDUs ........................ 127
Receive-ready block ............................. See R-block
References
Normative ....................................................... 5
Registered Application Provider Identifier . See RID
Reject an ATR ....................................................73
Reject an ICC .....................................................73
Reset ............................................................ 44, 61
Terminal Electrical Characteristics .................53
Response APDU ................................ See R-APDU
Response Data .................................................. 115
Resumption Information ................................... 144
Resynchronisation............................................. 106
Revision Log ...................................................... iii
RID .................................................................. 137
S
S(ABORT Request) Block ................................ 106
S(IFS Request) Block ....................................... 100
S(IFS Response) Block ..................................... 100
S(Response) block ............................................ 105
S(RESYNCH Request) Block ........................... 106
S(WTX Request) Block .................................... 101
S(WTX Response) Block .................................. 101
SAD ...................................................................95
S-block ................................................. 95, 97, 101
Coding PCB ...................................................96
Scope .................................................................. 3
Index EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
Page 180 June 2008
SELECT ................................................... 111, 126
Command Message ...................................... 130
Command Options Parameter ....................... 130
Command Reference Control Parameter ....... 130
Command-Response APDUs ........................ 129
Response Message Data Field (FCI) of ADF 133
Response Message Data Field (FCI) of DDF 132
Response Message Data Field (FCI) of PSE . 131
SFI ........................................................... 122, 123
Short Circuit Resilience ......................................56
Sliding Carriage .................................................64
Source Node Address ................................ See SAD
Specific Mode ....................................................79
Stages of a Card Session .....................................59
Start Bit..............................................................66
Status Byte Coding .............................................92
Structure of a Block
Block Protocol T=1 ........................................94
Structure of Command Message ........................ 114
Supervisory block ................................. See S-block
Supply Voltage .........................................See VCC
Supply Voltage (VCC) ........................................54
Synchronisation .......................................... 73, 101
Syntax Error ..................................................... 104
T
T=0 ..............................See Character Protocol T=0
T=1 ................................... See Block Protocol T=1
T0 - Format Character ........................................74
TA1 - Interface Character ...................................75
TA2 - Interface Character ...................................79
TA3 - Interface Character ...................................81
TAL ........................................................... 90, 115
TB1 - Interface Character....................................76
TB2 - Interface Character....................................79
TB3 - Interface Character....................................82
TC1 - Interface Character....................................77
TC2 - Interface Character....................................80
TC3 - Interface Character....................................82
TCK - Check Character ......................................83
TD1 - Interface Character ...................................78
TD2 - Interface Character ...................................80
Temperature Range ...................................... 40, 48
Template .......................................................... 160
Template 'BF0C' ............................................... 131
Terminal Application Layer ................................90
Terminal Behaviour during Answer to Reset .......83
Terminal Electrical Characteristics .....................48
Clock .............................................................52
Contact Resistance .........................................56
Current Requirement......................................54
I/O Current Limit ...........................................49
I/O Reception .................................................51
I/O Transmission............................................50
Powering and Depowering .............................57
Reset .............................................................53
Short Circuit Resilience .................................56
Temperature Range ........................................48
VCC ..............................................................54
VPP ...............................................................51
Terminal Logic Using Directories ..................... 145
Terminal Mechanical Characteristics ..................47
Contact Assignment .......................................48
Contact Force .................................................48
Contact Location ............................................47
Terminal Response to Procedure Byte .................91
Terminal Supply Voltage and Current .................55
Terminal Transport Layer ......................... See TTL
Terminology .......................................................31
Trailer .............................................................. 127
Transaction Abortion ........................................ 106
Transmission Control Parameters........................74
Transmission Error ........................................... 104
Transmission Protocols ................................ 70, 87,
See Character Protocol T=0,
See Block Protocol T=1
Transport Layer ..................................................87
Transport of APDUs by T=0 ............................. 107
Transportation of APDUs by T=1 ...................... 115
Tree Structure................................................... 121
TS - Initial Character .................................... 66, 73
TTL .................................................... 90, 107, 115
Transport of APDUs by T=0 ......................... 107
Transportation of APDUs by T=1 ................. 115
Types of Blocks ..................................................95
U
Using the List of AIDs in the Terminal ............. 148
V
VCC
ICC Electrical Characteristics.........................45
Terminal Electrical Characteristics .................54
Voltage Ranges...................................................46
VPP .............................................................. 76, 79
ICC Electrical Characteristics.........................42
Terminal Electrical Characteristics .................51
W
Waiting Time Integer ................................... See WI
Warm Reset ........................................................62
Warning Status ................................................. 108
WI ......................................................................80
Work Waiting Time ...................................... 80, 89
EMV 4.2 Book 1
Application Independent ICC to
Terminal Interface Requirements
June 2008 Page 181

EMV
Integrated Circuit Card Specifications for Payment Systems

Book 1
Application Independent ICC to Terminal Interface Requirements
Version 4.2 June 2008

© 1994-2008 EMVCo, LLC (―EMVCo‖). All rights reserved. Any and all uses of the EMV Specifications (―Materials‖) shall be permitted only pursuant to the terms and conditions of the license agreement between the user and EMVCo found at http://www.emvco.com

2 Book 1 Application Independent ICC to Terminal Interface Requirements Page ii June 2008 .EMV 4.

38: Recommendations Regarding the Use of Historical Bytes Minor editorial clarifications. 42: Voice Referrals Specification Update Bulletin no. 37 Fourth Edition: Editorial Errors in Release 4. 49: Data Errors during List of AIDs Selection Updated in support of the following Application Notes: Application Note no. Numbering and cross references in this version have been updated to reflect changes introduced by the published bulletins.2 The following changes have been made to Book 1 since the publication of Version 4. including those described in the following Specification Updates: Specification Update Bulletin no.2 Book 1 Application Independent ICC to Terminal Interface Requirements Revision Log . Incorporated changes described in the following General bulletins: General Bulletin no.1. 43: Correction to the Coding of TA2 Specification Update Bulletin no. 11 Second Edition: Lower Voltage Card Migration Mandatory Implementation Schedule Incorporated changes described in the following Specification Updates: Specification Update Bulletin no. 26: Warm Reset Timing Application Note no.1 of the EMV Specifications June 2008 Page iii .Version 4.EMV 4.

.

4 Abbreviations Notations Data Element Format Conventions Terminology Part II .2 4.1 1.3.1 Physical Characteristics 5.5 Reset (RST) 5.2 Input/Output (I/O) 5.3 4. and Terminology 4.2 Dimensions and Location of Contacts 5.2.2.2 Book 1 Application Independent ICC to Terminal Interface Requirements Contents Part I .3 1.4.3.General 1 Scope 1. Conventions.2 1.2 Structure Underlying Standards Audience 3 3 3 4 4 5 9 19 19 27 29 31 Normative References Definitions Abbreviations.3 Programming Voltage (VPP) 5.6 Supply Voltage (VCC) 5.3. Logical Interface.3.2 Mechanical Characteristics of the ICC 5.3.3 Contact Assignment 5.3 Electrical Characteristics of the ICC 5.3.7 Contact Resistance 5. and Transmission Protocols 5 Electromechanical Interface 5.3 Contact Assignment 5.5 Electrical Characteristics of the Terminal June 2008 35 36 37 37 38 39 40 40 40 42 43 44 45 46 47 47 48 48 48 Page v .3.1 4.EMV 4.1 Interface Device 5.4.1 Measurement Conventions 5.2 Contact Forces 5.4.1 Lower Voltage ICC Migration 5.4 Mechanical Characteristics of the Terminal 5. Notations.4 2 3 4 Changes in Version 4.2.4 Clock (CLK) 5.Electromechanical Characteristics.

Flow at the Terminal 9 Transmission Protocols 9.3 ICC Reset 6.2 Bit Duration Character Frame 8 Answer to Reset 8.1 TS .5 Answer to Reset .1.4 Terminal Behaviour during Answer to Reset 8.2 Character Protocol T=0 9.3.1 5.1.1 Physical Transportation of Characters Returned at Answer to Reset 8.2 Book 1 Application Independent ICC to Terminal Interface Requirements 5.5.1 Stages of a Card Session 6.7 5.5.4 5.2.5 Contact Deactivation Sequence 6.4 TCK .1.5.4 Execution of a Transaction 6.1 Transport of APDUs by T=0 9.5 5.2 T0 .3 Terminal Transport Layer (TTL) 9.1 Normal Card Session 6.3.1.2 Data Link Layer 9.Interface Characters 8.1 7.EMV 4.2.Format Character 8.5.3.5 Error Detection and Correction for T=1 9.Check Character 8.3.3 Character Definitions 8.3 Error Detection and Correction for T=0 9.2.2 Abnormal Termination of Transaction Process 7 Physical Transportation of Characters 7.4 Block Protocol T=1 9.9 6 Measurement Conventions Input/Output (I/O) Programming Voltage (VPP) Clock (CLK) Reset (RST) Supply Voltage (VCC) Contact Resistance Short Circuit Resilience Powering and Depowering of Terminal with ICC in Place 48 49 51 52 53 54 56 56 57 59 59 59 60 61 63 63 64 65 65 66 69 69 70 72 73 74 74 83 83 85 87 87 88 88 89 93 94 104 107 107 115 Card Session 6.1 Physical Layer 9.2.8 5.3 5.2 Transportation of APDUs by T=1 Page vi June 2008 .6 5.5.5.2 Characters Returned by ICC at Answer to Reset 8.3.5.2.5.2 ICC Insertion and Contact Activation Sequence 6.Initial Character 8.3 TA1 to TC3 .2 5.5.1 Character Frame 9.1.3.

EMV 4.2.2.1 C-APDU 9.2 Application Elementary Files 10.3.5 Processing State Returned in the Response Message 11.2 Response APDU Format 11.2.1 File Structure 10.1.4.1 Overview of Application Selection 12.2 R-APDU Part III .1 Referencing by Name 10.5 Error Handling for FCI Response Data 12.2.4 Coding of Other Directories 12.1 Definition and Scope 11.5 Processing State Returned in the Response Message 12 Application Selection 12.2.1.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9.1 Coding of Payment System Application Identifier 12.4 Data Field Returned in the Response Message 11. and Application Selection 10 Files 10.4 Application Layer 9.3.2.1 Command APDU Format 11.2 Structure of the PSE 12.3 Mapping of Files Onto ISO/IEC 7816-4 File Structure 10.1.1.3 Building the Candidate List 115 116 117 121 121 121 122 122 122 123 123 123 125 125 126 127 127 127 128 128 128 128 129 129 130 130 131 134 135 135 137 137 138 139 141 141 141 June 2008 Page vii .2.1 Definition and Scope 11.2.3.4 Directory Structure 10.2.3.4.2 Referencing by SFI 11 Commands 11.2.Files.3 Data Field Sent in the Command Message 11.4 Data Field Returned in the Response Message 11.2.3 Coding of a Payment System Directory 12.1 Application Definition Files 10.1 Message Structure 11.2 Command Message 11.2 Data in the ICC Used for Application Selection 12.2 File Referencing 10.3.2 READ RECORD Command-Response APDUs 11.1.3 SELECT Command-Response APDUs 11. Commands.2 Command Message 11.3 Data Field Sent in the Command Message 11.2.1.

3.4 Final Selection 142 143 146 149 Part IV .1.3.3.3.3 Using a List of AIDs 12.Annexes Annex A A1 A2 A3 A4 A5 A6 A7 Annex B B1 B2 Annex C C1 C2 C3 Examples of Exchanges Using T=0 Case 1 Command Case 2 Command Case 3 Command Case 4 Command Case 2 Command Using the '61' and '6C' Procedure Bytes Case 4 Command Using the '61' Procedure Byte Case 4 Command with Warning Condition Data Elements Table Data Elements by Name Data Elements by Tag Examples of Directory Structures Single Application Card Single Level Directory Multi-Level Directory 155 155 156 156 157 157 158 158 159 159 165 167 167 168 169 Part V .2.2 Structure of the PSE 173 173 174 174 174 174 174 174 175 175 175 Page viii June 2008 .3 SELECT Command-Response APDUs 11.1 File Structure 10.EMV 4.2 Using the PSE 12.1 Matching Terminal Applications to ICC Applications 12.5 Processing State Returned in the Response Message 12 Application Selection 12.Common Core Definitions Common Core Definitions Changed Sections 10 Files 10.2 Book 1 Application Independent ICC to Terminal Interface Requirements 12.2 Data in the ICC Used for Application Selection 12.4 Directory Structure 11 Commands 11.

EMV 4.2.2 Book 1 Application Independent ICC to Terminal Interface Requirements 12.3 Coding of a Payment System Directory Index 175 176 June 2008 Page ix .

EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements Page x June 2008 .

EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements Tables Table 1: Lower Voltage Card Migration Table 2: ICC Contact Assignment Table 3: Electrical Characteristics of I/O for ICC Reception Table 4: Electrical Characteristics of I/O for ICC Transmission Table 5: Electrical Characteristics of CLK to ICC Table 6: Electrical Characteristics of RST to ICC Table 7: Classes of Operation Table 8: Mandatory and Optional Operating Voltage Ranges Table 9: IFD Contact Assignment Table 10: Electrical Characteristics of I/O for Terminal Transmission Table 11: Electrical Characteristics of I/O for Terminal Reception Table 12: Electrical Characteristics of CLK from Terminal Table 13: Electrical Characteristics of RST from Terminal Table 14: Terminal Supply Voltage and Current Table 15: Basic ATR for T=0 Only Table 16: Basic ATR for T=1 Only Table 17: Terminal Behaviour Table 18: Basic Response Coding of Character T0 Table 19: Basic Response Coding of Character TB1 Table 20: Basic Response Coding of Character TC1 Table 21: Basic Response Coding of Character TD1 Table 22: Basic Response Coding of Character TD2 Table 23: Basic Response Coding of Character TA3 Table 24: Basic Response Coding of Character TB3 Table 25: Terminal Response to Procedure Byte Table 26: Status Byte Coding Table 27: Structure of a Block Table 28: Types of Blocks Table 29: Coding of the PCB of an I-block Table 30: Coding of the PCB of a R-block Table 31: Coding of the PCB of a S-block Table 32: Structure of Command Message Table 33: GET RESPONSE Error Conditions Table 34: Definition of Cases for Data in APDUs Table 35: C-APDU Structures Table 36: Command APDU Content Table 37: Response APDU Content Table 38: READ RECORD Command Message Table 39: READ RECORD Command Reference Control Parameter Table 40: SELECT Command Message Table 41: SELECT Command Reference Control Parameter Table 42: SELECT Command Options Parameter Table 43: SELECT Response Message Data Field (FCI) of the PSE Table 44: SELECT Response Message Data Field (FCI) of a DDF 36 39 41 42 43 44 45 46 48 50 51 52 53 55 70 71 73 74 76 77 78 80 81 82 91 92 94 95 96 96 96 114 114 115 116 126 127 128 128 130 130 130 131 132 June 2008 Page xi .

2 Book 1 Application Independent ICC to Terminal Interface Requirements Table 45: Table 46: Table 47: Table 48: Table 49: Table 50: Table 51: SELECT Response Message Data Field (FCI) of an ADF Payment System Directory Record Format DDF Directory Entry Format ADF Directory Entry Format Format of Application Priority Indicator Data Elements Table Data Elements Tags 133 139 139 140 140 159 165 Page xii June 2008 .EMV 4.

2 Book 1 Application Independent ICC to Terminal Interface Requirements Figures Figure 1: ICC Contact Location and Dimensions Figure 2: Layout of Contacts Figure 3: Terminal Contact Location and Dimensions Figure 4: Maximum Current Pulse Envelope Figure 5: Maximum Current Pulse Envelopes Figure 6: Contact Activation Sequence Figure 7: Cold Reset Sequence Figure 8: Warm Reset Sequence Figure 9: Contact Deactivation Sequence Figure 10: Character Frame Figure 11: ATR .EMV 4.Example Flow at the Terminal Figure 12: Character Repetition Timing Figure 13: Chaining C-APDU Figure 14: Chaining I-Blocks Figure 15: Command APDU Structure Figure 16: Response APDU Structure Figure 17: Terminal Logic Using Directories Figure 18: Using the List of AIDs in the Terminal Figure 19: Simplest Card Structure Single Application Figure 20: Single Level Directory Figure 21: Third Level Directory 38 39 47 54 56 60 61 62 63 66 85 93 103 103 126 127 145 148 167 168 169 June 2008 Page xiii .

2 Book 1 Application Independent ICC to Terminal Interface Requirements Page xiv June 2008 .EMV 4.

EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements Part I General June 2008 Page 1 .

EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements Page 2 June 2008 .

and Transmission Protocols Files.Book 1.2 Book 1 Application Independent ICC to Terminal Interface Requirements 1 Scope This document.EMV 4. notations. Commands. and Acquirer Interface Requirements 1. etc.Security and Key Management Book 3 .Cardholder. data element format convention. Attendant. The Revision Log at the beginning of the Book provides additional detail about changes to this Book. amendments. and terminology. definitions. 1. abbreviations. Logical Interface.Application Specification Book 4 . published up to the date of this release.2 Structure Book 1 consists of the following parts: Part I Part II Part III Part IV Part V General Electromechanical Characteristics. describes the minimum functionality required of integrated circuit cards (ICCs) and terminals to ensure correct operation and interoperability independent of the application to be used. Application Independent ICC to Terminal Interface Requirements. The Integrated Circuit Card Specifications for Payment Systems includes the following additional documents.2 This release incorporates all relevant Specification Update Bulletins.com:    Book 2 . but these are beyond the scope of this specification and interoperability cannot be guaranteed.1 Changes in Version 4. all available on http://www. as well as data applicable to all Books: normative references. and Application Selection Annexes Common Core Definitions Part I includes this introduction. the Integrated Circuit Card (ICC) Specifications for Payment Systems . Additional proprietary functionality and features may be provided. June 2008 Page 3 . Application Notes.emvco.

Part III defines data elements. and transmission protocols as they apply to the exchange of information between an ICC and a terminal.and block-oriented asynchronous transmission protocols. Structure and referencing of files. voltage levels. system designers in payment systems. and example directory structures. and signal parameters as they apply to both ICCs and terminals. if any of the provisions or definitions in this specification differ from those standards. 1. 1.4 Audience This specification is intended for use by manufacturers of ICCs and terminals. Part IV includes examples of exchanges using T=0. The logical structure of data and files within the card that is required for the process is specified. and financial institution staff responsible for implementing financial applications in ICCs.1 Scope 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. files. In particular it covers:    Data elements and their mapping onto data objects. An overview of the card session. and commands as they apply to the exchange of information between an ICC and a terminal. Page 4 June 2008 . The Book also includes a revision log and an index. Structure and coding of messages between the ICC and the terminal to achieve application selection. Part V defines an optional extension to be used when implementing the Common Core Definitions (CCD). Character. as is the terminal logic using the card structure. Part III also defines the application selection process from the standpoint of both the card and the terminal. a data elements table specific to application selection.3 Underlying Standards EMV 4. logical interface. Establishment of communication between the ICC and the terminal by means of the answer to reset. In particular it covers:     Mechanical characteristics. the provisions herein shall take precedence.2 Book 1 Application Independent ICC to Terminal Interface Requirements Part II defines electromechanical characteristics. However.

EMV 4.2 Book 1 Application Independent ICC to Terminal 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. FIPS 180-2 ISO 639-1 Secure Hash Standard 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

ISO 3166 ISO 4217 ISO/IEC 7811-1 ISO/IEC 7811-3

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

ISO/IEC 7813 ISO/IEC 7816-1 ISO/IEC 7816-2

ISO/IEC 7816-3

June 2008

Page 5

2 Normative References

EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements

ISO/IEC 7816-4

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 Banking – PIN management and security – Part 1: Basic principles and requirements for online PIN handling in ATM and POS systems Banking – PIN management and security – Part 3: Requirements for offline PIN handling in ATM and POS 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

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

ISO 9564-3

ISO/IEC 9796-2:2002

ISO/IEC 9797-1

Page 6

June 2008

EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements

2 Normative References

ISO/IEC 10116 ISO/IEC 10118-3 ISO/IEC 10373 ISO 13491-1

Information technology – Security techniques – Modes of operation for an n-bit block cipher Information technology – Security techniques – Hash-functions – Part 3: Dedicated hash-functions 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

ISO 13616 ISO 16609 ISO/IEC 18031 ISO/IEC 18033-3

June 2008

Page 7

2 Normative References EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements Page 8 June 2008 .

The two transformations have the property that. it is computationally infeasible to derive the private transformation. A succession of characters comprising two or three fields defined as prologue field. See also:    Authorisation Request Cryptogram Authorisation Response Cryptogram Asymmetric Cryptographic Technique 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.EMV 4. Accelerated Revocation Application Application Authentication Cryptogram Application Cryptogram A key revocation performed on a date sooner than the published key expiry date. The provision of assurance of the claimed identity of an entity or of data origin. An Application Cryptogram generated by the card when declining a transaction A cryptogram generated by the card in response to a GENERATE AC command. given the public transformation. a public transformation (defined by the public key) and a private transformation (defined by the private key). A cryptographic technique that uses two related transformations. The application protocol between the card and the terminal and its related set of data. information field.2 Book 1 Application Independent ICC to Terminal Interface Requirements 3 Definitions The following terms are used in one or more books of these specifications. and epilogue field. Authentication Block June 2008 Page 9 .

A form of offline dynamic data authentication. and so on. A list of elements or objects may be concatenated by concatenating the first pair to form a new element. that is.2 Book 1 Application Independent ICC to Terminal Interface Requirements Byte Card Certificate 8 bits. 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. using that as the first element to concatenate with the next in the list. The public key and identity of an entity together with some other information. Compromise Concatenation Contact Page 10 June 2008 . Certification Authority Ciphertext Cold Reset Combined DDA/Application Cryptogram Generation Command A message sent by the terminal to the ICC that initiates an action and solicits a response from the ICC. Trusted third party that establishes a proof that links a public key and other relevant information to its owner. A payment card as defined by a payment system. The breaching of secrecy or security. most significant byte first. Two elements are concatenated by appending the bytes from the second element to the end of the first. 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. Within each byte bits are ordered from most significant bit to least significant. A conducting element ensuring galvanic continuity between integrated circuit(s) and external interfacing equipment. Enciphered information.3 Definitions EMV 4. rendered unforgeable by signing with the private key of the certification authority which issued that certificate.

and the sender against forgery by the recipient. The property that data has not been altered or destroyed in an unauthorised manner. An asymmetric cryptographic transformation of data that allows the recipient of the data to prove the origin and integrity of the data.1. The reversible transformation of data by a cryptographic algorithm to produce ciphertext. A form of offline dynamic data authentication Characters raised in relief from the front surface of a card.5.EMV 4. June 2008 Page 11 . It contains the error detection code (EDC) byte(s). An algorithm that transforms data in order to hide or reveal its information content. A process accomplished by one or more commands and resultant actions that are used to perform all or part of a transaction. The final field of a block. Binary addition with no carry. giving the following values: 0+0=0 0+1=1 1+0=1 1+1=0 Dynamic Data Authentication Embossing Encipherment Epilogue Field Exclusive-OR Financial Transaction Function The act between a cardholder and a merchant or acquirer that results in the exchange of goods or services against payment. and protect the sender and the recipient of the data against forgery by third parties. The deactivation sequence defined in section 6. The reversal of a corresponding encipherment.2 Book 1 Application Independent ICC to Terminal Interface Requirements 3 Definitions Cryptogram Cryptographic Algorithm Data Integrity Deactivation Sequence Decipherment Digital Signature Result of a cryptographic operation.

The string of bits that is the output of a hash function.Online Integrated Circuit Module Integrated Circuit(s) Integrated Circuit(s) Card Interface Device Issuer Action Code Page 12 June 2008 . That part of a terminal into which the ICC is inserted. satisfying the following two properties:   It is computationally infeasible to find for a given output an input which maps to this output.Denial Issuer Action Code . if the hash function is required to be collision–resistant. including such mechanical and electrical devices as may be considered part of it. which reflect the issuer-selected action to be taken upon analysis of the TVR:    Issuer Action Code . A card into which one or more integrated circuits are inserted to perform processing and memory functions. Electronic component(s) designed to perform processing and/or memory functions. It is computationally infeasible to find for a given input a second input that maps to the same output. Any of the following.4 V or less with respect to ground (GND). it must also satisfy the following property:  Hash Result Inactive It is computationally infeasible to find any two distinct inputs that map to the same output. bonding wires.2 Book 1 Application Independent ICC to Terminal Interface Requirements Guardtime 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.3 Definitions EMV 4. and contacts. The supply voltage (VCC) and other signals to the ICC are in the inactive state when they are at a potential of 0. the IC carrier. The sub-assembly embedded into the ICC comprising the IC.Default Issuer Action Code . Hash Function Additionally. A function that maps strings of bits to fixed–length strings of bits.

Key Key Expiry Date Key Introduction Key Life Cycle Key Replacement Key Revocation Key Revocation Date Key Withdrawal Keypad June 2008 Page 13 . The kernel contains device drivers.2 Book 1 Application Independent ICC to Terminal Interface Requirements 3 Definitions Kernel The set of functions required to be present on every terminal implementing a specific interpreter. Key revocation can be as scheduled or accelerated. Issuer certificates signed by the key must expire on or before this date. from planning and generation. and archiving. and. command. The key management process of withdrawing a key from service and dealing with the legacy of its use. For a planned revocation the Key Revocation Date is the same as the key expiry date. interface routines. and the software for translating from the virtual machine language to the language used by the real machine. A sequence of symbols that controls the operation of a cryptographic transformation. The process of generating. and beginning use of a key pair. All phases of key management. the kernel is the implementation of the virtual machine on a specific real machine. The date after which no legitimate cards still in use should contain certificates signed by this key. Arrangement of numeric. destruction. The simultaneous revocation of a key and introduction of a key to replaced the revoked one. where required. distributing.EMV 4. function and/or alphanumeric keys laid out in a specific manner. through revocation. The process of removing a key from service as part of its revocation. The date after which a signature made with a particular key is no longer valid. In other words. security and control functions. Keys may be removed from terminals after this date has passed. and therefore the date after which this key can be deleted from terminals.

Appending extra bits to either side of a data string.3 Definitions EMV 4. providing general support for terminal programs and/or applications.2 Book 1 Application Independent ICC to Terminal Interface Requirements Library A set of high-level software functions with a published interface. The four most significant or least significant bits of a byte. Concatenation of file identifiers without delimitation. Logical Compromise Magnetic Stripe Message Message Authentication Code Nibble Padding Path Payment System Environment Physical Compromise PIN Pad Plaintext Planned Revocation Page 14 June 2008 . excluding transmission-control characters. or a hardware security module has been stolen or accessed by unauthorised persons. A symmetric cryptographic transformation of data that protects the sender and the recipient of the data against forgery by third parties. The stripe containing magnetically encoded information. Unenciphered information. increases in computing power. A string of bytes sent by the terminal to the card or vice versa. Arrangement of numeric and command keys to be used for personal identification number (PIN) entry. or when a Directory Definition File (DDF) used for payment system application purposes has been selected. The compromise of a key resulting from the fact that it has not been securely guarded. The set of logical conditions established within the ICC when a payment system application conforming to this specification has been selected. or combination of the two. A key revocation performed as scheduled by the published key expiry date. The compromise of a key through application of improved cryptanalytic techniques.

2 Book 1 Application Independent ICC to Terminal Interface Requirements 3 Definitions Potential Compromise 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. the public key defines the verification function. the private key defines the signature function. The public key information of an entity signed by the certification authority and thereby rendered unforgeable.EMV 4. The difference between the high and low voltages of a signal. That key of an entity‘s asymmetric key pair that should only be used by that entity. A message returned by the ICC to the terminal after the processing of a command message received by the ICC. spikes. The first field of a block. and length (LEN). Random perturbations introduced from external sources are beyond the scope of this specification. etc. In the case of a digital signature scheme. An execution vector defined at a particular point in an application and assigned a unique number for reference. In the case of a digital signature scheme. crosstalk. That key of an entity‘s asymmetric key pair that can be made public. 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. protocol control byte (PCB). Abnormalities occurring on a signal during normal operation such as undershoot/overshoot. ripple. electrical noise. It contains subfields for node address (NAD). Private Key Prologue Field Public Key Public Key Certificate Response Script Secret Key Signal Amplitude Signal Perturbations Socket June 2008 Page 15 . A key used with symmetric cryptographic techniques and usable only by a set of specified entities.

May indicate a logic one or logic zero depending on the logic convention used with the ICC. Offline static data authentication A cryptographic technique that uses the same secret key for both the originator‘s and recipient‘s transformation. Without knowledge of the secret key. 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. defined to give a logical grouping of data objects. Terminate Transaction Page 16 June 2008 .3 Definitions EMV 4. which reflect the acquirer-selected action to be taken upon analysis of the TVR:    Terminal Action Code .2 Book 1 Application Independent ICC to Terminal Interface Requirements State H Voltage high on a signal line. Any of the following.Default Terminal Action Code . Voltage low on a signal line. May indicate a logic one or logic zero depending on the logic convention used with the ICC. and displaying a message indicating that the ICC cannot be used to complete the transaction Stop the current application and deactivate the card.5.Denial Terminal Action Code . Character-oriented asynchronous half duplex transmission protocol.1. it is computationally infeasible to compute either the originator‘s or the recipient‘s transformation. Block-oriented asynchronous half duplex transmission protocol. Value field of a constructed data object.Online State L Static Data Authentication Symmetric Cryptographic Technique T=0 T=1 Template Terminal Terminal Action Code Terminate Card Session End the card session by deactivating the IFD contacts according to section 6.

2 Book 1 Application Independent ICC to Terminal Interface Requirements 3 Definitions Transaction An action taken by a terminal at the user‘s request. Transaction Certificate Virtual Machine Warm Reset June 2008 Page 17 . 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. etc.EMV 4. A transaction selects among one or more applications as part of its processing flow. For a POS terminal. 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. a transaction might be payment for goods.

3 Definitions EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements Page 18 June 2008 .

3) Application Protocol Data Unit Application Program Interface Authorisation Response Code Authorisation Response Cryptogram Authorisation Request Cryptogram Application Selection Indicator Abstract Syntax Notation Application Transaction Counter June 2008 Page 19 . Conventions.1 Abbreviations µA µm µs a AAC AC ACK ADF AEF AFL AID AIP an ans APDU API ARC ARPC ARQC ASI ASN ATC Microampere Micrometre Microsecond Alphabetic (see section 4.3) Alphanumeric Special (see section 4. 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.2 Book 1 Application Independent ICC to Terminal Interface Requirements 4 Abbreviations.EMV 4. Notations.3. and Terminology 4.

Notations.4 Abbreviations.2 Book 1 4. and Terminology EMV 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. Conventions.3) Central Processing Unit Certificate Revocation List Card Status Update Command TPDU Cryptogram Version Page 20 June 2008 .1 Abbreviations Application Independent ICC to Terminal Interface Requirements 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 CV Automated Teller Machine Answer to Reset Application Usage Control Binary (see section 4.

Notations. and Terminology Application Independent ICC to 4. Seconds Input/Output June 2008 Page 21 .2 Book 1 4 Abbreviations.EMV 4. Minutes.1 Abbreviations Terminal Interface Requirements 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 I/O 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. Conventions.

and Terminology EMV 4. Conventions.s. Notations.2 Book 1 4. 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 Lower Consecutive Offline Limit Page 22 June 2008 .1 Abbreviations Application Independent ICC to Terminal Interface Requirements 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. Lc LCOL Issuer Action Code (Denial.4 Abbreviations. Default.

Year Newton Numeric (see section 4.EMV 4.3) Node Address Negative Acknowledgment Nanoampere-second Lr LRC M m M m.1 Abbreviations Terminal Interface Requirements LDD Le LEN Licc 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 Megohm Most Significant Meters per Second Milliampere Message Authentication Code Maximum Master File Megahertz Minimum ICC Master Key for session key generation Millimetre Month. Conventions. m/s mA MAC max. MK mm MMDD MMYY N n NAD NAK nAs June 2008 Page 23 . and Terminology Application Independent ICC to 4. MF MHz min.2 Book 1 4 Abbreviations.s. Day Month. Notations.

4 Abbreviations, Notations, Conventions, and Terminology EMV 4.2 Book 1 4.1 Abbreviations Application Independent ICC to Terminal 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

Page 24

June 2008

EMV 4.2 Book 1 4 Abbreviations, Notations, Conventions, and Terminology Application Independent ICC to 4.1 Abbreviations Terminal 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

June 2008

Page 25

4 Abbreviations, Notations, Conventions, and Terminology EMV 4.2 Book 1 4.1 Abbreviations Application Independent ICC to Terminal 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

Page 26

June 2008

that is. Notations. Conventions. for which there exists an integer d such that A = dn + r A/n The integer division of A by n. using a secret key K Decipherment of a data block Y with a block cipher as specified in Annex A1 of Book 2.2 Notations ‗0‘ to ‗9' and 'A' to 'F' xx A := B A=B A  B mod n 16 hexadecimal characters Any value A is assigned the value of B Value of A is equal to the value of B Integers A and B are congruent modulo the integer n. there exists an integer d such that (A – B) = dn A mod n The reduction of the integer A modulo the integer n. such that A = dn + r Y := ALG(K)[X] X = ALG-1(K)[Y] Y := Sign (SK)[X] Encipherment of a data block X with a block cipher as specified in Annex A1 of Book 2. and Terminology Application Independent ICC to 4. X = Recover(PK)[Y] C := (A || B) June 2008 Page 27 . using a secret key K 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 The recovery of the data block X with an asymmetric reversible algorithm as specified in Annex A2 of Book 2.2 Book 1 4 Abbreviations. which is defined as C = 2m A + B. 0  r < n.EMV 4. that is.2 Notations Terminal Interface Requirements 4. using the public key PK The concatenation of an n-bit number A and an m-bit number B. the unique integer r. that is. 0  r < n. the unique integer d for which there exists an integer r.

If C = (A || B) as above. or digits and used interchangeably with the term ―most significant‖.4 Abbreviations. and Terminology EMV 4. or digits and used interchangeably with the term ―least significant‖. If C = (A || B) as above. Applies to a sequence of bits. If one data block is shorter than the other. then A is the leftmost n bits of C. then B is the rightmost m bits of C. then it is first padded to the left with sufficient binary zeros to make it the same length as the other. Notations. bytes.2 Notations Application Independent ICC to Terminal Interface Requirements Leftmost Applies to a sequence of bits. Conventions. 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. Rightmost H := Hash[MSG] XY Page 28 June 2008 . bytes.2 Book 1 4.

EMV 4. 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.2 Book 1 4 Abbreviations. n Numeric data elements consist of two numeric digits (having values in the range Hex '0'–'9') per byte. Authorised (Numeric) as Hex '00 00 00 01 23 45'. These digits are right justified and padded with leading hexadecimal zeroes. The permitted characters and their coding are shown in the Common Character Set table in Annex B of Book 4. Bit combination example: Processing Options Data Object List (PDOL) is defined as ―b‖ with the format shown in Book 3. Notations. An ATC value of 19 is stored as Hex '00 13'. an ans June 2008 Page 29 .3 Data Element Format Conventions Terminal Interface Requirements 4. Other specifications sometimes refer to this data format as Binary Coded Decimal (―BCD‖) or unsigned packed. Binary example: The Application Transaction Counter (ATC) is defined as ―b‖ with a length of two bytes.3 Data Element Format Conventions The EMV specifications use the following data element formats: a Alphabetic data elements contain a single character per byte.4. section 5. Alphanumeric data elements contain a single character per byte. The permitted characters are alphabetic (a to z and A to Z. Alphanumeric Special data elements contain a single character per byte. These data elements are left justified and padded with trailing hexadecimal 'F's. Example: Amount. 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. upper and lower case). upper and lower case) and numeric (0 to 9). A value of 12345 is stored in Amount. Conventions. and Terminology Application Independent ICC to 4. Authorised (Numeric) is defined as ―n 12‖ with a length of six bytes. b These data elements consist of either unsigned binary numbers or bit combinations that are defined elsewhere in the specification. cn Compressed numeric data elements consist of two numeric digits (having values in the range Hex '0'–'9') per byte. The permitted characters are alphabetic only (a to z and A to Z. Example: The Application Primary Account Number (PAN) is defined as ―cn‖ with a length of up to ten bytes.

3 Data Element Format Conventions Application Independent ICC to Terminal 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.4 Abbreviations.2 Book 1 4. Notations. and Terminology EMV 4. Page 30 June 2008 . Conventions.

Conventions. Notations.4 Terminology proprietary shall should Not defined in this specification and/or outside the scope of this specification Denotes a mandatory requirement Denotes a recommendation June 2008 Page 31 .4 Terminology Terminal Interface Requirements 4.2 Book 1 4 Abbreviations.EMV 4. and Terminology Application Independent ICC to 4.

2 Book 1 4. Conventions.4 Terminology Application Independent ICC to Terminal Interface Requirements Page 32 June 2008 .4 Abbreviations. Notations. and Terminology EMV 4.

EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements Part II Electromechanical Characteristics. Logical Interface. and Transmission Protocols June 2008 Page 33 .

EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements Page 34 June 2008 .

The ICC characteristics defined herein are based on the ISO/IEC 7816 series of standards with some small variations. ICC and terminal specifications differ to allow a safety margin to prevent damage to the ICC.EMV 4. June 2008 Page 35 .2 Book 1 Application Independent ICC to Terminal Interface Requirements 5 Electromechanical Interface This section covers the electrical and mechanical characteristics of the ICC and the terminal.

No class A cards shall be in circulation from January 2014. only class AB or class ABC cards shall be in circulation from January 2014. and class BC cards are not allowed. shall not be used before end December 2013. to the following cards:1    class A (until end December 2013) class AB class ABC class A terminals until end December 2013 new terminal values from January 2014 to class A terminals (or the class A component of multi-class terminals) to class A. Page 36 June 2008 . From January 2014. shall be used for new class A or class B terminals.emvco. Cards that support class A only are being phased out and shall be replaced by class AB or class ABC cards by end December 2013. class C. class B. it will be possible to deploy terminals that support class B only in addition to class A only terminals. Refer to General Bulletin 11 on the EMVCo website at http://www. are permitted immediately and until further notice. Class C terminals shall not be deployed until stated by EMVCo (except for proprietary purposes outside the scope of EMV).com for details of the migration schedule. there is no requirement to update terminals already in the field built using these values. When all cards in use support class AB or class ABC. Section 5 describes the requirements for cards and terminals as the transition occurs.5 Electromechanical Interface 5. all cards in circulation shall be either class AB or class ABC.1 Lower Voltage ICC Migration A phased migration to lower voltage cards is underway.1 Lower Voltage ICC Migration EMV 4. class AC. From January 2014. From January 2014. and class C terminals Table 1: Lower Voltage Card Migration 1 Class B. Differences are indicated using the notations shown in Table 1: Notation class A cards until end December 2013 new card values from January 2014 Information applies: to class A cards Values: are permitted for cards in circulation until end December 2013.2 Book 1 Application Independent ICC to Terminal Interface Requirements 5. shall be used for class A terminals until end December 2013.

The lowest point on the IC module surface shall not be greater than 0. the ICC shall comply with the physical characteristics for ICCs as defined in ISO/IEC 7816-1. mechanical strength. and mechanical strength of the ICC.EMV 4. surface profile of the contacts. X-rays.2 Mechanical Characteristics of the ICC This section describes the physical characteristics.2.1 Module Height The highest point on the IC module surface shall not be greater than 0.2. electromagnetic characteristics. 5.10mm below the plane of the card surface.10mm above the plane of the card surface.1 Physical Characteristics Except as otherwise specified herein.2 Mechanical Characteristics of the ICC 5. 5.2 Book 1 Application Independent ICC to Terminal Interface Requirements 5 Electromechanical Interface 5. contact assignment. The ICC shall also comply with the additional characteristics defined in ISO/IEC 7816-1 as related to ultraviolet light. and static electricity and shall continue to function correctly electrically under the conditions defined therein.1. June 2008 Page 37 .

2. Page 38 June 2008 . The minimum ICC contacts shall be connected to the IC contacts as shown in Table 2.2 Mechanical Characteristics of the ICC EMV 4. other than via the IC.87 min All dimensions in millimetres Figure 1: ICC Contact Location and Dimensions Areas C1. and areas Z1 to Z8 as defined in ISO/IEC 7816-2 Annex B may optionally have conductive surfaces. and C7 shall be fully covered by conductive surfaces forming the minimum ICC contacts.25 min 17. there shall be no connection between the conductive surface of any area and the conductive surface of any other area. C2.5 Electromechanical Interface 5.85 max 28.23 max 20. and Z1 to Z8. C8.31 max 26.2 Dimensions and Location of Contacts The dimensions and location of the contacts shall be as shown in Figure 1: Upper Edge 26. C6. C3. they shall be electrically isolated from the integrated circuit (IC).01 min Left Edge C1 C2 C3 C4 C5 C6 C7 C8 10.47 min 24.93 min 21.25 max 12. (Electrically isolated means that the resistance measured between the conductive surface and any other conductive surface shall be 10M with an applied voltage of 5V DC. Areas C4. from one another.2 Book 1 Application Independent ICC to Terminal Interface Requirements 5.87 max 19. C5. If conductive surfaces exist in areas C6.) In addition. but it is strongly recommended that no conductive surfaces exist in areas Z1 to Z8.77 max 23.55 min 19. and from any other contact area.

need not be physically present Table 2: ICC Contact Assignment 2 Defined in ISO/IEC 7816-3:1997 as programming voltage (VPP) for class A. Further.2.EMV 4. positioning of the signature panel behind the IC may lead to damage due to heavy pressure being applied during signature. 5.3 Contact Assignment The assignment of the ICC contacts shall be as defined in ISO/IEC 7816-2 and is shown in Table 2: C1 C2 C3 C4 Supply voltage (VCC) Reset (RST) Clock (CLK) Not used.2 Book 1 Application Independent ICC to Terminal Interface Requirements 5 Electromechanical Interface 5. need not be physically present C5 C6 C7 C8 Ground (GND) RFU 2 Input/output (I/O) Not used.2 Mechanical Characteristics of the ICC The layout of the contacts relative to embossing and/or magnetic stripe shall be as shown in Figure 2: Magnetic Stripe (Back of Card) Mandatory Contacts Optional Contacts Embossing Area Front of Card Figure 2: Layout of Contacts Note: Care should be taken that card embossing does not damage the IC. June 2008 Page 39 .

5. Note: The temperature range limits are dictated primarily by the thermal characteristics of polyvinyl chloride (which is used for the majority of cards that are embossed) rather than by constraints imposed by the characteristics of the IC.3 Electrical Characteristics of the ICC EMV 4. ICCs shall be capable of correct operation over an ambient temperature range of at minimum 0 C to 50 C. 5.2 Input/Output (I/O) This contact is used as an input (reception mode) to receive data from the terminal or as an output (transmission mode) to transmit data to the terminal. During operation. Page 40 June 2008 .3.1 Measurement Conventions All measurements are made at the point of contact between the ICC and the interface device (IFD) contacts and are defined with respect to the GND contact over an ambient temperature range 0 C to 50 C.3.2 Book 1 Application Independent ICC to Terminal Interface Requirements 5. In the event that this condition occurs. the state (voltage level) of the I/O contact is indeterminate and no damage shall occur to the ICC. the ICC and the terminal shall not both be in transmission mode.5 Electromechanical Interface 5. All currents flowing into the ICC are considered positive.3 Electrical Characteristics of the ICC This section describes the electrical characteristics of the signals as measured at the ICC contacts.

2 x VCC 1.EMV 4.6. Table 3: Electrical Characteristics of I/O for ICC Reception June 2008 Page 41 . see Table 1 The ICC shall not be damaged by signal perturbations on the I/O line in the range –0.7 x VCC 0 — Maximum VCC 0. Symbol VIH VIL tR and tF Conditions Minimum 0.3.0 Unit V V µs new card values from January 2014. and with the supply voltage (VCC) for the applicable class in the range specified in section 5.7 x VCC 0 — Maximum VCC 0.1 Reception Mode When in reception mode.3 V to VCC + 0.8 1. the ICC shall correctly interpret signals from the terminal having the characteristics shown in Table 3: Symbol VIH VIL tR and tF Conditions Minimum 0.0 Unit V V µs class A cards until end December 2013.3 Electrical Characteristics of the ICC 5. see Table 1 The ICC shall not be damaged by signal perturbations on the I/O line in the range –0.3 V.2 Book 1 Application Independent ICC to Terminal Interface Requirements 5 Electromechanical Interface 5.3 V to VCC + 0.2.3.3 V.

3).3 Programming Voltage (VPP) The ICC shall not require VPP (see note in section 5. VCC = min. CIN (terminal) = 30 pF max. 0 < IOL < 1 mA. see Table 1 Minimum 0.0 Unit V V new card values from January 2014.15 x VCC 1. Page 42 June 2008 .5 mA tR and tF CIN (terminal) = 30 pF max. There is no requirement for the ICC to have any current source capability to I/O.2 Transmission Mode When in transmission mode.2 Book 1 Application Independent ICC to Terminal Interface Requirements 5. Minimum 0. see Table 1 µs Table 4: Electrical Characteristics of I/O for ICC Transmission Unless transmitting.0 Unit V V µs class A cards until end December 2013. Conditions –20 µA < IOH < 0 Class A: 0 < IOL < 1 mA Classes B and C: 0 < IOL < 0.2.3.3. the ICC shall set its I/O line driver to reception mode.3 Electrical Characteristics of the ICC EMV 4. 5.5 Electromechanical Interface 5.7 x VCC 0 — Maximum VCC 0. VCC = min.4.4 1. the ICC shall send data to the terminal with the characteristics shown in Table 4: Symbol VOH VOL tR and tF Symbol VOH VOL Conditions –20 µA < IOH < 0.7 x VCC 0 0 — Maximum VCC 0.08 x VCC 0.

7 0 — Maximum VCC 0.3 V. Table 5: Electrical Characteristics of CLK to ICC The ICC shall operate correctly with a CLK duty cycle of between 44% and 56% of the period during stable operation.EMV 4. see Table 1 The ICC shall not be damaged by signal perturbations on the CLK line in the range –0. Symbol VIH VIL tR and tF Conditions Minimum 0.3.3 Electrical Characteristics of the ICC 5.7 x VCC 0 — Maximum VCC 0.2 x VCC 9% of clock period Unit V V new card values from January 2014.2 Book 1 Application Independent ICC to Terminal Interface Requirements 5 Electromechanical Interface 5. Note: Frequency shall be maintained by the terminal to within  1% of that used during the answer to reset throughout the card session.6. the ICC shall operate correctly with a CLK signal having the characteristics shown in Table 5: Symbol VIH VIL tR and tF VCC = min.3 V. June 2008 Page 43 .3. see Table 1 The ICC shall not be damaged by signal perturbations on the CLK line in the range –0. to max.4 Clock (CLK) With VCC in the range specified for the applicable class in section 5. The ICC shall operate correctly with a CLK frequency in the range 1 MHz to 5 MHz.5 9% of clock period Unit V V class A cards until end December 2013.3 V to VCC + 0. Conditions Minimum VCC – 0.3 V to VCC + 0.

3.0 Unit V V µs new card values from January 2014.6. Conditions Minimum VCC – 0.7 x VCC 0 Maximum VCC 0. — The ICC shall not be damaged by signal perturbations on the RST line in the range –0. the ICC shall correctly interpret a RST signal having the characteristics shown in Table 6: Symbol VIH VIL tR and tF VCC = min.0 Unit V V µs class A cards until end December 2013.3 V to VCC + 0.5 Reset (RST) With VCC in the range specified for the applicable class in section 5.3 V to VCC + 0.2 Book 1 Application Independent ICC to Terminal Interface Requirements 5. to max.6 1.3 Electrical Characteristics of the ICC EMV 4.5 Electromechanical Interface 5. to max.3 V. see Table 1 The ICC shall not be damaged by signal perturbations on the RST line in the range –0. see Table 1 VCC = min.7 0 — Maximum VCC 0. Page 44 June 2008 .3. Symbol VIH VIL tR and tF Conditions Minimum 0. Table 6: Electrical Characteristics of RST to ICC The ICC shall answer to reset asynchronously using active low reset.2 x VCC 1.3 V.

70 1. These are defined in Table 7.62 Maximum 5. see Table 1 ICC mA The maximum current consumptions shown apply when operating at any frequency within the range specified in section 5. see Table 1 class A cards until end December 2013.4.3. The ICC shall operate correctly on any supply voltage lying within the range(s) specified for the class(es) it supports.3 Electrical Characteristics of the ICC 5.EMV 4.3.6 Supply Voltage (VCC) The ICC shall operate correctly with a supply voltage VCC of 5 V  0.98 50 50 30 Unit V new card values from January 2014.50 3.50 2.3. Table 7: Classes of Operation June 2008 Page 45 . Symbol VCC Conditions Class A Class B Class C Class A Class B Class C Minimum 4.30 1. The ICC shall support class A and may optionally support one or more additional consecutive classes.4.2 Book 1 Application Independent ICC to Terminal Interface Requirements 5 Electromechanical Interface 5.5 V DC and have a maximum current requirement of 50 mA when operating at any frequency within the range specified in section 5. Three classes of operation are defined based on the nominal supply voltage applied to the ICC.

25 µm of gold over 5.70 Unit V V new card values from January 2014.3. If the ICC supports more than one class.98–2. to guarantee that the ICC will be accepted in the event that the cold ATR is rejected.2 Book 1 Application Independent ICC to Terminal Interface Requirements The ICC shall not be damaged if it is operated under classes that it does not support (the ICC is considered to be damaged if it no longer operates as specified. the ATR may be rejected in an EMV compliant terminal.70–3.30–4. and there is no requirement for ICCs conforming to this specification to support such negotiation. 5. the warm ATR should be one of the basic ATRs defined in section 8.62–1.50–5. To avoid interoperability problems. Page 46 June 2008 .50 3.30 4. Note: A nominal IFD contact may be taken as a minimum of 1. or if it contains corrupt data).50–5.30–4.00 µm of nickel.70–3. If the ICC returns a class indicator in the ATR as defined in ISO/IEC 7816-3. Issuers of ICCs bearing multisector applications should ensure that the IC used has a current requirement compatible with all terminals (from all sectors) in which the ICC might be used. Supported Classes A and B A. and C ICC Shall Operate 4. it may optionally operate correctly on any supply voltage lying between the ranges specified for the supported classes (see Table 8 below).50 2. but this is outside the scope of EMV.50 1. since the maximum current consumption allowable for the ICC may be reduced in future versions of this specification.50 2. any class indicator used should be returned in the cold ATR.7 Contact Resistance The contact resistance as measured across a pair of clean ICC and clean nominal IFD contacts shall be less than 500 m throughout the design life of an ICC (see ISO/IEC 10373 for test method). B.5 Electromechanical Interface 5.3 Electrical Characteristics of the ICC EMV 4.30 1. Note: It is strongly recommended that the current consumption of ICCs is maintained at as low a value as possible.98 ICC May Operate 3. see Table 1 Table 8: Mandatory and Optional Operating Voltage Ranges For proprietary reasons terminals may support the capability to negotiate with the ICC the voltage class to be used.

embossing. Note: As a general principle.4 Mechanical Characteristics of the Terminal This section describes the mechanical characteristics of the terminal interface device.4 Mechanical Characteristics of the Terminal 5. loss of power). a mechanism should exist to return the ICC to the cardholder in the event of a failure (for example. and hologram. in the position compliant with Figure 2 of ISO/IEC 7816-2 Embossing compliant with ISO/IEC 7811-1 and ISO/IEC 7811-3 The IFD contacts shall be located such that if an ICC having contacts with the dimensions and locations specified in Figure 3 is inserted into the IFD.2 Book 1 Application Independent ICC to Terminal Interface Requirements 5 Electromechanical Interface 5. The IFD should have no contacts present other than those needed to connect to ICC contacts C1 to C8. Where the ICC is drawn into the IFD.EMV 4. an ICC should be accessible to the cardholder at all times. 5. correct connection of all contacts shall be made. Figure 3: Terminal Contact Location and Dimensions Location guides and clamps (if used) should cause no damage to ICCs.4. particularly in the areas of the magnetic stripe. June 2008 Page 47 . signature panel.1 Interface Device The IFD into which the ICC is inserted shall be capable of accepting ICCs having the following characteristics:    Physical characteristics compliant with ISO/IEC 7816-1 Contacts on the front.

5 Electromechanical Interface 5.5 Electrical Characteristics of the Terminal

EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements

5.4.2 Contact Forces
The force exerted by any one IFD contact on the corresponding ICC contact shall be in the range 0.2 N to 0.6 N.

5.4.3 Contact Assignment
The assignment of the IFD contacts shall be as shown in Table 9: C1 C2 C3 C4 VCC RST CLK Not used; need not be physically present C5 C6 C7 C8 GND Not used for class A 3 RFU for classes B and C I/O Not used; need not be physically present

Table 9: IFD Contact Assignment

5.5 Electrical Characteristics of the Terminal
This section describes the electrical characteristics of the signals as measured at the IFD contacts.

5.5.1 Measurement Conventions
All measurements are made at the point of contact between the ICC and the IFD contacts and are defined with respect to GND contact over an ambient temperature range 5 C to 40 C unless otherwise specified by the manufacturer. The internal temperature of the terminal should be limited to avoid damage to ICCs. All currents flowing out of the terminal are considered positive.

3

Defined in ISO/IEC 7816-3:1997 as programming voltage (VPP) for class A.

Page 48

June 2008

EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements

5 Electromechanical Interface 5.5 Electrical Characteristics of the Terminal

5.5.2 Input/Output (I/O)
This contact is used as an output (transmission mode) to transmit data to the ICC or as an input (reception mode) to receive data from the ICC. During operation, the terminal and the ICC should not both be in transmission mode. In the event that this condition occurs, the state (voltage level) of the contact is indeterminate and no damage shall occur to the terminal. When both the terminal and the ICC are in reception mode, the contact shall be in the high state. The terminal shall not pull I/O high unless VCC is powered and stable within the tolerances specified in section 5.5.6. See the contact activation sequence specified in section 6.1.2. The terminal shall limit the current flowing into or out of the I/O contact to 15 mA at all times.

June 2008

Page 49

5 Electromechanical Interface 5.5 Electrical Characteristics of the Terminal

EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements

5.5.2.1

Transmission Mode

When in transmission mode, the terminal shall send data to the ICC with the characteristics shown in Table 10: Symbol VOH VOL tR and tF Signal perturbations Conditions 0 < IOH < 20 µA, VCC = min. – 0.5 mA < IOL < 0, VCC = min. CIN(ICC) = 30 pF max. Signal low Signal high Minimum 0.8 x VCC 0 — – 0.25 0.8 x VCC Maximum VCC 0.4 0.8 0.4 VCC + 0.25 Maximum VCC 0.15 x VCC 0.8 0.15 x VCC VCC + 0.25 Unit V V µs V V
class A terminals until end December 2013; see Table 1

Symbol VOH VOL tR and tF Signal perturbations

Conditions 0 < IOH < 20 µA – 0.5 mA < IOL < 0 CIN(ICC) = 30 pF max. Signal low Signal high

Minimum 0.8 x VCC 0 — – 0.25 0.8 x VCC

Unit V V µs V V
new terminal values from January 2014; see Table 1

Table 10: Electrical Characteristics of I/O for Terminal Transmission Unless transmitting, the terminal shall set its I/O line driver to reception mode.

Page 50

June 2008

Note: Keeping C6 isolated in new class A terminals facilitates its use for other purposes if so defined in future versions of this specification. Electrically isolated means that the resistance measured between C6 and any other contact shall be 10M with an applied voltage of 5V DC.2.2 Reception Mode When in reception mode.5.5 1.5. the terminal shall correctly interpret signals from the ICC having the characteristics shown in Table 11: Symbol VIH VIL tR and tF Symbol VIH VIL tR and tF Conditions Conditions Minimum 0. June 2008 Page 51 .2 Unit V V µs Unit V V µs class A terminals until end December 2013. If connected in existing class A terminals. C6 shall be maintained at a potential between GND and 1.6 x VCC 0 — Maximum VCC 0. see Table 1 Table 11: Electrical Characteristics of I/O for Terminal Reception 5.05 x VCC throughout the card session.2 Book 1 Application Independent ICC to Terminal Interface Requirements 5 Electromechanical Interface 5.3 Programming Voltage (VPP) C6 shall be electrically isolated.6 x VCC 0 — Minimum 0. see Table 1 new terminal values from January 2014.5 Electrical Characteristics of the Terminal 5.2 Maximum VCC 0.EMV 4.20 x VCC 1.

CIN(ICC) = 30 pF max. see Table 1 Signal perturbations – 0. Frequency shall be in the range 1 MHz to 5 MHz and shall not change by more than  1% throughout answer to reset and the following stages of a card session (see section 6) unless changed following the answer to reset by means of a proprietary negotiation technique.2 Book 1 Application Independent ICC to Terminal Interface Requirements 5.25 Maximum VCC 0.25 0.4 8% of clock period 0.8 x VCC 0 — Unit V V new terminal values from January 2014.5 0 — Maximum VCC 0. VCC = min.5 Electrical Characteristics of the Terminal EMV 4.15 x VCC 8% of clock period 0.5 Electromechanical Interface 5.4 Clock (CLK) The terminal shall generate a CLK signal having the characteristics shown in Table 12: Symbol VOH VOL tR and tF Conditions 0 < IOH < 50 µA. see Table 1 Signal perturbations – 0.4 VCC + 0. Signal low Signal high Minimum VCC – 0. VCC = min.15 x VCC VCC + 0.25 V V V V Unit V V class A terminals until end December 2013.5 Symbol VOH VOL tR and tF Conditions 0 < IOH < 50 µA – 50 µA < IOL < 0 CIN(ICC) = 30 pF max.8 x VCC Table 12: Electrical Characteristics of CLK from Terminal Duty cycle shall be between 45% and 55% of the period during stable operation. Signal low Signal high Minimum 0.25 VCC – 0.5. – 50 µA < IOL < 0. Page 52 June 2008 .

25 VCC – 0.5 Electrical Characteristics of the Terminal 5.25 0.8 x VCC 0 — – 0.8 x VCC Unit V V µs V V new terminal values from January 2014.2 Book 1 Application Independent ICC to Terminal Interface Requirements 5 Electromechanical Interface 5. – 50 µA < IOL < 0. Signal low Signal high Minimum VCC – 0.25 Unit V V µs V V class A terminals until end December 2013.8 0. see Table 1 Table 13: Electrical Characteristics of RST from Terminal June 2008 Page 53 . see Table 1 Symbol VOH VOL tR and tF Signal perturbations Conditions 0 < IOH < 50 µA – 50 µA < IOL < 0 CIN(ICC) = 30 pF max. Signal low Signal high Minimum 0.5 Reset (RST) The terminal shall generate a RST signal having the characteristics shown in Table 13: Symbol VOH VOL tR and tF Signal perturbations Conditions 0 < IOH < 50 µA.25 Maximum VCC 0.4 0.5.5 Maximum VCC 0. VCC = min.15 x VCC 0. CIN(ICC) = 30 pF max.15 x VCC VCC + 0.8 0. VCC = min.5 0 — – 0.4 VCC + 0.EMV 4.

During normal operation of an ICC.5 Electromechanical Interface 5. current pulses cause voltage transients on VCC as measured at the ICC contacts. communications links. The supply shall be protected from transients and surges caused by internal operation of the terminal and from external interference introduced via power leads.2 Book 1 Application Independent ICC to Terminal Interface Requirements 5.25V with respect to ground. see Table 1 Figure 4: Maximum Current Pulse Envelope Page 54 June 2008 . an amplitude 100 mA. and a rate of change of current 1 mA/ns. VCC shall never be less than –0.5 Electrical Characteristics of the Terminal EMV 4.4 V DC and shall be capable of delivering steady state output current in the range 0 to 55 mA whilst maintaining VCC within these tolerances.6 Supply Voltage (VCC) The terminal shall generate a VCC of 5 V  0. See Figure 4 for the maximum envelope of the pulse. a duration 400 ns. ensuring that VCC remains within the range specified. 120 Icc(mA) 100 80 60 40 20 -100 -20 t(ns) 100 200 300 400 500 class A terminals until end Decembe r 2013. etc. The power supply shall be able to counteract transients in the current consumption of the ICC having a charge 30 nAs.5.

66 55 55 35 Maximum 5. but this is outside the scope of EMV. If the terminal supports more than one class.5 Electrical Characteristics of the Terminal The terminal shall generate a VCC within one of the range(s) specified in Table 14 below for the class(es) supported. and shall be capable of delivering the corresponding steady state output current whilst maintaining VCC within that range. communications links. it shall always generate a VCC from the class containing the highest voltage range available.40 3.24 1. Symbol VCC Conditions Class A Class B Class C Class A Class B Class C Minimum 4. For proprietary reasons terminals may support the capability to negotiate with the ICC the voltage class to be used.2 Book 1 Application Independent ICC to Terminal Interface Requirements 5 Electromechanical Interface 5.EMV 4. The supply shall be protected from transients and surges caused by internal operation of the terminal and from external interference introduced via power leads. VCC shall never be less than –0. etc.60 2. Attempting class negotiation with such an ICC may result in the ICC being rejected. and is not supported by ICCs conforming to this specification.76 1.25V with respect to ground. see Table 1 ICC mA Table 14: Terminal Supply Voltage and Current June 2008 Page 55 .94 Unit V new terminal values from January 2014.

5 nAs max Class C.5 Electrical Characteristics of the Terminal EMV 4. if a metal plate is inserted. 30 nAs max Class B. 11. for example.5.1 nAs max new terminal values from January 2014. but it is recommended that terminals limit the steady state current that can be delivered to a maximum of 200 mA.00 µm of nickel. current pulses cause voltage transients on VCC as measured at the ICC contacts. 5. ensuring that VCC remains within the range specified.5 Electromechanical Interface 5.25 µm of gold over 5.5. Page 56 June 2008 .8 Short Circuit Resilience The terminal shall not be damaged in the event of fault conditions such as a short circuit between any combinations of contacts. 5. 120 Icc(mA) 100 80 60 40 20 -100 -20 t(ns) 100 200 300 400 500 Class A. 17. Note: A nominal ICC contact may be taken as 1.7 Contact Resistance The contact resistance as measured across a pair of clean IFD and clean nominal ICC contacts shall be less than 500 m throughout the design life of a terminal (see ISO/IEC 7816-1 for test method). The power supply shall be able to counteract transients in the current consumption of the ICC having characteristics within the maximum charge envelope applicable to the class of operation as shown in Figure 5.2 Book 1 Application Independent ICC to Terminal Interface Requirements During normal operation of an ICC. see Table 1 Figure 5: Maximum Current Pulse Envelopes Note: Terminals may be designed to be capable of delivering more than required current. The terminal shall be capable of sustaining a short circuit of any duration between any or all contacts without suffering damage or malfunction.

and contact activation and deactivation sequences and timings.5.1. as described in sections 6.1.5 respectively.5 Electrical Characteristics of the Terminal 5. shall be respected. June 2008 Page 57 .5.2 Book 1 Application Independent ICC to Terminal Interface Requirements 5 Electromechanical Interface 5.9 Powering and Depowering of Terminal with ICC in Place If the terminal is powered on or off with an ICC in place.2 and 6.EMV 4. all signal voltages shall remain within the limits specified in section 5.

2 Book 1 Application Independent ICC to Terminal Interface Requirements Page 58 June 2008 .5 Electromechanical Interface 5.5 Electrical Characteristics of the Terminal EMV 4.

1 Normal Card Session This section describes the processes involved in the execution of a normal transaction. Deactivation of the contacts and removal of the ICC. 4.1 Stages of a Card Session A card session is comprised of the following stages: 1.EMV 4. 2.1. June 2008 Page 59 . Insertion of the ICC into the IFD and connection and activation of the contacts. 6. 6. Execution of the transaction(s).2 Book 1 Application Independent ICC to Terminal Interface Requirements 6 Card Session This section describes all stages involved in a card session from insertion of the ICC into the IFD through the execution of the transaction to the removal of the ICC from the IFD. 3. Reset of the ICC and establishment of communication between the terminal and the ICC.

Following establishment of galvanic contact but prior to activation of I/O or CLK. When the ICC is correctly seated within the IFD.4.6. the contacts shall be activated as follows (see Figure 6):    RST shall be maintained by the terminal in state L throughout the activation sequence. or otherwise.2 ICC Insertion and Contact Activation Sequence On insertion of the ICC into the IFD.5 and that VCC is 0. VCC RST CLK I/O C ardinserted here Indeterm inate 200cycles Figure 6: Contact Activation Sequence Page 60 June 2008 .5. the terminal shall set its I/O line driver to reception mode and shall provide CLK with a suitable and stable clock as defined in section 5.1. Following verification by the terminal that VCC is stable and within the limits defined in section 5. the terminal shall ensure that all signal contacts are in state L with values of VOL as defined in section 5.6 Card Session 6.4 V or less at the instant galvanic contact is made.5.1.2 Book 1 Application Independent ICC to Terminal Interface Requirements 6. The state of the I/O line after the terminal has set its I/O line driver to reception mode is dependent upon the state of the I/O line driver in the ICC (see section 6. by waiting sufficient time for it to stabilise according to the design of the terminal.3. The I/O line driver in the terminal may be set to reception mode prior to application of the clock but shall be set to reception mode no later than 200 clock cycles after application of the clock.1).1 Normal Card Session EMV 4. VCC shall be powered. Note: The terminal may verify the state of VCC by measurement.

the terminal shall initiate the deactivation sequence no earlier than 42.1. the ICC shall set its I/O line driver to reception mode. Since the terminal shall also have set its I/O line driver to reception mode within this period. The terminal shall have a reception window which is opened no later than 380 clock cycles after time T1 and closed no earlier than 42.3.001 clock cycles after time T1.    VCC RST CLK I/O T0 Indeterm inate 200cycles t1 T1 A er toR nsw eset Figure 7: Cold Reset Sequence June 2008 Page 61 .2. when it shall set RST to state H.3. the terminal shall initiate a cold reset and obtain an ATR from the ICC as follows (see Figure 7):   The terminal shall apply CLK at a notional time T0.1 Cold Reset Following activation of the contacts according to section 6.000 clock cycles after time T1 (time t1 in Figure 7). The terminal shall maintain RST in state L through time T0 and for a period of between 40. The means of transportation of the answer to reset (ATR) are described in section 7 and its contents are described in sections 8.000 clock cycles after time T1 (time t1 in Figure 7).1.000 clock cycles plus 50ms after time T1.2 Book 1 Application Independent ICC to Terminal Interface Requirements 6 Card Session 6. the I/O line is guaranteed to be in state H no later than 200 clock cycles following time T0. 6. If no answer to reset is received from the ICC.000 and 45. and no later than 42.3 ICC Reset The ICC shall answer to reset asynchronously using active low reset.EMV 4.2 and 8. Within a maximum of 200 clock cycles following T0.1. The answer to reset on I/O from the ICC shall begin between 400 and 40.000 clock cycles following time T0 to time T1.1 Normal Card Session 6.

the terminal shall initiate a warm reset and obtain an ATR from the ICC as follows (see Figure 8):    A warm reset shall start at a notional time T0'.    VCC RST CLK I/O Indeterm inate 200cycles t1' T1' A er toR nsw eset T0' Figure 8: Warm Reset Sequence Note: Figure 8 indicates that the terminal may initiate the warm reset sequence during the time that the card is still transmitting the cold ATR.4 and 5.2 Warm Reset If the ATR received following a cold reset as described in section 6.000 clock cycles following time T0' to time T1'. the card shall be able to respond correctly with the warm ATR.000 clock cycles plus 50ms after time T1'.5.001 clock cycles after time T1'. The terminal shall have a reception window which is opened no later than 380 clock cycles after time T1' and closed no earlier than 42.000 clock cycles after time T1' (time t1' in Figure 8).000 clock cycles after time T1' (time t1' in Figure 8). the ICC and terminal shall set their I/O line drivers to reception mode. The I/O line therefore is guaranteed to be in state H no later than 200 clock cycles following time T0'.000 and 45. The terminal shall maintain RST in state L from time T0' for a period of between 40.1. and in the event that it does.3. If no answer to reset is received from the ICC.6 throughout the warm reset sequence. and no later than 42. at which time the terminal shall set RST to state L.2 Book 1 Application Independent ICC to Terminal Interface Requirements 6.1 Normal Card Session EMV 4. Within a maximum of 200 clock cycles following T0'. when it shall set RST to state H.1 does not conform to the specification in section 8.6 Card Session 6. The terminal shall maintain VCC and CLK stable and within the limits defined in sections 5.5.1. The answer to reset on I/O from the ICC shall begin between 400 and 40. the terminal shall initiate the deactivation sequence no earlier than 42.3. Page 62 June 2008 .

1. This period is measured from the time that RST is set to state L to the time that VCC reaches 0.4 V or less prior to galvanic disconnection of the IFD contacts.5 Contact Deactivation Sequence As the final step in the card session. the terminal shall set CLK and I/O to state L. CLK. upon normal or abnormal termination of the transaction (including withdrawal of the ICC from the IFD during a card session). the terminal shall depower VCC. VCC shall be 0. and I/O to state L but prior to galvanic disconnection of the IFD contacts. The deactivation sequence shall be completed within 100 ms.  VCC RST CLK I/O Indeterm inate C ardrem oved here Figure 9: Contact Deactivation Sequence June 2008 Page 63 . Following the setting of RST to state L but prior to depowering VCC.4 V or less. 6.4 Execution of a Transaction Selection of the application in the ICC and the subsequent exchange of information between the ICC and the terminal necessary to perform a transaction are described in section 12 and in Book 3.1 Normal Card Session 6.EMV 4.1. the terminal shall deactivate the IFD contacts as follows (see Figure 9):    The terminal shall initiate the deactivation sequence by setting RST to state L.2 Book 1 Application Independent ICC to Terminal Interface Requirements 6 Card Session 6. Following the setting of RST.

2 Abnormal Termination of Transaction Process EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements 6. Note: For ‗sliding carriage‘ type IFDs. and of deactivating all IFD contacts in the manner described in section 6.1.2 Abnormal Termination of Transaction Process If an ICC is prematurely removed from a terminal during execution of a transaction at speeds of up to 1 m/s. In this event.6 Card Session 6. but deactivation of the contacts shall be complete before any electrical contact is broken between the ICC and IFD. No electrical or mechanical damage shall be caused to the ICC under these conditions. the terminal shall be capable of sensing the movement of the ICC relative to the IFD contacts. it is not mandatory to be able to sense the movement of the ICC relative to the IFD contacts. it may be possible for the terminal to sense the movement of the ICC/IFD contact sub-assembly relative to the main body of the IFD.5 before the relative movement exceeds 1 mm. Page 64 June 2008 .

June 2008 Page 65 . as described in section 8). The mechanism of exchanging bits and characters is described below. where f is in Hertz f Following the answer to reset (and establishment of the global parameters F and D. In the following sections.1 Bit Duration The bit duration used on the I/O line is defined as an elementary time unit (etu). the bit duration is known as the current etu. and is given by the following equation: current etu  F seconds.EMV 4. A linear relationship exists between the etu on the I/O line and CLK frequency (f).2 Book 1 Application Independent ICC to Terminal Interface Requirements 7 Physical Transportation of Characters During the transaction process. During the answer to reset. where f is in Hertz Df Note: For the basic answer(s) to reset described in this specification. and this shall be used to control the timing of this exchange. only values of F = 372 and D = 1 are supported. data is passed bi-directionally between the terminal and the ICC over the I/O line in an asynchronous half duplex manner. 7. and is given by the following equation: initial etu  372 seconds. ―etu‖ indicates current etu unless otherwise specified. A clock signal is provided to the ICC by the terminal. It applies during the answer to reset and is also used by both transmission protocols as described in section 9. the bit duration is known as the initial etu.

7 Physical Transportation of Characters 7.2 Character Frame

EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements

7.2 Character Frame
Data is passed over the I/O line in a character frame as described below. The convention used is specified in the initial character (TS) transmitted by the ICC in the ATR (see section 8.3.1). Prior to transmission of a character, the I/O line shall be in state H. A character consists of 10 consecutive bits (see Figure 10):    1 start bit in state L 8 bits, which comprise the data byte 1 even parity checking bit

The start bit is detected by the receiving end by periodically sampling the I/O line. The sampling time should be less than or equal to 0.2 etu. The number of logic ones in a character shall be even. The 8 bits of data and the parity bit itself are included in this check but the start bit is not. The time origin is fixed as midway between the last observation of state H and the first observation of state L. The existence of a start bit should be verified within 0.7 etu. Subsequent bits should be received at intervals of (n + 0.5 ± 0.2) etu (n being the rank of the bit). The start bit is bit 1. Within a character, the time from the leading edge of the start bit to the trailing edge of the nth bit is (n ± 0.2) etu. The interval between the leading edges of the start bits of two consecutive characters is comprised of the character duration (10 ± 0.2) etu, plus a guardtime. Under error free transmission, during the guardtime both the ICC and the terminal shall be in reception mode (I/O line in state H). For T=0 only, if the ICC or terminal as receiver detects a parity error in a character just received, it shall set I/O to state L to indicate the error to the sender (see section 9.2.3).
Start 8 data bits Parity Start

H I/O L
10  0.2 etu Character Duration Guardtime

Figure 10: Character Frame At the terminal transport layer (TTL), data shall always be passed over the I/O line most significant (m.s.) byte first. The order of bits within a byte (that is, whether the least significant (l.s.) or m.s. bit is transferred first) is specified in character TS returned in the answer to reset (see section 8.3).

Page 66

June 2008

EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements

7 Physical Transportation of Characters 7.2 Character Frame

June 2008

Page 67

EMV 4.3. 4 June 2008 Page 69 .2.4 This time is measured between the leading edge of the start bit of the first character (TS) and 12 initial etus after the leading edge of the start bit of the last character. 8.1. bit of a character refers to bit b8 and the l. bit refers to bit b1. the ICC answers with a string of bytes known as the ATR. is described below. The bit duration is defined in section 7. 'A' or '3F'.s. These bytes convey information to the terminal that defines certain characteristics of the communication to be established between the ICC and the terminal. and the maximum interval between the leading edges of the start bits of two consecutive characters shall be 9600 initial etus. The ICC shall transmit all the characters to be returned during an answer to reset (warm or cold) within 19. Note: In sections 8 and 9.200 initial etus.2 Book 1 Application Independent ICC to Terminal Interface Requirements 8 Answer to Reset After being reset by the terminal as described in section 6. and their meaning. and the character frame is defined in section 7. During the answer to reset. since the period represented by an etu is frequency dependent (see section 7. The method of transporting these bytes. The maximum time allowed for the answer to reset varies according to clock frequency.1 Physical Transportation of Characters Returned at Answer to Reset This section describes the structure and timing of the characters returned at the answer to reset.s.1). the m.1. A value in straight single quotes is coded in hexadecimal notation. for example. the minimum interval between the leading edges of the start bits of two consecutive characters shall be 12 initial etus.

but one of the supported protocols shall be T=0 or T=1. ICCs returning one of the two answers to reset described here are assured correct operation and interoperability in terminals conforming to this specification. It defines the characters to be returned and the allowable ranges of values for the transmission control parameters.3) Table 15: Basic ATR for T=0 Only Page 70 June 2008 . which need not have the corresponding additional proprietary functionality required to support the ICC.3. Also for proprietary reasons ICCs may optionally support other values of the transmission control parameters at the issuer‘s discretion. If protocol type T=0 only is supported (character-oriented asynchronous transmission protocol). This can only be achieved by proprietary means beyond the scope of this specification. The characters returned by the ICC at the answer to reset for the two basic answers to reset are shown in Table 15 and Table 16.2 Characters Returned by ICC at Answer to Reset EMV 4. that is. Support for such a mechanism is not required by. x indicates the number of historical bytes present VPP not required Indicates the amount of extra guardtime required. This section describes two basic answers to reset. such support is considered outside the scope of this specification and such ICCs may be rejected at terminals conforming to this specification.2 Book 1 Application Independent ICC to Terminal Interface Requirements 8. TS first. However. and is beyond the scope of these specifications.2 Characters Returned by ICC at Answer to Reset The number and coding of the characters returned by the ICC at the answer to reset varies depending upon the transmission protocol(s) and the values of the transmission control parameters supported. the characters returned shall be as shown in Table 15: Character TS T0 TB1 TC1 Value '3B' or '3F' '6x' '00' '00' to 'FF' Remarks Indicates direct or inverse convention TB1 and TC1 present. The characters are shown in the order in which they are sent by the ICC. one for ICCs supporting T=0 only and the other for ICCs supporting T=1 only.8 Answer to Reset 8. Value 'FF' has a special meaning (see section 8. For proprietary reasons ICCs may optionally support more than one transmission protocol. The first offered protocol shall be T=0 or T=1. and the terminal shall continue the card session using the first offered protocol unless for proprietary reasons it supports a mechanism for selecting an alternative protocol offered by the ICC.3. Note: This specification does not support ICCs having both T=0 and T=1 protocols present at the same time.

s. T=1 to be used TA3 and TB3 present. nibble '0' to '4' l. Value 'FF' has special meaning (see section 8.EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements 8 Answer to Reset 8.3.3. x indicates the number of historical bytes present VPP not required Indicates amount of extra guardtime required. and TC2 absent. which indicates initial value for information field size for the ICC and IFSC of 16–254 bytes BWI = 0 to 4 CWI = 0 to 5 Check character TD1 TD2 TA3 '81' '31' '10' to 'FE' TB3 TCK m. T=1 to be used Returns IFSI.4 Table 16: Basic ATR for T=1 Only June 2008 Page 71 . the characters returned shall be as shown in Table 16: Character TS T0 TB1 TC1 Value '3B' or '3F' 'Ex' '00' '00' to 'FF' Remarks Indicates direct or inverse convention TB1 to TD1 present. nibble '0' to '5' See section 8.s. TB2.2 Characters Returned by ICC at Answer to Reset If protocol type T=1 only is supported (block-oriented asynchronous transmission protocol). TC3 and TD3 absent. TD2 present.3) TA2.3.

it shall reject the ICC. For example. However. Terminals may thus reject an ATR containing interface bytes not described in. a terminal should accept a non-basic ATR if it is able to function correctly with it.) required terminal behaviour in the event that a terminal receives characters outside the range allowed by EMV The ‗basic response‘ indicates the presence or absence of the character. Terminals conforming to this specification are only required (as a minimum) to support the basic ATRs described here together with any additional requirements specified in ‗terminal behaviour‘. nor the omission/inclusion of a character at the issuer‘s discretion. only ICCs returning a basic ATR. national) use. or an ATR supported by the minimum required terminal functionality described below. Such terminal functionality is not mandatory and is beyond the scope of this specification. The description of a basic response (even though indicated by ‗shall‘) is not intended to preclude the use of other values of the characters. the ICC may return additional characters if it supports more than one transmission protocol (see section 9). and the allowable range of values it may take (if present) if it is to conform to one of the basic ATRs.8 Answer to Reset 8. If the terminal detects a parity error. Terminals shall be capable of checking the parity of characters returned in the answer to reset. Each character description includes the following information:     title explanation of usage as described in ISO/IEC 7816-3 basic response (This response should always be used in a warm ATR to ensure interoperability. However. As a general principle. Page 72 June 2008 .2 Book 1 Application Independent ICC to Terminal Interface Requirements 8. are guaranteed to be supported correctly in interchange. or having values not specified in.3 Character Definitions EMV 4. but not necessarily as they are received. this specification. terminals may correctly interpret such an ATR if it is returned by an ICC for proprietary (for example.3 Character Definitions This section provides detailed descriptions of the characters that may be returned at the answer to reset.

3.1 TS . Using inverse logic convention. Note: It is strongly recommended that a value of '3B' is returned by the ICC since a value of '3F' may not be supported in future versions of this specification.s. but only if the requirements specified in this section for all other characters are also met. Using direct logic convention.3 Character Definitions Table 17 describes the action indicated by several terms in the following character descriptions: If it is indicated that a terminal shall: reject an ATR   then: If the terminal is rejecting a cold ATR.s. It provides a known bit pattern to the terminal to facilitate bit synchronisation. An ICC returning an ATR containing TS having any other value shall be rejected. Terminal behaviour: The terminal shall be capable of supporting both inverse and direct convention and shall accept an ATR containing TS having a value of either '3B' or '3F'.2 Book 1 Application Independent ICC to Terminal Interface Requirements 8 Answer to Reset 8. and the l. The first four bits LHHL are used for bit synchronisation. If the terminal is rejecting a warm ATR. Table 17: Terminal Behaviour 8. a high state H on the I/O line is equivalent to a logic one.Initial Character TS performs two functions. bit of the data byte is the first bit sent after the start bit. and it indicates the logic convention to be used for the interpretation of the subsequent characters. the terminal shall terminate the card session by deactivating the ICC contacts. Basic responses: The ICC shall return an ATR containing TS having one of two values:  (H)LHHLLLLLLH  (H)LHHLHHHLLH inverse convention direct convention value '3F' value '3B' The convention used may differ between cold and warm resets. a low state L on the I/O line is equivalent to a logic one.EMV 4. The terminal shall accept the ATR. reject an ICC accept an ATR The terminal shall terminate the card session by deactivating the ICC contacts. the terminal shall issue a warm reset. June 2008 Page 73 . and the m. bit of the data byte is the first bit sent after the start bit.

nibble (b1–b4) indicates the number of optional historical bytes present (0 to 15). The information contained in TA1. if an EMV-compliant terminal does support historical bytes. However. if used. it is strongly recommended that they are encoded to have a structure and meaning according to ISO/IEC 7816-4. and their usage. indicating that characters TB1 to TD1 are present. TC1. indicating that characters TB1 and TC1 are present. the EMV Specifications do not explicitly support the use of historical bytes.Interface Characters TA1 to TC3 convey information that shall be used during exchanges between the terminal and the ICC subsequent to the answer to reset.5 Terminal behaviour: The terminal shall accept an ATR containing T0 of any value provided that the value returned correctly indicates and is consistent with the interface characters TA1 to TD1 and historical bytes actually returned. D. and TB2 shall apply to all subsequent exchanges irrespective of the protocol type to be used. Bits b5–b8 are set to the logic one state to indicate the presence of TA1 to TD1. the ATR shall contain T0 = 'Ex'. they should recognise that unintentional conflict of coding between cards may exist. Since Issuers are free to encode the historical bytes in any way they choose. Although their use is not forbidden. it should never be designed in such a way that nonrecognition or misinterpretation of any historical bytes present in the ATR causes termination of the transaction.8 Answer to Reset 8. b8 T=0 only T=1 only 0 1 b7 1 1 b6 1 1 b5 0 0 b4 x x b3 x x b2 x x b1 x x Table 18: Basic Response Coding of Character T0 8. nibble (b5–b8) is used to indicate whether the subsequent characters TA1 to TD1 are present. The value of 'x' represents the number of optional historical bytes to be returned. structure and meaning are outside the scope of EMV.) Basic responses: If T=0 only is to be used. TA2. (See Table 18 for the basic response coding of character T0.3 TA1 to TC3 . and character waiting time integer (CWI) applicable to T=1 as defined in ISO/IEC 7816-3. the ATR shall contain T0 = '6x'. respectively.s. and N. However.s. The m.3 Character Definitions EMV 4. TB1.2 T0 .2 Book 1 Application Independent ICC to Terminal Interface Requirements 8. block waiting time integer (BWI).3. Great care should be exercised by the terminal that it is able to unambiguously identify a card before interpreting any historical bytes returned in the ATR. P.Format Character T0 is comprised of two parts. They indicate the values of the transmission control parameters F. I. The l. and the IFSC. leading to misinterpretation at terminals. EMV-compliant terminals should ignore any historical bytes present in the ATR. If T=1 only is to be used. 5 Page 74 June 2008 .3.

or 4).1. June 2008 Page 75 .1 compliant terminals. and that a warm ATR is always present which either does not contain TA1.1. which may be used to modify the frequency of the clock provided by the terminal subsequent to the answer to reset the l. Terminal behaviour: If TA1 is present in the ATR (indicated by b5 of T0 set to 1) and TA2 is returned with b5 = 0 (specific mode. If TA1 is absent from the ATR. Basic response: The ATR shall not contain TA1 and thus the default values of F = 372 and D = 1 shall continue be used during all subsequent exchanges.EMV 4. Default values of FI = 1 and DI = 1 indicating values of F = 372 and D = 1. 6 and immediately implement the values of F and D indicated (F=372 and D = 1. nibble FI is used to determine the value of F. the bit rate adjustment factor. 6 Terminals compliant to version 3.3. nibble DI is used to determine the value of D.2 Book 1 Application Independent ICC to Terminal Interface Requirements 8 Answer to Reset 8.s. respectively. and thus may be rejected in 3. ATRs indicating the higher allowable values of D will include TA1 coded '12' or '13'.1  TA1 TA1 conveys the values of FI and DI where: the m.1 of the EMV Specifications may reject an ATR (not an ICC) if TA1 is present and coded other than '11'. the terminal shall accept the ATR and shall continue using the default values of D = 1 and F = 372 during all subsequent exchanges.1 compliant terminals (albeit operating at basic data transfer rates).1 for calculation of the bit duration subsequent to the answer to reset (current etu).1. the default values of D = 1 and F = 372 shall be used during all subsequent exchanges. parameters defined by the interface bytes).3 Character Definitions 8. to ensure that an ICC supporting higher data transfer rates is always accepted in 3.  If TA1 is present in the ATR (indicated by b5 of T0 set to 1) and TA2 is not returned (negotiable mode). unless it supports a proprietary technique for negotiating the parameters to be used. which may be used to adjust the bit duration used subsequent to the answer to reset  See section 7. it is essential that any TA1 indicating higher data rates is present in the cold ATR only.s. 2. shall be used during the answer to reset. or includes a TA1 having the value '11'.3. unless it is able to support and immediately implement the conditions indicated. the terminal shall:  Accept the ATR if the value of TA1 is in the range '11' to '13'. Therefore. the clock rate conversion factor. Reject the ATR if the value of TA1 is not in the range '11' to '13'.

Ipp.3. Note: Existing terminals may maintain VPP in the idle state (see section 5.   Basic response: The ATR shall contain TB1 = '00'. II is specified in bits b6 and b7 and is used to determine the maximum programming current.2 Book 1 Application Independent ICC to Terminal Interface Requirements 8. PI1 = 0 indicates that VPP is not connected in the ICC.3). In response to a warm reset the terminal shall accept an ATR containing TB1 of any value (provided that b6 of T0 is set to 1) or not containing TB1 (provided that b6 of T0 is set to 0) and shall continue the card session as though TB1 = '00' had been returned.3 Character Definitions EMV 4. required by the ICC. indicating that VPP is not connected in the ICC. Bit 8 is not used and shall be set to logic zero. VPP shall never be generated.8 Answer to Reset 8. The basic response coding of character TB1 is shown in Table 19: b8 0 b7 0 b6 0 b5 0 b4 0 b3 0 b2 0 b1 0 Table 19: Basic Response Coding of Character TB1 Page 76 June 2008 . This parameter is not used if PI1 = 0. the terminal shall accept only an ATR containing TB1 = '00'.2  TB1 TB1 conveys the values of PI1 and II where: PI1 is specified in bits b1 to b5 and is used to determine the value of the programming voltage P required by the ICC.3.4. Terminal behaviour: In response to a cold reset.

or 11 etus if T=1 is to be used. The basic response coding of character TC1 is shown in Table 20: b8 x b7 x b6 x b5 x b4 x b3 x b2 x b1 x Table 20: Basic Response Coding of Character TC1 Note: It is strongly recommended that the value of TC1 be set to the minimum acceptable for the ICC.3.3 TC1 TC1 conveys the value of N. Basic response: The ATR shall contain TC1 having a value in the range '00' to 'FF'. If the value of TC1 = 'FF'.2 Book 1 Application Independent ICC to Terminal Interface Requirements 8 Answer to Reset 8.1 and 9. June 2008 Page 77 . where N is used to indicate the extra guardtime that shall be added to the minimum duration between the leading edges of the start bits of two consecutive characters for subsequent exchanges from the terminal to the ICC.2. Note: TC1 applies only to the timing between two consecutive characters sent from the terminal to the ICC. and shall continue the card session as though TC1 = '00' had been returned.3 Character Definitions 8.EMV 4. Terminal behaviour: The terminal shall accept an ATR not containing TC1 (provided that b7 of T0 is set to 0).2.3. N may take any value between 0 and 255. or 11 etus if T=1 is to be used.2). which for subsequent transmissions shall be between 12 and 266 etus.2. and thus lengthy transaction times.4. N is binary coded over bits b1–b8 of TC1. If the value of TC1 is in the range '00' to 'FE'. then the minimum character to character duration for subsequent transmissions shall be 12 etus if T=0 is to be used.2. It does not apply to the timing between consecutive characters sent from the ICC to the terminal. TC1='FF' has a special meaning and indicates that the minimum delay between the leading edges of the start bits of two consecutive characters shall be reduced to 12 etus if T=0 is to be used. Large values of TC1 lead to very slow communication between the terminal and the ICC. between 0 and 254 etus of extra guardtime shall be added to the minimum character to character duration. and its value represents the number of etus to be added as extra guardtime. nor does it apply to the timing between two characters sent in opposite directions (see sections 9.

3 Character Definitions EMV 4.3. nibble having any value (provided that the value returned correctly indicates and is consistent with the interface characters TA2 to TD2 actually returned). and the l. The l.s. The ATR shall contain TD1 = '81' if T=1 only is to be used. The basic response coding of character TD1 is shown in Table 21: b8 T=1 1 b7 0 b6 0 b5 0 b4 0 b3 0 b2 0 b1 1 Table 21: Basic Response Coding of Character TD1 Page 78 June 2008 .  Basic responses: The ATR shall not contain TD1 if T=0 only is to be used. nibble provides information concerning the protocol type(s) to be used for subsequent exchanges. The terminal shall reject an ATR containing other values of TD1.s.2 Book 1 Application Independent ICC to Terminal Interface Requirements 8. and protocol type T=0 shall be used as a default for all subsequent transmissions.8 Answer to Reset 8.3. Terminal behaviour: The terminal shall accept an ATR containing TD1 with the m. indicating that TD2 is present and that protocol type T=1 shall be used for all subsequent transmissions.4 TD1 TD1 indicates whether any further interface bytes are to be transmitted and information concerning the protocol type(s) where:  The m.s. nibble having a value of '0' or '1'.s. These bits (b5–b8) are set to the logic one state to indicate the presence of TA2 to TD2 respectively. nibble is used to indicate whether the characters TA2 to TD2 are present.

nibble is also the first indicated protocol in the ATR.EMV 4. Otherwise. Basic response: The ATR shall not contain TB2.s. The transmission parameters are defined by the interface characters if b5 is set to 0. TA2 conveys information regarding the specific mode of operation where:    b8 indicates whether the ICC is capable of changing its mode of operation. which is used to determine the value of programming voltage P required by the ICC. It is capable of changing if b8 is set to 0.3). Note: Existing terminals may maintain VPP in the idle state (see section 5. b5 = 0 The terminal is able to support the exact conditions indicated in the applicable interface characters and immediately uses those conditions.4.2 Book 1 Application Independent ICC to Terminal Interface Requirements 8 Answer to Reset 8.3 Character Definitions 8. Terminal behaviour: The terminal shall reject an ATR containing TB2. the terminal shall reject an ATR containing TA2. 8. b7–b6 are RFU (set to 00).  Basic response: The ATR shall not contain TA2.3. Terminal behaviour: The terminal shall accept an ATR containing TA2 provided that all the following conditions are met:    The protocol indicated in the l. b5 indicates whether the transmission parameters to be used following Answer to Reset are defined in the interface characters or are implicitly known by the terminal. or are implicitly known by the terminal if b5 is set to 1. nibble b4-b1 indicates the protocol to be used in specific mode. and unable to change if b8 is set to 1.3. When present.5 TA2 The presence or absence of TA2 indicates whether the ICC will operate in specific mode or negotiable mode respectively following the answer to reset.3.3. l. the absence of TA2 indicates the negotiable mode of operation.s. When present it overrides the value indicated by PI1 returned in TB1. June 2008 Page 79 .6 TB2 TB2 conveys PI2.

3.3 Character Definitions EMV 4. The work waiting time is given by 960 x D x WI. These bits (b5–b8) are set to the logic one state to indicate the presence of TA3 to TD3.8 Answer to Reset 8.s. indicating that TA3 and TB3 are present and that protocol type T=1 shall be used for all subsequent transmissions.  Basic responses: The ATR shall not contain TD2 if T=0 is to be used. respectively. nibble is used to indicate whether the characters TA3 to TD3 are present. 8. nibble of TD1 is '0'). and the l.2 Book 1 Application Independent ICC to Terminal Interface Requirements 8. nibble indicates the protocol type to be used for subsequent exchanges.8 TD2 TD2 indicates whether any further interface bytes are to be transmitted and the protocol type to be used for subsequent transmissions.3.3. Terminal behaviour: The terminal shall:    reject an ATR containing TC2 = '00' accept an ATR containing TC2 = '0A' reject an ATR containing TC2 having any other value unless it is able to support it. Terminal behaviour: The terminal shall accept an ATR containing TD2 with the m. It shall take the value '1' as T=1 is to be used. The l. The basic response coding of character TD2 is shown in Table 22: b8 T=1 0 b7 0 b6 1 b5 1 b4 0 b3 0 b2 0 b1 1 Table 22: Basic Response Coding of Character TD2 Page 80 June 2008 . nibble having a value of '1' (or 'E' if the l. and the protocol type T=0 shall be used as a default for all subsequent transmissions. Basic response: The ATR shall not contain TC2 and a default value of WI = 10 shall be used during subsequent communication. The terminal shall reject an ATR containing other values of TD2.7 TC2 TC2 is specific to protocol type T=0 and conveys the work waiting time integer (WI) that is used to determine the maximum interval between the leading edge of the start bit of any character sent by the ICC and the leading edge of the start bit of the previous character sent either by the ICC or the terminal (the work waiting time). where:  The m.3. nibble having any value (provided that the value returned correctly indicates and is consistent with the interface characters TA3 to TD3 actually returned).s.s.s.s. The ATR shall contain TD2 = '31' if T=1 is to be used.

The basic response coding of character TA3 is shown in Table 23: b8 T=1 x b7 x b6 x b5 x b4 x b3 x b2 x b1 x '00' to '0F' and 'FF' not allowed Table 23: Basic Response Coding of Character TA3 June 2008 Page 81 .2 Book 1 Application Independent ICC to Terminal Interface Requirements 8 Answer to Reset 8.9 TA3 TA3 (if T=1 is indicated in TD2) returns the information field size integer for the ICC (IFSI). Basic response: If T=1 is to be used.3. which determines the IFSC. and shall continue the card session using a value of '20' for TA3. Values of '00' and 'FF' are reserved for future use. The terminal shall reject an ATR containing TA3 having a value in the range '00' to '0F' or a value of 'FF'.3.EMV 4. the ATR shall contain TA3 having a value in the range '10' to 'FE' indicating an initial IFSC in the range 16 to 254 bytes. It represents the length of IFSC in bytes and may take any value between '01' and 'FE'.3 Character Definitions 8. Terminal behaviour: The terminal shall accept an ATR not containing TA3 (provided that b5 of TD2 is set to 0). and specifies the maximum length of the information field (INF) of blocks that can be received by the card.

The type of code to be used is indicated in b1. thus indicating longitudinal redundancy check (LRC) as the error code to be used. The basic response coding of character TB3 is shown in Table 24: b8 T=1 0 b7 x b6 x b5 x b4 0 b3 y b2 y b1 y xxx is in the range 000 to 100 yyy is in the range 000 to 101 Table 24: Basic Response Coding of Character TB3 Terminal behaviour: The terminal shall reject an ATR not containing TB3. Basic response: If T=1 is to be used. and b2 to b8 are not used.11 TC3 TC3 (if T=1 is indicated in TD2) indicates the type of block error detection code to be used.3 Character Definitions EMV 4. The l. and the m. Page 82 June 2008 . the ATR shall contain TB3 having the l. or containing a TB3 indicating BWI greater than 4 and/or CWI greater than 5.3.2 Book 1 Application Independent ICC to Terminal Interface Requirements 8. if TC1='FF'.s.3. whilst the m. TC1 shall have a value in the range '00' to '1E' or a value of 'FF' in order to avoid a conflict between TC1 and TB3. indicating values of 0 to 5 for CWI and 0 to 4 for BWI.3. It shall reject an ATR containing TC3 having any other value. Terminal behaviour: The terminal shall accept an ATR containing TC3 = '00'. Since the maximum value for CWI allowed by these specifications is 5. or having a value such that 2CWI  (N + 1). When using T=1.10 TB3 TB3 (if T=1 is indicated in TD2) indicates the values of the CWI and the BWI used to compute the CWT and BWT respectively. nibble in the range '0' to '5'. 8. note that when T=1 is used. nibble in the range '0' to '4'. nibble (b1–b4) is used to indicate the value of CWI. It shall accept an ATR containing a TB3 having any other value. the value of N shall be taken as –1. nibble (b5–b8) is used to indicate the value of BWI.s.s. Note: N is the extra guardtime indicated in TC1.s.8 Answer to Reset 8. Basic response: The ATR shall not contain TC3.3.

000 initial etus (19. It shall accept an ICC returning an ATR not containing TCK if T=0 only is indicated.200 + 4. If the terminal rejects a cold ATR as described in section 8.600 + 480 initial etus).1.800 initial etus) measured from the leading edge of the start bit of the TS character of the ATR. If the terminal rejects a warm ATR as described in section 8.     June 2008 Page 83 .4 Terminal Behaviour during Answer to Reset 8.3. it shall initiate the deactivation sequence within 24.1. or containing an incorrect TCK.000 initial etus (19.200 + 4. The value of TCK is such that the exclusive-OR‘ing of all bytes from T0 to TCK inclusive is null. The terminal shall not initiate the warm reset until the T0 character has been received.600 + 4. 8.080 initial etus (9.1. the terminal shall reject an ICC returning an ATR not containing TCK. In all other cases TCK shall be returned in the ATR.4 TCK .800 initial etus) following the leading edge of the start bit of the last received character (the character from which timeout occurred). the terminal shall abort the card session by initiating the deactivation sequence within 14. The terminal shall be able to receive an ATR having maximum interval between two consecutive characters of 10.3.3. The terminal shall be able to receive an ATR having a minimum interval between the leading edges of the start bits of two consecutive characters of 11.3. If a character is not received.8 initial etus. In all other cases.4 Terminal Behaviour during Answer to Reset Following activation of the ICC contacts as described in section 6. Basic responses: The ATR shall not contain TCK if T=0 only is to be used.800 initial etus) measured from the leading edge of the start bit of the TS character of the cold ATR to the time that RST is set low. Terminal behaviour: The terminal shall be able to evaluate TCK when appropriately returned.400 initial etus (9.EMV 4.800 initial etus) measured from the leading edge of the start bit of the TS character of the warm ATR. Subsequently the following shall apply:  If the terminal rejects the ICC as described in section 8.3.2 the terminal shall initiate a cold reset as described in section 6.200 + 4. it shall initiate the deactivation sequence within 24. it shall not immediately abort the card session but shall initiate a warm reset within 24.Check Character TCK has a value that allows the integrity of the data sent in the ATR to be checked.000 initial etus (19.2 Book 1 Application Independent ICC to Terminal Interface Requirements 8 Answer to Reset 8.

200 + 4.   Page 84 June 2008 .160 initial etus. It may continue the card session as soon as the last character of the valid ATR (as indicated by the bit map characters T0 and/or TDi) and TCK.000 initial etus (19.800 initial etus) measured from the leading edge of the start bit of the TS character of the ATR.800 initial etus) following the leading edge of the start bit of the TS character. Upon receipt of a valid cold or warm reset complying with the timings described above. the terminal shall proceed with the card session using the returned parameters. BGT for T=1) measured from the leading edge of the start bit of the last character of the valid ATR.000 initial etus (19. Before transmitting. If the terminal detects a parity error in a character returned in the ATR. if present. If the ATR (warm or cold) is not completed the terminal shall abort the card session by initiating the deactivation sequence within 24.200 + 4. it shall wait at least the guardtime applicable to the protocol to be used (16 etus for T=0.2 Book 1 Application Independent ICC to Terminal Interface Requirements  The terminal shall be able to receive an ATR having a duration of less than or equal to 20.8 Answer to Reset 8. it shall initiate the deactivation sequence within 24. has been received.4 Terminal Behaviour during Answer to Reset EMV 4.

Example Flow at the Terminal June 2008 Page 85 . Case = 1 for a cold reset.Flow at the Terminal 8.4 are respected ABORT (See Note 3) Is No ATR check 2 OK? ATR check 2 is OK if the parameters and structure of the ATR conform to the requirements of section 8 Yes Is Case = 1? No OR if a proprietary ATR is recognised Continue using parameters determined above OR (See Note 4) ABORT (See Note 2) Figure 11: ATR . START Set Case = 1 (See Note 1) Warm Reset Set Case = 2 Yes Is Yes ATR check 1 OK? ATR check 1 is OK if parity and TCK (if returned) are correct.Flow at the Terminal Figure 11 illustrates an example of the process of an ICC returning an ATR to the terminal and the checks performed by the terminal to ensure conformance to section 8.EMV 4. An appropriate message should be displayed on the terminal.5 Answer to Reset .2 Book 1 Application Independent ICC to Terminal Interface Requirements 8 Answer to Reset 8. Note 3: If the process aborts at this point. Cold Reset Note 4: A proprietary card session beyond the scope of this specification may be started at this point. The terminal should be primed to accept the ICC prior to insertion. Any subsequent processing is proprietary and beyond the scope of this specification. and Case = 2 for a warm reset. Note 2: If the process aborts at this point.5 Answer to Reset . reset may be retried after removing the ICC from the terminal and taking corrective action as required. the ICC may be acceptable in this terminal by business agreement. Note 1: „Case‟ is a process variable used to indicate whether a cold or warm reset is operative. and the timings specified in No section 8.

Flow at the Terminal EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements Page 86 June 2008 .8 Answer to Reset 8.5 Answer to Reset .

Terminals shall support both protocol T=0 and T=1.2 through 9.1 Physical Layer Both protocols T=0 and T=1 use the physical layer and character frame as defined in section 7. The protocol to be used for subsequent communication between the ICC and terminal is indicated in TD1. The protocol indicated by the ICC applies immediately after the answer to reset. Data link layer. Character protocol T=0. defining the exchanges of characters common to both protocols. which includes the following sub-definitions:        Character frame.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9 Transmission Protocols This section defines the structure and processing of commands initiated by the terminal for transmission control and for specific control in asynchronous half duplex transmission protocols. which defines the transmission of application-oriented messages specific to each protocol. defining the exchange of characters specific to T=0. Other parameters returned in the ATR and relevant to a specific protocol are defined in sections 9. Application layer.4. which describes the exchanges of bits and is common to both protocols. The protocols are defined according to the following layering model:   Physical layer. ICCs shall support either protocol T=0 or protocol T=1. and shall be T=0 or T=1. If TD1 is absent in the ATR. Block protocol T=1. 9. Two types of protocol are defined. Error detection and correction specific to T=1.EMV 4. which defines the exchange of messages according to an application protocol that is common to both transmission protocols. defining the exchanges of blocks specific to T=1. June 2008 Page 87 . Transport layer. T=0 is assumed. as there is no PTS procedure. character protocol (T=0) and block protocol (T=1). Error detection and correction specific to T=0.

2.2 applies to all messages exchanged between the ICC and the terminal. and error handling for protocols T=0 and T=1. specific options.1 Character Frame The character frame as defined in section 7.2 Data Link Layer This section describes the timing.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9.9 Transmission Protocols 9. 9.2 Data Link Layer EMV 4. Page 88 June 2008 .

These timings do not apply during character repetition. The terminal shall be able to correctly interpret characters sent by the ICC with a minimum interval between the leading edges of the start bits of two consecutive characters of 11.3). The maximum interval between the leading edge of the start bit of any character sent by the ICC and the leading edge of the start bit of the previous character sent either by the ICC or the terminal (the Work Waiting Time.1 Specific Options .2 Data Link Layer 9.2 Character Protocol T=0 9. This interval may be less than the minimum interval of 16 etus allowed between two characters sent in opposite directions.2. respectively).2 Book 1 Application Independent ICC to Terminal Interface Requirements 9 Transmission Protocols 9.8 etus. The minimum interval between the leading edges of the start bits of two consecutive characters sent by the ICC to the terminal shall be 12 etus. the terminal shall initiate the deactivation sequence within {WWT + (D x 9600)} etus following the leading edge of the start bit of the character from which the timeout occurred. the ICC shall be able to correctly interpret characters sent by the terminal with a minimum interval between the leading edges of the start bits of two consecutive characters of 11. June 2008 Page 89 . If no character is received. the minimum interval between the leading edges of the start bits of the last character received and the first character sent in the opposite direction shall be 16 etus.2 and 8.8 + N etus.2. The ICC or terminal shall be able to correctly interpret a character received within 15 etus timed from the leading edge of the start bit of the last character sent to the leading edge of the start bit of the received character. For the ICC or terminal.2. The terminal shall be able to correctly interpret a character sent by the ICC with a maximum interval between the leading edge of the start bit of the character and the leading edge of the start bit of the previous character sent either by the ICC or the terminal of {WWT + (D x 480)} etus. If the value returned in TC1 is N.EMV 4.Character Timing for T=0 The minimum interval between the leading edges of the start bits of two consecutive characters sent by the terminal to the ICC shall be between 12 and 266 etus as determined by the value of TC1 returned at the answer to reset (see sections 8. or WWT) shall not exceed 960 x D x WI etus (D and WI are returned in TA1 and TC2.

INS is the instruction code.3 Command Processing Following reception of a command header by the ICC. or the maximum length of data expected in the response from the ICC. where:     CLA is the command class.2. P1 and P2 contain additional instruction-specific parameters. INS.9 Transmission Protocols 9. The mapping of the command application protocol data unit (C-APDU) onto the C-TPDU is described in section 9. Both the TTL and ICC shall know implicitly at any point during exchange of commands and data between the TTL and the ICC what the direction of data flow is and whether it is the TTL or the ICC that is driving the I/O line. These bytes together with any data to be sent with the command constitute the command transport protocol data unit (C-TPDU) for T=0. and P3. the ICC shall return a procedure byte or status bytes SW1 SW2 (hereafter referred to as ‗status‘) to the TTL.2 Data Link Layer EMV 4. depending on the coding of INS. 9.2 Command Header A command is always initiated by the terminal application layer (TAL) which sends an instruction via the TTL to the ICC in the form of a five byte header called the command header. P2. The command header is comprised of five consecutive bytes.2.2. Page 90 June 2008 . P3 indicates either the length of data to be sent with the command to the ICC.3. The TTL transmits the five-byte header to the ICC and waits for a procedure byte. P1. CLA.2.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9.

or the TTL shall be ready to receive all remaining data bytes from the ICC The next data byte shall be transferred by the TTL. Equal to complement of INS byte ( INS ) '60' '61' '6C' June 2008 Page 91 . or the TTL shall be ready to receive the next data byte from the ICC The TTL shall provide additional work waiting time as defined in this section The TTL shall wait for a second procedure byte then send a GET RESPONSE command header to the ICC with a maximum length of 'xx'. where 'xx' is the value of the second procedure byte The TTL shall wait for a second procedure byte then immediately resend the previous command header to the ICC using a length of 'xx'. Procedure Byte Value Equal to INS byte Action All remaining data bytes shall be transferred by the TTL. after the action has taken place the TTL shall wait for a further procedure byte or status.EMV 4.2. where 'xx' is the value of the second procedure byte Table 25: Terminal Response to Procedure Byte In all cases.3.2. The coding of the byte and the action that shall be taken by the TTL is shown in Table 25.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9 Transmission Protocols 9.2 Data Link Layer 9.1 Procedure Byte The procedure byte indicates to the TTL what action it shall take next.

or only expecting data in response from the ICC (cases 2 and 3 in section 9. 9. First Status Byte Value '6x' or '9x' (except '60'.2.2. The meaning of the status bytes is related to the command being processed and is defined in section 11 and in Book 3.4 Transportation of C-APDUs A C-APDU containing only command data to be sent to the ICC. Page 92 June 2008 .2 Data Link Layer EMV 4.3.4). A C-APDU that contains and expects no data.3 for transportation by a C-TPDU for T=0.1) to the TAL in the response APDU (R-APDU) and await a further C-APDU.3. or a C-APDU that requires data transmission to and from the ICC (cases 1 and 4 in section 9.status byte SW1 Action TTL shall wait for a further status byte (status byte SW2) Table 26: Status Byte Coding Following receipt of the second status byte.9 Transmission Protocols 9.2.2 Status Bytes The status bytes indicate to the TTL that command processing by the ICC is complete. '61' and '6C') . The coding of the first status byte and the action that shall be taken by the TTL are shown in Table 26.see section 9.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9. the TTL shall return the status bytes (together with any appropriate data .4) is translated according to the rules defined in section 9.2. is mapped without change onto a T=0 C-TPDU.

10. If the last repetition is unsuccessful.2 etus .2) etus following the leading edge of the start bit of the character for a minimum of 1 etu and a maximum of 2 etus.600 etus following the leading edge of the start bit of the (invalid) byte received.2.2.1 and 9. If the transmitter detects an error.earliest low Parity signalling Repeated character 9. 0.10.2 Data Link Layer 9.2. The transmitter shall test the I/O line (11 ± 0.3 etus if a parity error is signalled Figure 12: Character Repetition Timing When awaiting a procedure byte or status byte.3.3 Error Detection and Correction for T=0 This procedure is mandatory for T=0 but does not apply during the answer to reset.7 etus Earliest high . if the byte returned by the ICC has a value other than specified in sections 9.5 ± 0. the receiver shall indicate an error by setting the I/O line to state L at time (10.earliest high 12. The transmitter shall repeat the same disputed character a maximum of three more times. the terminal shall initiate the deactivation sequence within 9.12.3 etus Latest low . and assumes that the character was correctly received if the I/O line is in state H.8 etus . Character repetition timing is illustrated in Figure 12.latest end Start of character Transmitter tests I/O here (11 ± 0.3 etus I/O may be high or low Times are relative to start of character I/O is guaranteed low between 10.7 etus and 11.2.earliest end 10.2.2. June 2008 Latest high .7 etus Page 93 .2) etus after the leading edge of the start bit of a character was sent.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9 Transmission Protocols 9. the terminal shall initiate the deactivation sequence within (D x 960) etus following reception of the leading edge of the start bit of the invalid character (if it is the receiver). or within (D x 960) etus following detection of the signalling of the parity error by the ICC (if it is the transmitter).8 etus . If a character is received with a parity error.11.2 etus) Character with parity error Earliest low .EMV 4. and shall therefore send a character up to a maximum of five times in total (the original transmission followed by the first repeat and then three further repeats) in an attempt to achieve error free transmission. it shall repeat the disputed character after a delay of at least 2 etus following detection of the error.3.8 etus .

The block is structured as illustrated in Table 27: Prologue Field .2 Book 1 Application Independent ICC to Terminal Interface Requirements 9.4. The data link layer block frame structure. acknowledgment).2.1. 9.2.1    Prologue Field The Prologue Field is mandatory and consists of three mandatory bytes: Node address (NAD) to identify source and intended destination of the block and to provide VPP state control Protocol control byte (PCB) to control data transmission Length (LEN) of the optional information field Page 94 June 2008 .2.Mandatory Node Address (NAD) 1 byte Protocol Control Byte (PCB) 1 byte Length (LEN) 1 byte Information Field . specific options of the protocol.Optional APDU or Control Information (INF) 0–254 bytes Epilogue Field .4 Block Protocol T=1 The protocol consists of blocks transmitted between the TAL and the ICC to convey command and R-APDUs and transmission control information (for example.4.Mandatory Error Detection Code (EDC) 1 byte Table 27: Structure of a Block 9.2 applies.2 Data Link Layer EMV 4. and protocol operations (including error handling) are defined below.9 Transmission Protocols 9.1 Block Frame Structure The character frame as defined in section 7.

and indicates the type of block. Protocol Control Byte The PCB is mandatory.EMV 4.2. There are three types of blocks.2 Data Link Layer NAD is mandatory. A value of 0 indicates that VPP shall be maintained in the idle state. as defined in Table 28: Type of Block Information block Receive-ready block Supervisory block Short Name I-block R-block S-block Purpose to convey APDUs to convey acknowledgments (ACK or NAK) to exchange control information Table 28: Types of Blocks Defined in ISO/IEC 7816-3:1997 as VPP control for class A. These specifications do not support node addressing. 7 June 2008 Page 95 . it shall apply the error detection and correction techniques described in section 9. In this event.2 Book 1 Application Independent ICC to Terminal Interface Requirements Node Address 9 Transmission Protocols 9. If during the card session the terminal or ICC receives a block with a NAD  '00'.5. Bits b1–b3 of NAD indicate the source node address (SAD) of the block. The first block sent by the terminal following the ATR and all following blocks transmitted by either the terminal or ICC shall have the NAD = '00'. whilst bits b5–b7 indicate the intended destination node address (DAD) of the block. it may treat the block as invalid. Bits b4 and b8 7 are unused and shall be set to 0.

2 Data Link Layer EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements The coding of the PCB depends on its type and is defined in Table 29.9 Transmission Protocols 9. and Table 31. Page 96 June 2008 . Table 30. b8 b7 b6 b5–b1 0 Sequence number Chaining (more data) Reserved for future use (RFU) Table 29: Coding of the PCB of an I-block b8 b7 b6 b5 b4–b1 1 0 0 Sequence number 0 = Error free 1 = EDC and/or parity error 2 = Other error(s) Other values RFU Table 30: Coding of the PCB of a R-block b8 b7 b6 b5–b1 1 1 0 = Request 1 = Response 0 = Resynchronisation request 1 = Information field size request 2 = Abort request 3 = Extension of BWT request 4 = VPP error 8 Other values RFU Table 31: Coding of the PCB of a S-block 8 Not used by ICCs and terminals conforming to this specification.

The value of the number starts with zero for the first I-block sent after the answer to reset by a sender and is incremented by one after sending each I-block.EMV 4. The normal default of the LRC is thus used for the EDC.1. 9. When present in a S-block. This specification supports only the LRC as EDC. 9. b5 of the PCB of the R-block carries the sequence number of the next I-block its sender expects to receive. A S-block carries no number.4.2 Book 1 Application Independent ICC to Terminal Interface Requirements Length 9 Transmission Protocols 9. A block is invalid when a parity error and/or an EDC error occurs. The number is reset to zero by the sender after resynchronisation.2    Information Field The Information Field (INF) is conditional. and contains the EDC of the transmitted block. it conveys control information.4 Block Numbering I-blocks are numbered using a modulo-2 number coded on one bit.2 Data Link Layer The Length (LEN) is mandatory. if present.1. R-blocks are numbered using a modulo-2 number coded on one bit. is not returned by the ICC in the ATR.2.2. Epilogue Field 9.2. In either case. and indicates the length of the INF part of the block.1. The numbering system is maintained independently at the ICC and the terminal as senders.3 The Epilogue Field is mandatory. When present in an I-block. which indicates the type of error detection code to be used. A R-block is used to acknowledge a chained I-block or to request retransmission of an invalid block. A R-block shall not contain an INF. Note: TCi (i  2). it may range from 0 to 254 depending on the type of block. The LRC is one byte in length and is calculated as the exclusive-OR of all the bytes starting with the NAD and including the last byte of INF.4. June 2008 Page 97 . Note: This specification does not support I-blocks with LEN = 0.4. it conveys application data.

2. and is defined as follows. and this size shall be used throughout the rest of the card session. The maximum block size that can be received by the ICC is therefore (IFSC + 3 + 1) bytes including the prologue and epilogue fields. The initial size immediately following the answer to reset shall be 254 bytes.4.9 Transmission Protocols 9.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9.2. IFSI may take values in the range '10' to 'FE' that indicate values for IFSC in the range 16 to 254 bytes. At the answer to reset the IFSI is returned by the ICC in TA3 indicating the size of the IFSC that can be accommodated by the ICC.4.1 Information Field Sizes The IFSC is the maximum length of the information field of blocks that can be received by the ICC.2 Specific Options This section defines the information field sizes and timings to be used with protocol type T=1. Page 98 June 2008 . 9. The size established during the answer to reset shall be used throughout the rest of the card session or until a new value is negotiated by the ICC by sending a S(IFS request) block to the terminal. The information field size for the terminal (IFSD) is the maximum length of the information field of blocks that can be received by the terminal.2.2 Data Link Layer EMV 4.

2 Data Link Layer 9.10. The block waiting time integer.4. For the ICC or terminal. and thus BWT lies in the range 971 to 15.2.8 + N etus.3). BGT) shall be 22 etus. The terminal shall be able to correctly interpret characters sent by the ICC with a minimum interval between the leading edges of the start bits of two consecutive characters of 10.2.2 and 8. The character waiting time integer.10. The receiver shall be able to correctly interpret a character having a maximum interval between the leading edge of the start bit of the character and the leading edge of the start bit of the previous character of (CWT + 4) etus. the minimum interval between the leading edges of the start bits of the last received character and the first character sent in the opposite direction (the block guard time.8 etus.3. If the value returned in TC1 is N.371 etus for a D of 1.EMV 4. The maximum interval between the leading edges of the start bits of two consecutive characters sent in the same block (the character waiting time. CWI shall have a value of 0 to 5 as described in section 8. The ICC or terminal shall be able to correctly interpret a character received within 21 etus timed from the leading edge of the start bit of the last character that it sent to the leading edge of the start bit of the received character. BWT) shall not exceed {(2BWI x 960) + 11} etus.2 Timing for T=1 The minimum interval between the leading edges of the start bits of two consecutive characters sent by the terminal to the ICC shall be between 11 and 42 etus as indicated by the value of TC1 returned at the answer to reset (see sections 8.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9 Transmission Protocols 9. CWT) shall not exceed (2CWI + 11) etus. the ICC shall be able to correctly interpret characters sent by the terminal with a minimum interval between the leading edges of the start bits of two consecutive characters of 11. Note: In general.3. and thus CWT lies in the range 12 to 43 etus.3. The minimum interval between the leading edges of the start bits of two consecutive characters sent by the ICC to the terminal shall be 11 etus. The maximum interval between the leading edge of the start bit of the last character that gave the right to send to the ICC and the leading edge of the start bit of the first character sent by the ICC (the block waiting time.3. The terminal shall be able to correctly interpret the first character of a block sent by the ICC following a time BWT + (D x 960) etus. BWT is calculated using the formula:   372D  BWT    2 BWI  960    11 etu F    June 2008 Page 99 . for values of FI and DI other than 1. BWI shall have a value in the range 0 to 4 as described in section 8.

2. it shall send a S(IFS request) block to the terminal.4. The half duplex block protocol consists of blocks transmitted alternately by the terminal and the ICC. The PCB of the S(IFS response) block sent in response shall have the value 'E1'. 5. only blocks as defined in this section shall be exchanged. The INF field shall contain a byte the value of which indicates the size in bytes of the requested new IFSC. that the ICC returns to the terminal. The ICC shall return a S(IFS response) block to the terminal acknowledging the change to the size of the IFSD. 8. The ICC shall acknowledge an I-block transmitted by the terminal. The receiver is not required to evaluate bits b4–b1 of the PCB. the sender switches to the receiving state. When a R-block is received. 4. 6. 7. If no I-block was previously received. and the INF field shall have the same value as the INF field of the block requesting the change. When the receiver has received the number of characters in accordance with the value of LEN and the EDC. or the R-block if chaining is in use (except the last block of the chain). the receiver gains the right to send. This byte shall have a value in the range '10' to 'FE'. The PCB of the S(IFS response) block sent in response shall have the value 'E1'. When the sender has transmitted a complete block. and the INF field shall have the same value as the INF field of the block requesting the change. If the ICC wishes to change the size of the IFSC from the initial value indicated at the answer to reset. Optional evaluation of bits b4–b1 shall not result in any action which contradicts the protocol rules defined in this specification Page 100 June 2008 . During the card session. The PCB of the S(IFS request) block shall have the value 'C1' indicating a request to change the IFSC. 3. b5 shall be evaluated.3 Error Free Operation The protocol rules for error free operation are as follows: 1. the sequence number of the I-block sent in response shall be 0.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9.2 Data Link Layer EMV 4. The first block transmitted after the answer to reset shall be sent by the terminal to the ICC and shall be a S(IFS request) block with PCB = 'C1' and with IFSD = 254 (value indicated in the single byte INF field). A non-chained I-block or the last I-block of a chain is considered by the sender to be acknowledged when the sequence number of the I-block received in response differs from the sequence number of the previously received I-block. The acknowledgment is indicated in the sequence number of the I-block.9 Transmission Protocols 9. The terminal shall return a S(IFS response) block to the ICC acknowledging the change to the size of the IFSC.2. No further S(IFS request) blocks shall be sent by the terminal during the card session.

The terminal shall acknowledge by sending a waiting time extension response S(WTX response) block with the same value in the INF.5 shall apply. where the INF contains the one-byte binary integer multiplier of the BWT value requested. if correctly received.4. The chaining of I-blocks is controlled by b6 of the PCB.2. a chained I-block (except the last I-block of a chain) is considered by the sender to be acknowledged when the sequence number of the R-block sent in response differs from the sequence number of the I-block being acknowledged. the terminal will only transmit further I-blocks if another command is to be processed. The last block of a chain sent by the terminal shall be acknowledged by either an I-block if correctly received. The last block of a chain sent by the ICC shall be acknowledged by a R-block if incorrectly received.4 Chaining When the sender has to transmit data of length greater than IFSC or IFSD bytes. BWT is again used as the time allowed for the ICC to process the I-block. it shall send a waiting time extension request S(WTX request) block. S-blocks are used only in pairs. June 2008 Page 101 . The time allocated (which is the time requested in the S(WTX request) block. or a R-block if incorrectly received. During chaining. After the ICC responds. 9. A S(request) block is always followed by a S(response) block. 11. and which replaces BWT for this instance only) starts at the leading edge of the last character of the S(WTX response) block.4.2. 10. When synchronisation as outlined above is lost. The coding of b6 is as follows:   b6 = 0 b6 = 1 Last block of the chain Subsequent block follows Any I-block with b6 = 1 shall be acknowledged by a R-block according to section 9.2.EMV 4. The transmission of these multiple I-blocks is achieved using the chaining function described below.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9 Transmission Protocols 9. the procedure described in section 9. If the ICC requires more than the BWT to process the previously received I-block.1. it shall divide it into several consecutive I-blocks.2 Data Link Layer 9.

4.2. which shall have a length in the range 1 to IFSC bytes inclusive. whose length may be in the range 1 to IFSC bytes inclusive. When the terminal is the sender. The ICC may optionally chain blocks sent to the terminal. the ICC shall reject it using a R-block. If the ICC as sender chains blocks sent to the terminal it shall send I-blocks of length IFSD bytes per block. When the ICC is the receiver. if an I-block sent by the terminal has length > IFSC. the ICC shall not attempt to negotiate a new IFSC by sending a S(IFSC request) block to the terminal.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9. Chaining is only possible in one direction at a time.4. When the ICC is the receiver. the ICC shall accept a sequence of chained I-blocks sent from the terminal all having length LEN = IFSC except the last block. all I-blocks of a chain sent to the ICC shall have LEN = IFSC bytes except the last.9 Transmission Protocols 9.1 Rules for Chaining The TTL shall support chaining for both transmitted and received blocks.2 Data Link Layer EMV 4. During chaining.     Page 102 June 2008 . The following rules for chaining apply:   When the terminal is the receiver. the terminal shall accept a sequence of chained I-blocks sent from the ICC of length  IFSD bytes per block.

2 Book 1 Application Independent ICC to Terminal Interface Requirements 9 Transmission Protocols 9.2 Data Link Layer 9.2).4.3. If a C-APDU is too large to fit in one block. Block(1) Block(2) Block(n) Data Data Data Data Data Data SW1 SW2 Data Data Figure 14: Chaining I-Blocks Note: The above examples are for a case 4 command and show only the INF fields of the chained blocks.2 Construction of Chained Blocks C-APDUs are transported from the TTL to the ICC in the INF field of I-blocks (see section 9.2. Block(1) Block(2) Block(n) CLA INS P1 P2 Data Data Lc Data Data Data Le Data Data Figure 13: Chaining C-APDU The data and status returned by the ICC may optionally be chained over several I-blocks as illustrated in Figure 14. or IFSC bytes during chaining and 1 to IFSC bytes in the last block of the chain if the terminal is the sender.4.EMV 4. All chained blocks shall contain an INF field having a length in the range 1 to IFSD bytes if the ICC is the sender. it is chained over several as illustrated in Figure 13. June 2008 Page 103 . Each block also has a prologue and epilogue field.

9 Transmission Protocols 9. i. and BWT time-out. Protocol error (infringement of the rules of the protocol).2 Book 1 Application Independent ICC to Terminal Interface Requirements 9.2 Data Link Layer EMV 4.e. Where 'TTL' is used it includes any functionality present in the terminal as applicable.2. The TTL shall attempt error recovery by trying the following techniques in the order shown. Loss of synchronisation assumed when the actual block size is inconsistent with the size indicated by the value in LEN. Error recovery is attempted in the following manner. character repetition shall not be implemented when using T=1. a S(Response) block received in response to an I-block. i.e. the retransmitted block shall be identical to the originally transmitted block. The following types of block are considered invalid:    Blocks containing transmission errors. If a block is retransmitted. parity/EDC incorrect Blocks that have formatting errors. EDC error. Page 104 June 2008 . blocks constructed incorrectly by the sender (syntax error) Blocks that are unexpected according to the rules of the protocol at any particular point in an exchange. If a parity error is detected. Retransmission of blocks Deactivation of the ICC contacts The ICC shall attempt error recovery by trying retransmission of blocks. A R-block received indicating an error condition is not an invalid block. Note: In some terminals the TTL may not be solely responsible for error handling. for example. 1.5 Error Detection and Correction for T=1 The following errors shall be detected by the TTL:     Transmission error including parity error. Abort request for a chain of blocks.

transmit a R-block with its sequence number coded as specified in section 9. the terminal shall: (a) initiate the deactivation sequence OR (b) if the block not responded to was an I-block.2.4.4.800) etus from the leading edge of the start bit of the last character received. it shall return a R-block to the TTL with b5 = 0 and NAD = 0.1.800)} etus (or between {WTX + (n x D x 960)} and {WTX + (n x D x 4.EMV 4. the error coding bits b4–b1 may optionally be evaluated.4 OR (c) if the block not responded to was a S(Request) block.800)} etus if a waiting time extension has been negotiated) from the leading edge of the start bit of the last character of the block to which there was no response. 2. retransmit the S(Request) block between {BWT + (D x 960)} and {BWT + (D x 4. R-block. the terminal shall: (a) initiate the deactivation sequence OR (b) if the block not responded to was an I-block. 1. retransmit the S(Request) block within (CWT + 4) and (CWT + 4. or S(Response) block. 3. If there is no response from the ICC to a block sent by the TTL. In each case where a R-block is sent. but shall not result in any action which contradicts the protocol rules defined in this specification.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9 Transmission Protocols 9.1 Protocol Rules for Error Handling The following rules apply for error handling and correction. or S(Response) block. June 2008 Page 105 . If during reception of a block by the terminal an expected character is not received.5.2.2 Data Link Layer 9.4 OR (c) if the block not responded to was a S(Request) block.1. If the first block received by the ICC after the answer to reset is invalid.2. R-block. transmit a R-block with its sequence number coded as specified in section 9.

10. If a terminal optionally supporting abortion receives a S(ABORT request) from an ICC. request) block.. the sender shall transmit a R-block with its sequence number coded as specified in section 9. A S(ABORT request) shall not be sent by the terminal. If the terminal receives a S(ABORT request) from the ICC.2 Data Link Layer EMV 4.600) etus following reception of the leading edge of the start bit of the last character of the S(ABORT request) block.1. Page 106 June 2008 .. If an invalid block is received in response to a S(.4. it shall terminate the card session by initiating the deactivation sequence within (D x 9.9 Transmission Protocols 9.4. it may return a S(ABORT response) rather than terminating the card session.1. 5. 7. If an ICC or terminal supports abortion for proprietary reasons. the sender shall retransmit the R-block.4. the card session will be terminated according to the rules above..4. 9. 11. request) block. it may attempt this by sending a S(RESYNCH request) block.. the sender shall retransmit the S(. If the TTL has sent three consecutive blocks of any type without obtaining a valid response. If the ICC has sent a block a maximum of twice in succession (the original transmission followed by one repeat) without obtaining a valid response. In this event.2 Book 1 Application Independent ICC to Terminal Interface Requirements 4. but note that it will receive an invalid response if the receiver does not support abortion. then behave as specified in ISO/IEC 7816-3. If for proprietary reasons the terminal supports resynchronisation.. Note: Transaction abortion is not required by this specification. it shall initiate the deactivation sequence within {BWT + (D x 14.. Note: Resynchronisation is not required by this specification. response) block.. the sender shall transmit a R-block with its sequence number coded as specified in section 9.400)} etus following the leading edge of the start bit of the last character of the block requesting retransmission. it shall remain in reception mode. If a correct S(.2. If an invalid block is received in response to an I-block.2. response) block is not received in response to a S(. If an invalid block is received in response to a R-block. 8. it may issue a S(ABORT request). 6..

4. and the use of the GET RESPONSE command for retrieval of data from the ICC when case 2 or 4 commands are used.1 Transport of APDUs by T=0 This section describes the mapping of C-APDUs and R-APDUs. The construction of C-APDUs and R-APDUs are described in sections 9. data (if present) and status are returned by the ICC to the TTL.3 Terminal Transport Layer (TTL) 9.1 and 9. which maps it onto the R-APDU. 9.4. 9. respectively. and should never be returned to the TAL. June 2008 Page 107 . Such functionality is not required and is beyond the scope of these specifications. Following processing of the command by the ICC.1 Mapping of C-APDUs and R-APDUs and Data Exchange The mapping of the C-APDU onto the T=0 command header is dependent upon the case of the command. Procedure bytes '61xx' and '6Cxx' are returned by the ICC to control exchanges between the TTL and the ICC.3. and since both command and response messages may contain data.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9 Transmission Protocols 9. the TTL may in addition be capable of accepting data from the ICC without using the '61' and '6C' procedure bytes.2.3 Terminal Transport Layer (TTL) This section describes the mechanism by which command and response APDUs are transported between the terminal and the ICC. The C-APDU is passed from the TAL to the TTL where it is mapped in a manner appropriate to the transmission protocol to be used before being sent to the ICC. The mapping of the data (if present) and status returned by the ICC onto the R-APDU is dependent upon the length of the data returned and the meaning of the status bytes.EMV 4.3.1. the TTL shall be capable of managing the four cases defined in section 9. the mechanism for exchange of data between the TTL and the ICC. APDUs are command or response messages. Command processing in the ICC is not complete if it has returned procedure bytes '61xx' or '6Cxx'. Note: For proprietary reasons.4.

the TTL shall discontinue processing of the command. The TTL shall discontinue processing of a command (i. not to the case 2 or case 4 command which it completes.e. pass the R-APDU to the TAL and wait for a further C-APDU from the TAL) on receipt of any other status (but not on receipt of procedure bytes '61xx' and '6Cxx') from the ICC. immediately following successful transmission of command data to the ICC. 9. under normal or abnormal processing. (The ICC shall analyse the T=0 command header to determine whether it is processing a case 1 command or a case 2 command requesting all data up to the maximum length available. On receipt of status from the ICC. shall return status to the TTL. and '60' procedure bytes is not described.3. (For case 4 commands only. On receipt of the command header the ICC.) The following descriptions of the mapping of data and status returned by the ICC onto the R-APDU are for information. the TTL shall continue processing the command if warning status bytes ('62xx' or '63xx') or application related status bytes ('9xxx' except '9000') are received. and all data (if present) has been returned by the ICC under the control of '61xx' and '6Cxx' procedure bytes.) 3.2 Book 1 Application Independent ICC to Terminal Interface Requirements Normal status on completion of processing a command is indicated if the ICC returns status bytes SW1 SW2 = '9000' to the TTL. 2. and apply only after the ICC has completed processing of the command. The status returned to the TTL from the ICC after completion of processing of the command is mapped onto the mandatory trailer of the R-APDU without change.1 Case 1 The C-APDU header is mapped onto the first four bytes of the T=0 command header. Page 108 June 2008 . The flow of the exchange is as follows: 1.1. The TTL shall send the T=0 command header to the ICC.9 Transmission Protocols 9. The status returned by the ICC shall relate to the most recently received command.1. INS . where a GET RESPONSE command is used to complete the processing of a case 2 or case 4 command. and P3 of the T=0 command header is set to '00'.3 Terminal Transport Layer (TTL) EMV 4. See Annex A1 for details of the exchanges between the TTL and the ICC. Detailed use of the INS. any status returned by the ICC after receipt of the GET RESPONSE command shall relate to the GET RESPONSE command. successfully or otherwise.

The TTL shall send the T=0 command header to the ICC. The status returned is mapped onto the mandatory trailer of the R-APDU without change. the ICC shall return data and status to the TTL. The flow of the exchange is as follows: 1.3. including use of the '61xx' and '6Cxx' procedure bytes.  June 2008 Page 109 . procedure bytes '61xx') to control the return of data OR (b) under abnormal processing. On receipt of the command header: (a) under normal processing. or the status returned by the ICC that caused the TTL to discontinue processing of the command. On receipt of the data (if present) and status from the ICC.1. the TTL shall discontinue processing the command. See Annex A2 and Annex A5. the ICC shall return status only to the TTL. READ RECORD commands issued during application selection and all case 2 commands issued according to Book 3 shall have Le = '00'. and length byte 'Le' from the conditional body of the C-APDU is mapped onto P3 of the T=0 command header.1. If no data is returned. for details of the exchanges between the TTL and the ICC. are mapped onto the R-APDU as follows:  The data returned (if present) is mapped onto the conditional body of the R-APDU. 3. 2.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9 Transmission Protocols 9. using procedure bytes '6Cxx' (and if required.2 Case 2 The C-APDU header is mapped onto the first four bytes of the T=0 command header. The data (if present) and status returned to the TTL from the ICC after completion of processing of the command. the conditional body of the R-APDU is left empty.EMV 4.3 Terminal Transport Layer (TTL) 9.

The TTL shall send the T=0 command header to the ICC. 2.1. Page 110 June 2008 . On receipt of status from the ICC. the ICC shall return status following receipt of the conditional body of the C-APDU and completion of processing the command. the TTL shall send the data portion of the conditional body of the C-APDU to the ICC under the control of procedure bytes returned by the ICC. the TTL shall discontinue processing the command.9 Transmission Protocols 9. or the status returned by the ICC that caused the TTL to discontinue processing of the command. the TTL shall discontinue processing of the command. 3. On receipt of the command header: (a) If the ICC returns a procedure byte. for details of the exchanges between the TTL and the ICC. The status returned to the TTL from the ICC after completion of processing of the command.3 Case 3 The C-APDU header is mapped onto the first four bytes of the T=0 command header.3. See Annex A3.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9. If processing was not discontinued in step 2(b).1. 4. and length byte 'Lc' from the conditional body of the C-APDU is mapped onto P3 of the T=0 command header. The flow of the exchange is as follows: 1.3 Terminal Transport Layer (TTL) EMV 4. is mapped onto the R-APDU without change. OR (b) If the ICC returns status.

June 2008 Page 111 . 3. On receipt of the command header: (a) If the ICC returns a procedure byte. the TTL shall discontinue processing of the command.3. or which is application related ('9xxx' but not '9000').3.1. 5. the TTL shall discontinue processing of the command.3 Terminal Transport Layer (TTL) 9. The flow of the exchange is as follows: 1. OR (b) If the ICC returns status. OR (b) under abnormal processing. The TTL shall send the T=0 command header to the ICC. the TTL shall send a GET RESPONSE command with Le='00'. the ICC shall return status only to the TTL. the TTL shall send a GET RESPONSE command header to the ICC with P3 set to a value less than or equal to the value contained in the 'xx' byte of '61xx' procedure bytes. 4.1. and length byte 'Lc' from the conditional body of the C-APDU is mapped onto P3 of the T=0 command header. the TTL shall send the data portion of the conditional body of the C-APDU to the ICC under the control of procedure bytes returned by the ICC. 2. OR (c) If the ICC returned status as in step 3(b) other than that described in step 4(b). On receipt of the procedure bytes or status returned in step 3: (a) If the ICC returned '61xx' procedure bytes as in step 3(a).1. the ICC shall return procedure bytes '61xx' to the TTL requesting the TTL to issue a GET RESPONSE command to retrieve the data from the ICC.4 Case 4 The C-APDU header is mapped onto the first four bytes of the T=0 command header. following receipt of the conditional body of the C-APDU: (a) under normal processing. If processing was not discontinued in step 2(b).1. SELECT commands issued during application selection and all case 4 commands issued according to Book 3 shall have Le = '00'. the GET RESPONSE command shall be processed according to the rules for case 2 commands in section 9.2. OR (b) If the ICC returned status as in step 3(b) that indicates a warning ('62xx' or '63xx'). If processing was not discontinued in step 4(c).2 Book 1 Application Independent ICC to Terminal Interface Requirements 9 Transmission Protocols 9.EMV 4.

Page 112 June 2008 .3. The data (if present) and status returned to the TTL from the ICC after completion of processing of the command. the conditional body of the R-APDU is left empty. If no data is returned. including use of the '61xx' and '6Cxx' procedure bytes. is mapped onto the mandatory trailer of the R-APDU without change. Procedure bytes '6Cxx' instruct the TTL to immediately resend the previous command header setting P3 = 'xx'. including the GET RESPONSE command if used. or the status returned by the ICC that caused the TTL to discontinue processing of the command. the ICC may return status indicating error or warning conditions instead of the '61xx' or '6Cxx' response.2 Use of Procedure Bytes '61xx' and '6Cxx' The ICC returns procedure bytes '61xx' and '6Cxx' to the TTL to indicate to it the manner in which it should retrieve the data requested by the command currently being processed.9 Transmission Protocols 9.  9. Usage of these procedure bytes during error free processing with case 2 and 4 commands is as follows. P3 of the GET RESPONSE command header is set to  'xx'. Procedure bytes '61xx' instruct the TTL to issue a GET RESPONSE command to the ICC. are mapped onto the R-APDU as follows:  The data returned (if present) is mapped onto the conditional body of the R-APDU. These procedure bytes are only used when processing case 2 and 4 commands.2 Book 1 Application Independent ICC to Terminal Interface Requirements See Annex A4 and Annex A6. for details of the exchanges between the TTL and the ICC.1. The first status returned during processing of the entire case 4 command.3 Terminal Transport Layer (TTL) EMV 4. In the case of an error.

it shall return: (a) data of length Le (= Licc) under the control of the INS. 2.1. If the ICC receives a case 2 command header and Le = Licc. or '60' procedure bytes followed by procedure bytes '61xx' instructing the TTL to issue a GET RESPONSE command with a maximum length of 'xx' OR (b) procedure bytes '6C Licc' instructing the TTL to immediately resend the command header with P3 = Licc OR (c) status indicating a warning or error condition (but not SW1 SW2 = '90 00'). June 2008 Page 113 . If the ICC receives a case 2 command header and Le = '00' or Le > Licc.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9 Transmission Protocols 9.3.1 Case 2 Commands 1. Note: If Le = '00' and the ICC has 256 bytes of data to return. 3(b) above is not a valid response by the ICC to a GET RESPONSE command.3 Terminal Transport Layer (TTL) 9. it shall return: (a) data of length Le under the control of the INS. 3. or '60' procedure bytes followed by the associated status OR (b) procedure bytes '61xx' instructing the TTL to issue a GET RESPONSE command with a maximum length of 'xx' OR (c) status indicating a warning or error condition (but not SW1 SW2 = '90 00').EMV 4. it shall return: (a) procedure bytes '6C Licc' instructing the TTL to immediately resend the command header with P3 = Licc OR (b) status indicating a warning or error condition (but not SW1 SW2 = '90 00'). If the ICC receives a case 2 command header and Le < Licc. INS . INS . it should proceed as defined in the following rule for Le = Licc.2.

3.2. The GET RESPONSE command so issued is then treated as described in section 9.1. In the event that an error condition occurs. 9.1.1.3 Terminal Transport Layer (TTL) EMV 4. If the ICC receives a case 4 command. the ICC returns status bytes SW1 SW2 = '9000' and Licc bytes of data. it shall return: (a) procedure bytes '61 xx' instructing the TTL to issue a GET RESPONSE command with a maximum length of 'xx' OR (b) status indicating a warning or error condition (but not SW1 SW2 = '90 00'). The structure of the command message is shown in Table 32: CLA INS P1 P2 Le '00' 'C0' '00' '00' Maximum length of data expected Table 32: Structure of Command Message Following normal processing.3.2 Case 4 Commands 1.9 Transmission Protocols 9.1 for case 2 commands. It is employed only when the T=0 protocol type is in use.2. after processing the data sent with the C-APDU.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9. the coding of the error status bytes (SW1 SW2) is shown in Table 33: SW1 '62' '67' '6A' '6F' SW2 '81' '00' '86' '00' Meaning Part of returned data may be corrupted Length field incorrect P1 P2  '00' No precise diagnosis Table 33: GET RESPONSE Error Conditions Page 114 June 2008 .3.3 GET RESPONSE Command The GET RESPONSE command is issued by the TTL to obtain available data from the ICC when processing case 2 and 4 commands.

where the TAL sends a command to the ICC via the TTL.3. No data shall be returned with any other status. it shall also return data (if available) associated with processing of the command. Both command and response messages may contain data.2 Transportation of APDUs by T=1 The C-APDU is sent from the TAL to the TTL. and case 2 commands will become case 4. or is '9000'. Each specific command has a specific response.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9 Transmission Protocols 9. and sends the I-block to the ICC. Thus. which is application related ('9xxx'). Note: C-APDUs and response data/status may be chained over the INF fields of multiple blocks if required. and the ICC processes it and sends a response via the TTL to the TAL.EMV 4. If The ICC returns status indicating normal processing ('61xx'). The TTL maps the C-APDU onto the INF field of an I-block without change.4 Application Layer The application protocol consists of an ordered set of exchanges between the TAL and the TTL. The contents of the INF field of the I-block are mapped onto the R-APDU without change and returned to the TAL. 9. An APDU is defined as a command message or a response message. Each step in an application layer exchange consists of a command-response pair.4 Application Layer 9. June 2008 Page 115 . When using secure messaging. a warning ('62xx' or '63xx'). the MAC) is always sent to the ICC. as shown in Table 34: Case 1 2 3 4 Command Data Absent Absent Present Present Response Data Absent Present Absent Present Table 34: Definition of Cases for Data in APDUs Note: When secure messaging is used only case 3 and case 4 commands exist since data (as a minimum. case 1 commands will become case 3. four cases shall be managed by the transmission protocols via the TTL. Response data (if present) and status are returned from the ICC to the TTL in the INF field of an I-block.

if Le = 0. The value of Le may range from 0 to 255. bit is 0. the number of bytes sent being as defined by Lc.4.s. indicating the maximum number of data bytes expected in the R-APDU. P1. Note: The full coding of the headers for each command is covered in section 11. and the m. Note: The full coding of the data field of the conditional body for each command is covered in section 11. may take any value except 'FF'. INS. The value of Lc may range from 1 to 255. String of bytes sent as the data field of the C-APDU. The INS is only valid if the l.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9. denoted by Le. The conditional body consists of a string of bytes defined as follows:    1 byte. the maximum number of bytes expected in the response is 256.s. P1.4 Application Layer EMV 4. 1 byte. The four possible C-APDU structures are defined in Table 35: Case 1 2 3 4 Structure CLA INS P1 P2 CLA INS P1 P2 Le CLA INS P1 P2 Lc Data CLA INS P1 P2 Lc Data Le Table 35: C-APDU Structures Page 116 June 2008 . denoted by Lc. nibble is neither '6' nor '9'. INS: Instruction code within the instruction class.9 Transmission Protocols 9. and P2. P2: Reference bytes completing the INS. These mandatory header bytes are defined as follows:    CLA: Instruction class.1 C-APDU The C-APDU consists of a mandatory header of four consecutive bytes denoted CLA. followed by a conditional body of variable length. defining the number of data bytes to be sent in the C-APDU.

The mandatory trailer indicates the status of the ICC after processing the command. The coding of SW1 SW2 is defined in section 11. June 2008 Page 117 .2 R-APDU The R-APDU is a string of bytes consisting of a conditional body followed by a mandatory trailer of two bytes denoted SW1 SW2.2 Book 1 Application Independent ICC to Terminal Interface Requirements 9 Transmission Protocols 9.EMV 4.4 Application Layer 9. The conditional body is a string of data bytes with a maximum length as defined by Le in the C-APDU.4.

4 Application Layer EMV 4.9 Transmission Protocols 9.2 Book 1 Application Independent ICC to Terminal Interface Requirements Page 118 June 2008 .

and Application Selection June 2008 Page 119 . Commands.EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements Part III Files.

EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements Page 120 June 2008 .

1. 10. a description of logical content. and a coding. 10.EMV 4. It is up to the issuer to ensure that data in the card is of the correct format. A data element is the smallest piece of information that may be identified by a name.1 File Structure The file organisation applying to this specification is deduced from and complies with the basic organisations as defined in ISO/IEC 7816-4. An item of information is called a data element. An ADF and its related data files are seen as being on the same branch of the tree. A DDF is an entry point to other ADFs or DDFs. These items of information may be accessible to the terminal after a successful application selection. often contained within files. Allows access to the logical structure of an application by its selection. The files within the ICC are seen from the terminal as a tree structure.2 Book 1 Application Independent ICC to Terminal Interface Requirements 10 Files An application in the ICC includes a set of items of information. An ADF is the entry point to one or more Application Elementary Files (AEFs). June 2008 Page 121 . An ADF is seen from the terminal as a file containing only data objects encapsulated in its file control information (FCI) as shown in Table 45.1    Application Definition Files The tree structure of ADFs: Enables the attachment of data files to an application. This section describes the file structure of applications conforming to this specification. Data elements used during application selection that are not specified in Annex B are outside the scope of these specifications. The data element directory defined in Annex B includes those data elements that may be used for application selection. Ensures the separation between applications. Every branch of the tree is an Application Definition File (ADF) or a Directory Definition File (DDF). a format.

2. For the EMV Debit/Credit application. It may give access to elementary files and DFs. and when present there is no defined limit to the number of such directories that may exist. the ICC shall maintain a directory structure for the list of applications within the PSE that the issuer wants to be selected by a directory.1.1 File Structure EMV 4. An elementary file (EF) as defined in ISO/IEC 7816-4 is mapped onto the AEF. an EF) with a record structure according to this specification including the following data objects according to ISO/IEC 7816-4:   One or more Application Templates (tag '61') as described in section 12. retrieval of the attached EF is transparent to this specification. The directory structure allows for the retrieval of an application using its Application Identifier (AID) or the retrieval of a group of applications using the first n bytes of their AID as DDF name.4 Directory Structure When the Payment System Environment (PSE) as described in section 12.2 Book 1 Application Independent ICC to Terminal Interface Requirements 10. Optionally.3  Mapping of Files Onto ISO/IEC 7816-4 File Structure The following mapping onto ISO/IEC 7816-4 applies: A dedicated file (DF) as defined in ISO/IEC 7816-4 and containing a FCI is mapped onto an ADF or a DDF. the files are described in Book 3.2 is present. Directories are optional within an ICC. In that case. Each such directory is located by a directory SFI data object contained in the FCI of each DDF. An EF is never used as an entry point to another file. The data objects contained in this template are outside the scope of this specification. The presence of the DIR file shall be coded in the response message to the selection of the PSE (see the SELECT command). other data objects present within a Directory Discretionary Template (tag '73').1. 10. 10. the directory structure consists of a Payment System Directory file (DIR file) and optional additional directories introduced by a DDF as described in this section. Page 122 June 2008 .1. The DIR file is an AEF (in other words.10 Files 10.  If DFs are embedded. The DF at the highest level of the card is the master file (MF).2 Application Elementary Files The structure and use of AEFs is application dependent.

The coding of the SFI is described in every command that uses it.2.EMV 4.2 File Referencing 10.1 Referencing by Name Any ADF or DDF in the card is referenced by its DF name. A DF name for an ADF corresponds to the AID or contains the AID as the beginning of the DF name.2. 10. 10.2 Referencing by SFI SFIs are used for the selection of AEFs. June 2008 Page 123 .2 Book 1 Application Independent ICC to Terminal Interface Requirements 10 Files 10. A SFI shall be unique within an application. Each DF name shall be unique within a given card.2 File Referencing A file may be referred to by a name or a SFI depending on its type. Any AEF within a given application is referenced by a SFI coded on 5 bits in the range 1 to 30.

10 Files 10.2 Book 1 Application Independent ICC to Terminal Interface Requirements Page 124 June 2008 .2 File Referencing EMV 4.

All other commands shall be implemented as required by specific applications. To run an application. The terminal and the card shall also implement the physical. A specific response corresponds to a specific command. but shall conform to the APDU structures (formats) defined in Book 3. It includes steps consisting of sending a command to the card. This section describes the structure of the APDU command-response pairs necessary to the application protocols defined in this specification.EMV 4. and sending back the response to the terminal. and transport layers as defined in Part II. The command message sent from the application layer and the response message returned by the card to the application layer are called Application Protocol Data Units (APDU). This Book describes only those commands necessary to the functioning of application selection. These are referred to as APDU command-response pairs. All commands and responses referred to in the remainder of this Book are defined at the application layer. an additional layer called application protocol is implemented in the terminal. June 2008 Page 125 . data link. the command message and the response message may contain data.1 Message Structure Messages are transported between the terminal and the card according to the transmission protocol selected at the ATR (see Part II). Part II. In an APDU command-response pair.2 Book 1 Application Independent ICC to Terminal Interface Requirements 11 Commands 11. processing it in the card.

as shown in Figure 15: CLA  INS P1 P2 Lc  Data Conditional Body Le  Mandatory Header  Figure 15: Command APDU Structure The number of data bytes sent in the command APDU is denoted by Lc (length of command data field). When Le is present and contains the value zero.1.11 Commands 11.1 Command APDU Format The command APDU consists of a mandatory header of four bytes followed by a conditional body of variable length.2 Book 1 Application Independent ICC to Terminal Interface Requirements 11. Description Class of instruction Length 1 1 1 1 0 or 1 var. READ RECORD and SELECT commands issued during application selection and all case 2 and case 4 commands issued according to Book 3 shall have Le = '00'. The content of a command APDU message is as shown in Table 36: Code CLA INS P1 P2 Lc Data Le Instruction code Instruction parameter 1 Instruction parameter 2 Number of bytes present in command data field String of data bytes sent in command (= Lc) Maximum number of data bytes expected in data field of response Table 36: Command APDU Content The different cases of command APDU structure are described in Table 35. The maximum number of data bytes expected in the response APDU is denoted by Le (length of expected data). 0 or 1 Page 126 June 2008 . the maximum number of data bytes available ( 256) is requested.1 Message Structure EMV 4.

1.2 Response APDU Format The response APDU format consists of a conditional body of variable length followed by a mandatory trailer of two bytes. June 2008 Page 127 .1 Definition and Scope The READ RECORD command reads a file record in a linear file. The application layer may rely on the object oriented structure of the response message data field to calculate Lr if needed.2 READ RECORD Command-Response APDUs 11. Lr is not returned by the transport layer.2 READ RECORD Command-Response APDUs 11. The trailer indicates in two bytes the processing state of the command as returned by the transport layer.2 Book 1 Application Independent ICC to Terminal Interface Requirements 11 Commands 11.2.EMV 4. The content of a response APDU message is as shown in Table 37: Code Data SW1 SW2 Description String of data bytes received in response Command processing status Command processing qualifier Table 37: Response APDU Content Length var(= Lr) 1 1 11. as shown in Figure 16: Data  Body  SW1 SW2  Trailer  Figure 16: Response APDU Structure The number of data bytes received in the response APDU is denoted by Lr (length of response data field). The response from the ICC consists of returning the record.

Records read during application selection are directory records which are formatted as in section 12. 11.2 Command Message The READ RECORD command message is coded according to Table 38: Code CLA INS P1 P2 Lc Data Le '00' 'B2' Record number Reference control parameter (see Table 39) Not present Not present '00' Table 38: READ RECORD Command Message Table 39 defines the reference control parameter of the command message: b8 x b7 x b6 x b5 x b4 x 1 0 0 b3 b2 b1 SFI P1 is a record number Meaning Value Table 39: READ RECORD Command Reference Control Parameter 11.2.4 Data Field Returned in the Response Message The data field of the response message of any successful READ RECORD command contains the record read.3 Data Field Sent in the Command Message The data field of the command message is not present.2.11 Commands 11.2.2 Book 1 Application Independent ICC to Terminal Interface Requirements 11. Page 128 June 2008 .2 READ RECORD Command-Response APDUs EMV 4. 11.5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command.2.2.3. The format of records read during application processing is application dependent.

2 Book 1 Application Independent ICC to Terminal Interface Requirements 11 Commands 11.EMV 4. DDF. The selection of an application is described in section 12.3 SELECT Command-Response APDUs 11.1 Definition and Scope The SELECT command is used to select the ICC PSE. The response from the ICC consists of returning the FCI. or ADF using SFIs. A successful execution of the command sets the path to the PSE. or ADF corresponding to the submitted file name or AID.3 SELECT Command-Response APDUs 11. or ADF. DDF.3. Subsequent commands apply to AEFs associated with the selected PSE. DDF. June 2008 Page 129 .

11 Commands 11.3 SELECT Command-Response APDUs EMV 4.3.3.3 Data Field Sent in the Command Message The data field of the command message contains the PSE name or the DF name or the AID to be selected. Page 130 June 2008 .2 Book 1 Application Independent ICC to Terminal Interface Requirements 11.2 Command Message The SELECT command message is coded according to Table 40: Code CLA INS P1 P2 Lc Data Le '00' 'A4' Reference control parameter (see Table 41) Selection options (see Table 42) '05'–'10' File name '00' Table 40: SELECT Command Message Table 41 defines the reference control parameter of the SELECT command message: b8 0 b7 0 b6 0 b5 0 b4 0 1 0 0 Select by name b3 b2 b1 Meaning Value Table 41: SELECT Command Reference Control Parameter Table 42 defines the selection options P2 of the SELECT command message: b8 b7 b6 b5 b4 b3 b2 0 1 b1 0 0 Meaning First or only occurrence Next occurrence Table 42: SELECT Command Options Parameter 11.

issuer. Table 44.3.4 Data Field Returned in the Response Message The data field of the response message contains the FCI specific to the selected PSE. Data elements present in templates '6F' and/or 'BF0C' that are not expected or understood by the terminal because the terminal does not support any issuer-specific processing shall be ignored. No additional data elements shall be present in the FCI template (tag '6F') returned in the response to the SELECT command other than those contained in template 'BF0C'. and Table 45 apply to this specification. or EMV-defined tags that are specifically allocated to 'BF0C' Value Presence M M M M O O O O Table 43: SELECT Response Message Data Field (FCI) of the PSE June 2008 Page 131 . Annex B) 1 or more additional proprietary data elements from an application provider. or ADF. The tags defined in Table 43.EMV 4. or IC card supplier. Table 43 defines the FCI returned by a successful selection of the PSE: Tag '6F' FCI Template '84' 'A5' DF Name FCI Proprietary Template '88' '5F2D' '9F11' 'BF0C' SFI of the Directory Elementary File Language Preference Issuer Code Table Index FCI Issuer Discretionary Data 'XXXX' (Tag constructed according to Book 3.2 Book 1 Application Independent ICC to Terminal Interface Requirements 11 Commands 11.3 SELECT Command-Response APDUs 11. DDF.

or IC card supplier. issuer.11 Commands 11.2 Book 1 Application Independent ICC to Terminal Interface Requirements Table 44 defines the FCI returned by a successful selection of a DDF: Tag '6F' FCI Template '84' 'A5' DF Name FCI Proprietary Template '88' 'BF0C' SFI of the Directory Elementary File FCI Issuer Discretionary Data 'XXXX' (Tag constructed according to Book 3. Annex B) 1 or more additional proprietary data elements from an application provider. or EMV-defined tags that are specifically allocated to 'BF0C' Value Presence M M M M O O Table 44: SELECT Response Message Data Field (FCI) of a DDF Page 132 June 2008 .3 SELECT Command-Response APDUs EMV 4.

June 2008 Page 133 . or IC card supplier. it is strongly recommended that the Application Label data element be included in the response message in order to facilitate cardholder choice/confirmation of the application to be used when a terminal employs the List of AIDs method for application selection.2 Book 1 Application Independent ICC to Terminal Interface Requirements 11 Commands 11. issuer. or EMV-defined tags that are specifically allocated to 'BF0C' Value Presence M M M O O O O O O O O O Table 45: SELECT Response Message Data Field (FCI) of an ADF Note: For multi-application ICCs.3 SELECT Command-Response APDUs Table 45 defines the FCI returned by a successful selection of an ADF: Tag '6F' FCI Template '84' 'A5' DF Name FCI Proprietary Template '50' '87' '9F38' '5F2D' '9F11' '9F12' 'BF0C' Application Label Application Priority Indicator PDOL Language Preference Issuer Code Table Index Application Preferred Name FCI Issuer Discretionary Data '9F4D' 'XXXX' (Tag constructed according to Book 3. Annex B) Log Entry 1 or more additional proprietary data elements from an application provider.EMV 4.

3 SELECT Command-Response APDUs EMV 4.11 Commands 11. the card shall select a different DF file matching the partial name. the terminal repeats the SELECT command having P2 set to the Next Occurrence option (see Table 42) and with the same partial DF name. it shall comply with the following:  If. repeating the same command again shall result in no file being selected.   Page 134 June 2008 . after a DF file has been successfully selected.5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command. However. but shall retrieve no file twice.2 Book 1 Application Independent ICC to Terminal Interface Requirements 11. Repeated issuing of the same command with no intervening application level commands shall retrieve all such files. ICC support for the selection of a DF file using only a partial DF name is not mandatory. if the ICC does support partial name selection. if such other DF file exists. and the card shall respond with SW1 SW2 = '6A82' (file not found). After all matching DF files have been selected.3.

there is no requirement to remove/reinsert the card between the sessions.1. the card contacts shall be deactivated before starting the EMV card session. If a proprietary processing session (including any proprietary application selection method) is performed immediately before or after an EMV card session. application selection using the commands and techniques described in sections 11 and 12 shall be the first process performed immediately after contact activation/reset of the card and prior to the first application function.1. This process is described in section 12. if proprietary processing occurs before the EMV card session. 2. it shall be performed outside the EMV card session as defined in section 6.2 Book 1 Application Independent ICC to Terminal Interface Requirements 12 Application Selection 12. June 2008 Page 135 .1. It is not recommended that the ICC and the terminal use implicit selection as defined in ISO 7816.3. (This list is referred to below using the name ‗candidate list. It specifies the logical structure of data and files within the card that are required for the process. The application selection process described in this section is the process by which the terminal uses data in the ICC according to protocols defined herein to determine the terminal program and the ICC application to be used in processing a transaction.1. This section of the specification describes the necessary information in the card and two terminal selection algorithms that yield the correct results.EMV 4.1 Overview of Application Selection During an EMV card session as defined in section 6. Other terminal selection algorithms that yield the same results are permitted in place of the selection algorithms described here. The process is described in two steps: 1. then describes the terminal logic using the card structure. Select the application to be run from the list generated above.4. This section describes the application selection process from the standpoint of both the card and the terminal. as it is not useful in an interchange environment. Create a list of ICC applications that are supported by the terminal. However.‘) This process is described in section 12. If used.

1).12 Application Selection 12.    The set of data that the ICC contains in support of a given application is defined by an ADF selected by the terminal using a SELECT command and an Application File Locator (AFL) returned by the ICC in response to a GET PROCESSING OPTIONS command. each representing a different type or level of service or a different account). Ability for terminals with a wide range of capabilities to work with all ICCs supporting payment system applications according to this specification. Ability for ICCs to provide multiple sets of applications to be supported by a single terminal program. Conformance with ISO standards. (For example. Page 136 June 2008 . Ability for the issuer to optimise the selection process. a card may contain multiple credit/debit applications. As far as possible. Minimum overhead in storage and processing. provide the capability for applications conforming with this specification to co-reside on cards with presently existing applications.1 Overview of Application Selection EMV 4. The techniques chosen by the payment systems and described herein are designed to meet the following key objectives:      Ability to work with ICCs with a wide range of capabilities. Ability of ICCs to support multiple applications.2.2 Book 1 Application Independent ICC to Terminal Interface Requirements A payment system application is comprised of the following:    A set of files in the ICC providing data customised by the issuer Data in the terminal provided by the acquirer or the merchant An application protocol agreed upon by both the ICC and the terminal Applications are uniquely identified by AIDs conforming to ISO/IEC 7816-4 (see section 12. not all of which need to be payment system applications.

2 Data in the ICC Used for Application Selection 12.2 Book 1 Application Independent ICC to Terminal Interface Requirements 12 Application Selection 12. A Registered Application Provider Identifier (RID) of 5 bytes.EMV 4. An optional field assigned by the application provider of up to 11 bytes. Compliance with ISO/IEC 7816-4 will assure this avoidance. This field is known as a Proprietary Application Identifier Extension (PIX) and may contain any 0–11 byte value specified by the provider.1 Coding of Payment System Application Identifier The structure of the AID is according to ISO/IEC 7816-4 and consists of two parts: 1.2. Additional ADFs defined under the control of other application providers may be present in the ICC but shall avoid duplicating the range of RIDs assigned to payment systems. June 2008 Page 137 . unique to an application provider and assigned according to ISO/IEC 7816-4.2 Data in the ICC Used for Application Selection 12. The meaning of this field is defined only for the specific RID and need not be unique across different RIDs. 2.

3.2 will encounter the values specified in the FCI of the PSE and will not see the values specified in the FCI of the ADF until the application to be run has been chosen. If either data element is present in both locations but has different values in the two locations. The directory may also contain entries for other payment system‘s DDFs. if the PSE exists. The FCI of this DDF shall contain at least the information defined for all DDFs in section 11 and. the Language Preference (tag '5F2D') and the Issuer Code Table Index (tag '9F11').2 Structure of the PSE The PSE begins with a DDF given the name ‗1PAY. If it is present.SYS. the terminal shall use the data element that is present. although the applications defined by those ADFs may or may not conform to this specification.12 Application Selection 12.2 Data in the ICC Used for Application Selection EMV 4.9 The directory attached to this initial DDF contains entries for ADFs that are formatted according to this specification. the values must be the same. As with all DDFs. A terminal building the candidate list using the process described in section 12. and following the chain of DDFs may not reveal all applications supported by the card. it shall comply with this specification. if present. The Language Preference and Issuer Code Table Index are optional data objects that may occur in two places: the FCI of the PSE and the FCI of ADF files. See Annex C for examples of the internal logic structure of an ICC containing the PSE. 9 A terminal building a candidate list using the process described in section 12. However.2 Book 1 Application Independent ICC to Terminal Interface Requirements 12. only applications that are revealed by following the chain of DDFs beginning with the initial directory can be assured of international interoperability. this DDF shall contain a Payment System Directory.3.2. which shall conform to this specification. To ensure consistent interface to the cardholder. this DDF is mapped onto a DF within the card. Page 138 June 2008 . optionally. the terminal may use either value. which may or may not be the MF. The directory is not required to have entries for all DDFs and ADFs in the card. If either of these data elements is present in one location but not the other.DDF01‘. The presence of this DDF in the ICC is optional but.3 will encounter the values specified in the FCI of the ADFs.

but a single entry shall always be encapsulated in a single record. The SFI for the Payment System Directory is contained in the FCI of the DDF to which the directory is attached. Annex B) Value DDF Name Directory Discretionary Template var. and the value field is comprised of one or more directory entries as described below. 10 June 2008 Page 139 . Each record is formatted as shown in Table 46: Tag '70' Data Length (L) Tag '61' Length of directory entry 1 Directory entry 1 (ADF or DDF) . No additional data elements shall be present in the Payment System Directory Record (tag ‗70‘) other than those contained in template ‗73‘.2 Book 1 Application Independent ICC to Terminal Interface Requirements 12 Application Selection 12. or IC card supplier. A record may have several entries.2 Data in the ICC Used for Application Selection 12. issuer. Tag '61' Length of directory entry n Directory entry n (ADF or DDF) Table 46: Payment System Directory Record Format Each entry in a Payment System Directory is the value field of an Application Template (tag '61') and contains the information according to Table 47 or Table 48. or EMV-defined tags that are specifically allocated to template '73' Presence M O 10 O 'XXXX' Table 47: DDF Directory Entry Format Other data objects not relevant to this specification may appear in this constructed data object. Tag '9D' '73' Length 5–16 var... (Tag constructed according to Book 3. shall be ignored. template '61'. The Payment System Directory is read using the READ RECORD command as defined in section 11.3 Coding of a Payment System Directory A Payment System Directory is a linear EF file identified by a SFI in the range 1 to 10. Each record in the Payment System Directory is a constructed data object.2. Data elements present in the Payment System Directory Record.EMV 4. 1 or more additional proprietary data elements from an application provider. or template '73' that are not expected or understood by the terminal because the terminal does not support any issuer-specific processing.

or EMV-defined tags that are specifically allocated to template '73' Presence M M O O O 11 O 'XXXX' Table 48: ADF Directory Entry Format b8 1 0 b7–b5 b4–b1 Definition Application cannot be selected without confirmation of cardholder Application may be selected without confirmation of cardholder xxx 0000 xxxx (except 0000) RFU No priority assigned Order in which the application is to be listed or selected. ranging from 1–15. 1 or more additional proprietary data elements from an application provider. or IC card supplier. 11 Page 140 June 2008 . Annex B) Value ADF Name Application Label Application Preferred Name Application Priority Indicator (see Table 49) Directory Discretionary Template var. issuer.12 Application Selection 12.2 Data in the ICC Used for Application Selection EMV 4. (Tag constructed according to Book 3.2 Book 1 Application Independent ICC to Terminal Interface Requirements Tag '4F' '50' '9F12' '87' '73' Length 5–16 1–16 1–16 1 var. with 1 being highest priority Table 49: Format of Application Priority Indicator Other data objects not relevant to this specification may appear in this constructed data object.

3 for a description of the SELECT command).3 must be followed. Application Preferred Name. If these data elements are present in the FCI. the terminal shall disregard these errors and act as if the response provided by the card did not contain these data elements. More specifically.2. June 2008 Page 141 . The terminal may know other ways that are not described in this section to locate proprietary applications or to eliminate specific applications in the ICC from consideration.2. it shall treat the data element as not present.2 Book 1 Application Independent ICC to Terminal Interface Requirements 12 Application Selection 12. as described in section 12. If the terminal does not understand the value in Issuer Code Table Index or Language Preference. 12. This section describes two procedures for determining which of those applications is to be run. The SFI shall be valid for reading the directory when the DDF containing the directory is the current file selected. Otherwise.3. have the same format.3.3 Building the Candidate List 12. the issuer is responsible for their correct encoding. The low order five bits of the Directory SFI contain the SFI to be used in READ RECORD commands for reading the directory. if the terminal detects format errors in any of these data elements. or if the terminal is unable to display the invalid character. Terminals shall not enforce the correct formatting of these data elements. 12.5 Error Handling for FCI Response Data The data elements Application Label. If the card contains no PSE. Issuer Code Table Index. All directories. Each directory is located by a Directory SFI data object which must be contained in the FCI of the DDF (see section 11.4 Coding of Other Directories Each directory in an ICC is contained by a separate DDF. the terminal shall display the character if it is able to. If Application Preferred Name or Application Label contains a character that is not valid for the defined format.2.EMV 4. and when present there is no defined limit to the number that may exist. including the initial directory.3 Building the Candidate List The terminal shall maintain a list of applications supported by the terminal and their AIDs. the terminal shall not terminate the card session but shall proceed with application selection. DDFs and directories in the card are optional. This is permitted as long as all interoperable applications can be located in the ICC using the techniques described here. and Language Preference are present for the convenience of the cardholder and are not critical to the successful processing of application selection. it should omit the character or substitute a space character or any other appropriate character. the procedure described in section 12.

If the ICC has multiple ADFs supported by a single terminal AID.3.3.5 (see SELECT command). This allows the ICC to have multiple ADFs matching the terminal application by adding unique information to the AID used by each of the ADFs. the terminal supports the ICC application if the AID in the ICC begins with the entire AID kept within the terminal. In some cases.3 Building the Candidate List EMV 4. For each of the AIDs within the list of applications supported by the terminal.1 Matching Terminal Applications to ICC Applications The terminal determines which applications in the ICC are supported by comparing the AIDs for applications in the terminal with AIDs for applications within the ICC. If the card has only one ADF matching the terminal AID. Page 142 June 2008 . In other cases. This case limits the ICC to at most one matching ADF. the terminal shall keep an indication of which matching criterion to use. the following requirements must be met by the ICC:   The ICC must support partial name selection as described in section 11.2 Book 1 Application Independent ICC to Terminal Interface Requirements 12.12 Application Selection 12. None of the ICC AIDs shall be the same length as the AID in the terminal. All of the matching AIDs in the ICC must be distinguished by adding unique data to the PIX. it should identify that ADF with the exact AID known to the terminal. the terminal supports the ICC application only if the AID in the terminal has the same length and value as the AID in the ICC.

3. the terminal shall use the List of AIDs method described in section 12. If the ICC returns SW1 SW2 = '9000'. The terminal begins by selecting the PSE using a SELECT command as described in section 11 and a file name of ‗1PAY. Figure 17 is a flow diagram of the logic described here. no directory entries exist. including a SW1 SW2 different from '90 00' or '6A 83'. the ICC shall return '6A82' (‗File not found‘) in response to the SELECT command for the PSE. 2. the terminal proceeds to the next directory record.3. In this case. June 2008 Page 143 . and step 6 (below) applies.3 to find the matching applications. In this case.3. it shall follow the procedure described in this section to determine the applications supported by the card.3. the terminal shall clear the candidate list and restart the application selection process using the List of AIDs method described in section 12.3.3. which indicates that the record number requested does not exist. If the card returns any other value in SW1 SW2. If the card returns SW1 SW2 = '6A83' in response to a READ RECORD for record number 1 for the Payment System Directory. the ICC shall return '6283'.3. For each record in the Payment System Directory. If any error. (The card shall return '6A83' if the record number in the READ RECORD command is greater than the number of the last record in the file). If there is no PSE in the ICC.3.2 Book 1 Application Independent ICC to Terminal Interface Requirements 12 Application Selection 12. the terminal begins with the first directory entry and processes each directory entry in turn as described in steps 3 through 5. If the PSE is blocked.3 Building the Candidate List 12. The terminal performs the following steps: 1. If the card is blocked or the SELECT command is not supported (both conditions represented by SW1 SW2 = '6A81'). the terminal terminates the session. This establishes the PSE and makes the initial Payment System Directory accessible. occurs in steps 2 through 5. the terminal shall use the List of AIDs method described in section 12.DDF01‘.SYS.2 Using the PSE If a terminal chooses to support application selection using the PSE method. The terminal uses the Directory SFI from the FCI returned and reads all the records in the Payment System Directory beginning with record number 1 and continuing with successive records until the card returns SW1 SW2 = '6A83'. the terminal proceeds to step 2. If there are no directory entries in the record.EMV 4. the terminal shall use the List of AIDs method described in section 12.

1. If the entry is for an ADF and the ADF name matches one of the applications supported by the terminal as defined in section 12. The new directory is read and processed according to steps 2 through 5. all ADFs that can be found by this procedure have been determined. If steps 1 through 5 yield no directory entries that match applications supported by the terminal.4. The application is added to the candidate list in either of the following cases:   the AID entry retrieved is an exact match. and selects the DDF indicated using the DDF name.3. When the terminal finishes processing all entries in the last record of the Payment System Directory. 4. If the entry is for a DDF. the terminal continues processing as described in section 12.12 Application Selection 12.3.2 Book 1 Application Independent ICC to Terminal Interface Requirements 3. after which the terminal resumes processing the previously interrupted directory at the point of interruption. the terminal shall use the list of AIDs method described in section 12. 6. places resumption information on the stack. the application joins the candidate list for final application selection under control of the Application Selection Indicator (ASI) maintained in the terminal for that AID.3 Building the Candidate List EMV 4. or the ASI for the AID in the terminal indicates that a partial match is allowed. The search and the candidate list are complete. The ASI indicates whether the AID in the terminal shall match exactly (both in length and name) or need only partially match the associated ADF name in the card (tag '4F'). 5. Page 144 June 2008 . If at least one matching AID was found. The application is not added to the candidate list if the ADF entry retrieved is not an exact match and the ASI for the AID in the terminal indicates that an exact match is required.3 to find a match. the terminal interrupts processing of the current directory record.

Choose application from candidate list.DDF01' No Terminate Session Yes SW1 SW2 = '6A81' ? No PSE Found? Yes PSE Blocked? No Empty candidate list Yes No Selection from terminal list See “Using a List of AIDs” in next section Get SFI for directory from FCI Set record number for read to 1 Interrupt current directory & place resumption information on stack Read directory record No Get DDF name from entry Record found? Yes No Is there an entry on the directory stack? Yes No Are there any entries on the candidate list? Yes Select new DDF Is there an entry in this record? Yes Terminal supports application? Yes ADF is exact match of AID? No Check terminal‟s Application Selection Indicator Yes No Yes Is entry for an ADF? No Get first entry from record No Get previous directory entry from stack Candidate list is complete.EMV 4. it is performed prior to this step.3 Building the Candidate List Begin Application Selection If the terminal and card support implicit selection as defined by ISO 7816-4. Terminal Supports PSE? Yes Select DFNAME = '1PAY. Resume processing previous directory Is there another entry in this record? Yes No Increment record number for next read by 1 Partial match allowed? Yes Add to candidate list No Get next entry Figure 17: Terminal Logic Using Directories June 2008 Page 145 .2 Book 1 Application Independent ICC to Terminal Interface Requirements 12 Application Selection 12.SYS.

If there are no more AIDs in the list. If the application is blocked (SW1 SW2 = '6283').3. If the SELECT command fails because the card is blocked or the command is not supported by the ICC (SW1 SW2 = '6A81'). If the SELECT command is successful (SW1 SW2 = '9000').3 Building the Candidate List EMV 4. and DF Name is used for the application identifier in the card. Figure 18 is a flow diagram of the logic described here. 4. the card processed the command as a partial name selection. the term AID is used for the application identifier kept in the terminal. As can be seen in section 12. and the terminal proceeds to step 6. 3. If the card returns any other status or if mandatory data is missing from the SELECT response or if the FCI contains formatting errors not described in Section 12. the candidate list is complete. The terminal performs the following steps: 1. 13 The Application Label and Application Preferred Name must also be saved if the cardholder will be provided a list during final selection. it is necessary to distinguish between the AID kept in the terminal and the AID kept in the ICC. 5. The DF Name will either be identical to the AID (including the length). the terminal adds the FCI information from the selected file to the candidate list 13 and proceeds to step 5. the terminal terminates the card session. If the names are identical. the terminal compares the AID with the DF Name field returned in the FCI. and the terminal proceeds as specified in section 12.5. the terminal proceeds to Step 5 without adding the DF Name to the candidate list. 12 in the 2. the terminal shall use a list of AIDs that it supports to build the candidate list.2 Book 1 Application Independent ICC to Terminal Interface Requirements 12.4. If the SELECT command is successful (SW1 SW2 = '9000' or '6283').3. 12 To assist in a clear understanding of the process described in this section. the terminal proceeds to step 5 without adding the DF Name to the candidate list. In this procedure. Page 146 June 2008 . The terminal issues another SELECT command using the next AID in its list and returns to step 3. the terminal proceeds with step 4. these might not be identical even for matching applications.2.1. The DF Name and the Application Priority Indicator will be required in any case. The terminal issues a SELECT command using the first AID terminal list as the file name. If the DF Name is longer.3 Using a List of AIDs If either the card or the terminal does not support the PSE method or if the terminal is unable to find a matching application using the Payment System Directory selection method. or the DF Name will start with the AID but will be longer.12 Application Selection 12.

June 2008 Page 147 . If multiple occurrences are permitted but the application is blocked (SW1 SW2  '9000'). '62xx'.3 Building the Candidate List 6. 7.EMV 4. or '63xx'. the terminal proceeds to step 7 without adding the FCI information to the candidate list. Along with the AID list.2 Book 1 Application Independent ICC to Terminal Interface Requirements 12 Application Selection 12. but changes P2 in the command to '02' (Select Next). the partial name match is sufficient. the terminal goes to step 5. If the application is not blocked (SW1 SW2 = '9000'). the terminal adds the FCI information to the candidate list and proceeds to step 7. If the indicator says that an exact match (in both length and name) is required. the terminal returns to step 3. If multiple occurrences are permitted. but proceeds to step 5. The terminal repeats the SELECT command using the same command data as before. If it returns a different SW1 SW2. If the ICC returns SW1 SW2 = '9000'. the terminal does not add the file to the candidate list. the terminal keeps an Application Selection Indicator that indicates whether the card may have multiple occurrences of the application within the card. The terminal checks this indicator.

3 Building the Candidate List EMV 4. 62xx. including length DFname in FCI = AID? Application blocked? No Add FCI information to candidate list Yes No Check Application Selection Indicator in terminal Is there another AID in list? No Finished. Go to final selection Yes Get next AID from list Partial name match allowed? No SELECT File using DF name = AID Yes Application blocked? Yes No Add FCI information to candidate list SELECT NEXT with DF name = terminal AID Yes SW1 SW2 = 9000.2 Book 1 Application Independent ICC to Terminal Interface Requirements Begin Application Selection Empty candidate list Get first AID from terminal list SELECT File using DF name = AID SW1 SW2 = '6A81' ? No Yes Terminate Session File found including all mandatory data? Yes Yes No Must be identical. or 63xx No Figure 18: Using the List of AIDs in the Terminal Page 148 June 2008 .12 Application Selection 12.

applications prohibiting such selection (b8 = '1' in the Application Priority Indicator) shall be excluded from possible selection.4 Final Selection 12. 4.EMV 4. unless the terminal has its own preferred order.2 Book 1 Application Independent ICC to Terminal Interface Requirements 12 Application Selection 12. The same applies where duplicate priorities are assigned to multiple applications or individual entries are missing the Application Priority Indicator. 2. If there is only one mutually supported application. the terminal requests confirmation and selects the application if the cardholder approves. the terminal may offer a selection to the cardholder as described in step 4. 5. that is. the terminal selects the application. The terminal may select the application without cardholder assistance. 3. in this case. or if the terminal requests confirmation and the cardholder does not approve. In this case.4 Final Selection Once the terminal determines the list of mutually supported applications. Step 4 is the preferred method.   If b8 = '0'. the terminal checks b8 of the Application Priority Indicator for that application if present. If b8 = '1' and the terminal provides for confirmation by the cardholder. the terminal terminates the session. or make the selection itself as described in step 5. except that if the terminal does not provide for confirmation of the selected application. it shall be in priority sequence. the terminal may use its own preferred order or display the duplicate priority or non-prioritised applications in the order encountered in the card. If there are no mutually supported applications. the list should be in the order in which the applications were encountered in the card. with the highest priority application listed first. If the terminal does not provide for confirmation by the cardholder. If multiple applications are supported. June 2008 Page 149 . the terminal shall select the highest priority application from the list of mutually supported applications. it proceeds as follows: 1. If a list is presented to the cardholder. If there is no priority sequence specified in the card. the transaction is terminated.

no application is to be selected without cardholder confirmation. If the cardholder selects or confirms the selection of an application that is subsequently removed from the candidate list due to its being blocked or for any other reason. the terminal shall inform the cardholder of the action taken. and processing shall resume at step 1.12 Application Selection 12. if appropriate. If the command returns other than '9000' in SW1 SW2 or the SELECT response contains format errors other than those described in section 12.2 Book 1 Application Independent ICC to Terminal Interface Requirements Once the application to be run is determined by the terminal or by the cardholder. the application shall be removed from the candidate list.5. the application shall be selected. Page 150 June 2008 .4 Final Selection EMV 4. In any case. A SELECT command coded according to section 11 shall be issued by the terminal for the application using the ADF Name field (if the directories were read) or the DF Name field from the FCI (if the List of AIDs method was used) found during the building of the candidate list.2.

4 Final Selection June 2008 Page 151 .2 Book 1 Application Independent ICC to Terminal Interface Requirements 12 Application Selection 12.EMV 4.

.

2 Book 1 Application Independent ICC to Terminal Interface Requirements Part IV Annexes June 2008 Page 153 .EMV 4.

2 Book 1 Application Independent ICC to Terminal Interface Requirements Page 154 June 2008 .EMV 4.

ICC June 2008 Page 155 . Note the following:    The use of procedure bytes '60' and INS is not illustrated. Sections A5 and A6 illustrate the more extensive use of procedure bytes '61 xx' when used with case 2 and 4 commands.2 Book 1 Application Independent ICC to Terminal Interface Requirements Annex A Examples of Exchanges Using T=0 The following examples illustrate exchanges of data and procedure bytes between the TTL and ICC. A1 Case 1 Command A C-APDU of {CLA INS P1 P2} is passed from the TAL to the TTL (note that P3 of the C-TPDU is set to '00').EMV 4. [Data(x)] means x bytes of data. Sections A1 to A4 illustrate typical exchanges using case 1 to 4 commands. Section A7 illustrates a warning condition with a case 4 command. TTL [CLA INS P1 P2 00]   90 00 A R-APDU of {90 00} is returned from the TTL to the TAL. Case 2 and 4 commands have Le = '00' requesting the return of all data from the ICC up to the maximum available. Le = '00' is used in these examples to illustrate typical exchanges that may be observed when executing the application specified in Book 3. Le may take other values when executing a proprietary application.

TTL [CLA INS P1 P2 00]   6C Licc [CLA INS P1 P2 Licc]   INS [Data(Licc)] 90 00 A R-APDU of {[Data(Licc)] 90 00} is returned from the TTL to the TAL. ICC Page 156 June 2008 .2 Book 1 Application Independent ICC to Terminal Interface Requirements A2 Case 2 Command A C-APDU of {CLA INS P1 P2 00} is passed from the TAL to the TTL. TTL [CLA INS P1 P2 Lc]   INS [Data(Lc)]   90 00 A R-APDU of {90 00} is returned from the TTL to the TAL.Annex A Examples of Exchanges Using T=0 EMV 4. ICC A3 Case 3 Command A C-APDU of {CLA INS P1 P2 Lc [Data(Lc)]} is passed from the TAL to the TTL.

ICC June 2008 Page 157 .2 Book 1 Application Independent ICC to Terminal Interface Requirements Annex A Examples of Exchanges Using T=0 A4 Case 4 Command A C-APDU of {CLA INS P1 P2 Lc [Data (Lc)] 00} is passed from the TAL to the TTL. ICC A5 Case 2 Command Using the '61' and '6C' Procedure Bytes A C-APDU of {CLA INS P1 P2 00} is passed from the TAL to the TTL. TTL [CLA INS P1 P2 Lc]   [INS] [Data(Lc)]   61 Licc [00 C0 00 00 Licc]   C0 [Data(Licc)] 90 00 A R-APDU of {[Data(Licc)] 90 00} is returned from the TTL to the TAL.EMV 4. TTL [CLA INS P1 P2 00]   6C Licc [CLA INS P1 P2 Licc]   61 xx [00 C0 00 00 yy]   C0 [Data(yy)] 61 zz [00 C0 00 00 zz]   C0 [Data(zz)] 90 00 Where yy  xx A R-APDU of {[Data(yy + zz)] 90 00} is returned from the TTL to the TAL.

TTL [CLA INS P1 P2 Lc]   [INS] [Data(Lc)]   61 xx [00 C0 00 00 xx]   C0 [Data(xx)] 61 yy [00 C0 00 00 yy]   C0 [Data(yy)] 90 00 A R-APDU of {[Data(xx + yy)] 90 00} is returned from the TTL to the TAL. TTL [CLA INS P1 P2 Lc]   [INS] [Data(Lc)]   62 xx [00 C0 00 00 00]   6C Licc [00 C0 00 00 Licc]   C0 [Data(Licc)] 90 00 A R-APDU of {[Data(Licc)] 62 xx} is returned from the TTL to the TAL containing the data returned together with the warning status bytes. ICC Page 158 June 2008 . ICC A7 Case 4 Command with Warning Condition A C-APDU of {CLA INS P1 P2 Lc [Data Lc] 00} is passed from the TAL to the TTL.Annex A Examples of Exchanges Using T=0 EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements A6 Case 4 Command Using the '61' Procedure Byte A C-APDU of {CLA INS P1 P2 Lc [Data Lc] 00} is passed from the TAL to the TTL.

B1 Data Elements by Name Name Application Identifier (AID) card Application Identifier (AID) terminal Description Identifies the application as described in ISO/IEC 7816-4 Identifies the application as described in ISO/IEC 7816-4 Source ICC Format b Template '61' Tag '4F' Length 5–16 Terminal b — '9F06' 5–16 Table 50: Data Elements Table 14 Annex A of Book 3 provides a complete data elements table.3.14 Table 51 lists the data elements in tag sequence.2 Book 1 Application Independent ICC to Terminal Interface Requirements Annex B Data Elements Table Table 50 defines those data elements that may be used for application selection and their mapping onto data objects and files. June 2008 Page 159 . The characters used in the ―Format‖ column are described in section 4. Data Element Format Convention. defining all data elements that may be used for financial transaction interchange and their mapping onto data objects and files.EMV 4.

3) b Template '61' or 'A5' Tag '50' Length 1–16 Application Preferred Name Application Priority Indicator Application Selection Indicator Preferred mnemonic associated with the AID Indicates the priority of a given application or group of applications in a directory For an application in the ICC to be supported by an application in the terminal. including the length of the AID. or only up to the length of the AID in the terminal There is only one Application Selection Indicator per AID supported by the terminal Contains one or more data objects relevant to an application directory entry according to ISO/IEC 7816-4 ICC ICC '61' or 'A5' '61' or 'A5' '9F12' '87' 1–16 1 Terminal At the discretion of the terminal. up to 252 Table 50: Data Elements Table. continued June 2008 Page 160 .2 Book 1 Application Independent ICC to Terminal Interface Requirements Annex B Data Elements Table B1 Data Elements by Name Name Application Label Description Mnemonic associated with the AID according to ISO/IEC 7816-4 Source ICC Format ans with the special character limited to space ans (see section 4. The data is not sent across the interface — — See Format Application Template ICC b '70' '61' var.EMV 4. the Application Selection Indicator indicates whether the associated AID in the terminal must match the AID in the card exactly.

up to 222 ICC var. up to 252 var. Identifies the FCI template according to ISO/IEC 7816-4 ICC var.2 Book 1 Application Independent ICC to Terminal Interface Requirements Annex B Data Elements Table B1 Data Elements by Name Name Bank Identifier Code (BIC) Dedicated File (DF) Name Directory Definition File (DDF) Name Directory Discretionary Template File Control Information (FCI) Issuer Discretionary Data File Control Information (FCI) Proprietary Template File Control Information (FCI) Template Description Uniquely identifies a bank as defined in ISO 9362. b b Template 'BF0C' or '73' '6F' '61' Tag '5F54' '84' '9D' Length 8 or 11 5–16 5–16 ICC var. continued June 2008 Page 161 . 'A5' 'BF0C' Identifies the data object proprietary to this specification in the FCI template according to ISO/IEC 7816-4 ICC var.EMV 4. up to 252 Table 50: Data Elements Table. '6F' 'A5' var. — '6F' var. '61' '73' var. Identifies the name of the DF as described in ISO/IEC 7816-4 Identifies the name of a DF associated with a directory Issuer discretionary part of the directory according to ISO/IEC 7816-4 Issuer discretionary part of the FCI Source ICC ICC ICC Format var.

Indicates the code table according to ISO/IEC 8859 for displaying the Application Preferred Name Indicates the country of the issuer as defined in ISO 3166 (using a 2 character alphabetic code) Indicates the country of the issuer as defined in ISO 3166 (using a 3 character alphabetic code) The number that identifies the major industry and the card issuer and that forms the first part of the Primary Account Number (PAN) The URL provides the location of the issuer‘s Library Server on the Internet Source ICC Format var.EMV 4. continued June 2008 Page 162 . Template 'BF0C' or '73' 'A5' Tag '5F53' Length Var. Table 50: Data Elements Table.2 Book 1 Application Independent ICC to Terminal Interface Requirements Annex B Data Elements Table B1 Data Elements by Name Name International Bank Account Number (IBAN) Issuer Code Table Index Issuer Country Code (alpha2 format) Issuer Country Code (alpha3 format) Industry Identification Number (IIN) Issuer URL Description Uniquely identifies the account of a customer at a financial institution as defined in ISO 13616. up to 34 1 ICC n2 '9F11' ICC a2 'BF0C' or '73' 'BF0C' or '73' 'BF0C' or '73' '5F55' 2 ICC a3 '5F56' 3 ICC n6 '42' 3 ICC ans 'BF0C' or '73' '5F50' var.

2 Book 1 Application Independent ICC to Terminal Interface Requirements Annex B Data Elements Table B1 Data Elements by Name Name Language Preference Description 1–4 languages stored in order of preference. but may use template '70'.) Identifies the AEF referenced in commands related to a given ADF or DDF. ICC ICC b b 'BF0C' or '73' 'A5' '9F4D' '9F38' 2 var. Response messages for SFIs 11-30 are outside the scope of EMV. each represented by 2 alphabetical characters according to ISO 639 Note: EMVCo strongly recommends that cards be personalised with data element '5F2D' coded in lowercase. — '70' var. It is a binary data object having a value in the range 1 – 30 and with the three high order bits set to zero. up to 252 ICC b 'A5' '88' 1 Table 50: Data Elements Table.EMV 4. continued June 2008 Page 163 . ICC var. but that terminals accept the data element whether it is coded in upper or lower case. (Mandatory for SFIs 1-10. Source ICC Format an 2 Template 'A5' Tag '5F2D' Length 2–8 Log Entry Processing Options Data Object List (PDOL) READ RECORD Response Message Template Short File Identifier (SFI) Provides the SFI of the Transaction Log file and its number of records Contains a list of terminal resident data objects (tags and lengths) needed by the ICC in processing the GET PROCESSING OPTIONS command Contains the contents of the record read.

card to terminal). the following rules apply:   A data element in format n is right justified and padded with leading hexadecimal zeroes. When data is moved from one entity to another (for example. A data element in format a. June 2008 Page 164 . regardless of how it is internally stored. it shall always be passed in order from high order to low order.2 Book 1 Application Independent ICC to Terminal Interface Requirements Annex B Data Elements Table B1 Data Elements by Name When the length defined for the data object is greater than the length of the actual data.EMV 4. or ans is left justified and padded with trailing hexadecimal zeroes. The same rule applies when concatenating data. an.

card Application Label Language Preference Issuer URL International Bank Account Number (IBAN) Bank Identifier Code (BIC) Issuer Country Code (alpha2 format) Issuer Country Code (alpha3 format) Application Template File Control Information (FCI) Template READ RECORD Response Message Template Directory Discretionary Template Dedicated File (DF) Name Application Priority Indicator Short File Identifier (SFI) Directory Definition File (DDF) Name Application Identifier (AID) .EMV 4.terminal Issuer Code Table Index Application Preferred Name Processing Options Data Object List (PDOL) Log Entry File Control Information (FCI) Proprietary Template File Control Information (FCI) Issuer Discretionary Data Table 51: Data Elements Tags Template 'BF0C' or '73' '61' '61' or 'A5' 'A5' 'BF0C' or '73' 'BF0C' or '73' 'BF0C' or '73' 'BF0C' or '73' 'BF0C' or '73' '70' — — '61' '6F' '61' or 'A5' 'A5' '61' — 'A5' '61' or 'A5' 'A5' 'BF0C' or '73' '6F' 'A5' Tag '42' '4F' '50' '5F2D' '5F50' '5F53' '5F54' ‗5F55‘ '5F56' '61' '6F' '70' '73' '84' '87' '88' '9D' '9F06' '9F11' '9F12' '9F38' '9F4D' 'A5' 'BF0C' June 2008 Page 165 .2 Book 1 Application Independent ICC to Terminal Interface Requirements Annex B Data Elements Table B2 Data Elements by Tag B2 Data Elements by Tag Name Industry Identification Number (IIN) Application Identifier (AID) .

Annex B Data Elements Table B2 Data Elements by Tag EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements Page 166 June 2008 .

C1 Single Application Card Figure 19 illustrates a single application card with only a single level directory.2. but it shall conform to this specification. The MF shall be given the unique payment system‘s name assigned to the first level DDF as defined in section 12.2 Book 1 Application Independent ICC to Terminal Interface Requirements Annex C Examples of Directory Structures This annex illustrates some possible logical ICC file structures. including the requirement that it has a SFI in the range 1 to 10. as defined by ISO/IEC 7816-4) acts as the only DDF in the card. MF DIR A ADF EF EF Figure 19: Simplest Card Structure Single Application June 2008 Page 167 . and the FCI of the MF shall contain the SFI data object. In this example. ‗DIR A‘ in this example may or may not be the ISO DIR file. the MF (with file identification of '3F00'.EMV 4.

According to ISO/IEC 7816-4. The manner in which the terminal finds ADF5 is outside the scope of this specification. ADF5 can be selected only by a terminal that ‗knows‘ ADF5 may exist in the card. the root file (MF) does not support an application complying with this specification. Also note that the directory does not have entries for all ADFs (ADF2 to ADF5). MF DDF1 DIR A ADF 2 EF EF ADF 3 ADF 4 ADF 5 EF EF EF EF EF Figure 20: Single Level Directory Page 168 June 2008 .Annex C Examples of Directory Structures EMV 4. and no restrictions are placed on the function of the MF. a DIR file may be present but is not used by the application selection algorithm defined in section 12. In this example.2 Book 1 Application Independent ICC to Terminal Interface Requirements C2 Single Level Directory Figure 20 gives an example of a multi-application card with a single directory. as ADF5 is omitted.

DDF5 has no entry in the root directory and can be found only by a terminal that ‗knows‘ of the existence of DDF5. The manner in which the terminal finds and selects DDF5 is outside the scope of this specification. attached to DDF6. may lead the terminal to ADFs such as DF51. is a third level directory and points to four files (not shown). The directory attached to DDF2 (‗DIR B‘) has entries for two ADFs  ADF21 and ADF22  and a single DDF  DDF6. The first level directory (‗DIR A‘) has entries for 2 ADFs  ADF3 and ADF4  and a single DDF  DDF2. DIR D. if found by the terminal. and DF53.2 Book 1 Application Independent ICC to Terminal Interface Requirements Annex C Examples of Directory Structures C3 Multi-Level Directory Figure 21 is an example of a multi-application card with an n level directory structure. but the directory attached to DF5 (‗DIR C‘) may conform to this specification. which may be either ADFs or more DDFs. and. DF52.EMV 4. MF DDF1 DIR A DDF 2 DIR B ADF 3 ADF 4 DDF 5 DIR C EF EF ADF 21 ADF 22 DDF6 DIR D EF EF EF EF EF ADF 51 ADF 52 ADF 53 EF EF Figure 21: Third Level Directory June 2008 Page 169 .

Annex C Examples of Directory Structures EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements Page 170 June 2008 .

2 Book 1 Application Independent ICC to Terminal Interface Requirements Part V Common Core Definitions June 2008 Page 171 .EMV 4.

EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements Page 172 June 2008 .

including the Common Core Definitions part of Books 2 and 3. card application behaviours. 3. accept cards implemented according to the Common Core Definitions. since the Common Core Definitions are supported within the existing EMV requirements. Terminals certified to be compliant with the existing EMV specifications will. to be used when implementing the Common Core Definitions (CCD). It is to be used in conjunction with Books 2. Changed Sections Each section heading below refers to the section in this Book to which the additional requirements apply. June 2008 Page 173 . an implementation shall implement all the additional requirements in the Common Core Definitions sections of all affected Books. in addition to the requirements already specified in the referenced section of EMV. and 4. To be compliant with the Common Core Definitions. without change. The text defines requirements for a common core implementation. These Common Core Definitions specify a minimum common set of card application implementation options. and data element definitions sufficient to accomplish an EMV transaction.2 Book 1 Application Independent ICC to Terminal Interface Requirements Common Core Definitions This Part describes an optional extension to this Book.EMV 4.

3. Commands.Files.Common Core Definitions EMV 4.1. and Application Selection 10 Files 10.2 Book 1 Application Independent ICC to Terminal Interface Requirements Part III .5 Processing State Returned in the Response Message The ICC shall support partial name selection and shall accept SELECT command messages containing at least the 5 high-order bytes of the DF name (that is. Select Next functionality shall be supported.4 Directory Structure The directory structure within the PSE shall not contain any optional additional directories introduced by a DDF. Page 174 June 2008 .3 SELECT Command-Response APDUs 11.1 File Structure 10. the RID). 11 Commands 11.

where DDF1 is ‗1PAY.. the highest level DDF. Tag '61' Length of directory entry n Directory entry n (ADF) Table CCD 1: Payment System Directory Record Format for CCD-Compliant Card June 2008 Page 175 .2.DDF01‘. No other DDFs shall be present.SYS.DDF01‘..3 Coding of a Payment System Directory A Payment System Directory Record shall contain only ADF entries.EMV 4.SYS. A graphic example of the internal logic structure of a CCD-compliant card can be found in Appendix C.2 Book 1 Application Independent ICC to Terminal Interface Requirements Common Core Definitions 12 Application Selection 12. Each record in the Payment System Directory shall be formatted as in Table CCD 1: Tag '70' Data Length (L) Tag '61' Length of directory entry 1 Directory entry 1 (ADF) . Figure 20. the PSE shall contain only one DDF.2 Data in the ICC Used for Application Selection 12. 12. DDF entries are not allowed. ‗1PAY.2 Structure of the PSE If the card has a PSE.2.

.........................................70 Basic ATR for T=1 Only...19 Abnormal Termination of Transaction Process .................................................................................................. See Application Elementary File AFL......... 74. 90...........................................................................................................................................................................................................72 Characters Returned by ICC .............................. 137 Application Selection Indicator ....................... 160 C C-APDU ..................................................... 126 Format .......................................................................91 Basic ATR .............................................................................................. 126 Structure ............... 103 Content ..................... 147 Assignment of Contacts ................................................................................95 Acknowledged .................................70 Character Definitions ..................................................98 Blocks.................................... 143 Using Data in ICC ..........................70 Flow at the Terminal .............................. 101 C-APDU ..................91 '6C' ........................................................ 141 Final Selection ................................. 39....................................... 126 Structures .................................. 143 ASI...............................................................................85 Physical Transportation of Characters Ret’d ......................... 149 List of AIDs Method ......................................................................................................................................................... 116 R-APDU ..............................................74 Character TA3 .........................................78 Character TD2 ................. 104 Accept an ATR ........ 141 BWI .............................. See ADF Application Elementary File .................... 87.................................................73 ACK . 70.............................................. 82.............................................. 103 Character .................. 139....65 ATR ..................................................................... 136 Answer to Reset ................................................... 100 Information Field Sizes and Timings ....................... 138......................................................72 Page 176 June 2008 ......... 101 Error Detection and Correction ..................... 121............. 101..... 101 BWT Time-out ....................83 Application Definition File ........................................................................ 136 AID ....................................... 121 Directory Entry Format .........................................................................93 Character Definitions ... ...................................71 Basic Response ..... 103 I-blocks ............ 116 Card Session Stages ..................... 144........ See Answer to Reset B ' '60' .......................................................................................... See AID Application Label ...91 ADF ....DDF01 ..72 Basic Response Coding Character T0 .............................. See Common Core Definitions Chaining............. 133.......... 94 Block Frame Structure ..................................94 Chaining ............................................................. 146 PSE Method .......................SYS........... 146 Application Layer .........................................76 Character TB3 ... 104 A Abbreviations ............................................................................................2 Book 1 Application Independent ICC to Terminal Interface Requirements Index 1 1PAY......... 135 Building Candidate List ....... 122..... 72 Basic ATR for T=0 Only.............................................95 Body.................... 104 Error Free Operation .................................................................... 140 Application Selection ........77 Character TD1 ........59 Cases for Data in APDUs........... ................. 99................................................................ Types ............. 115 CCD ................ 115 C-APDU ..................65 Bit Rate Adjustment Factor.....................................69 Basic..................................................... 101 Additional Work Waiting Time .........69 Terminal Behaviour ...................................................80 Bit Duration ............. 122...................................................................................................................................... 87.................. 149 Format ............................. 122 Application Identifier ........73 Block Protocol T=1 .................................81 Character TB1 ............. 127 Building Candidate List for Application Selection ................................................. 48 Asynchronous Half Duplex ................................................................... See ASI Application Template ............................................ 82 BWT ................................ 116 Chaining ................ ................64 Abort Request..82 Character TC1 .............. 117 Application Preferred Name........... 140 AEF......................................................................75 Bit Synchronisation .. 146 Application Priority Indicator .............................................Common Core Definitions EMV 4..........................91 '61' .........................

............54 I/O Current Limit ...............................................................................................................See etu June 2008 Page 177 ... 174 PSE Structure ............................................... 122 Direct Logic Convention ..................................................................46 Current Requirement...............92 Character Repetition ......................................................................................................................... 121 Data Element Format Conventions .90 Command Processing ............................42 Reset ....51 Electromechanical Interface ...............................................................75 Coding PCB of I-block ................44 Temperature Range ............. 122 Directory SFI ........................................................................................................................96 R-block ......... ICC .............................................48 VCC ....................................EMV 4................................................................................. 47 Resistance ....................................... 88 Character Frame ...83 CLA ............................ 139 Definitions ............... 89 Character Timing .......40 Clock ........54 VPP ...................... 115 Command Header ...................................40 VCC .. 97....................48 Layout.50 Powering and Depowering ............................ 155 Transportation of C-APDUs ... 159 Data in ICC Used for Application Selection ..................................................................................................................... 74.............................................................................................................. 167 Disputed Character ...................................................43 Terminal Electrical Characteristics .................................... 116 Classes of Operation ...............................................................................29 Data Elements Table ........................................... 87... Terminal ........................See CTPDU Command-Response Pair ............... ..........................90 Current etu ....................... 137 Data Link Layer ...................................... 39......................... 100 EDC Error .........48 Clock .........................................70 Check Character TCK...................... 38.....................................90 Command Data .......... 141 Directory Structure .................60 Assignment ..............................45 Clock ICC Electrical Characteristics.... 122 Examples ..............................65 Current Requirement ICC Electrical Characteristics............................................................................ 87............................. 173 Coding Payment System Directory......35 Elementary Time Unit ............75 DIR .................................................63 Force ................................41 I/O Transmission........... 88 Character Protocol T=0 .. 82 CWT ...................................................56 Temperature Range ......................................................... 97.........................................45 Terminal Electrical Characteristics . See DAD DF Name ..................................................................75 DDF ..89 Command Header . 146 DI .................. 46..................................................................................53 Short Circuit Resilience ................ 121......................................................................................................................................................42 Electrical Characteristics................ 56 C-TPDU ..57 Reset ...... 9 Destination Node Address .................52 Clock Rate Conversion Factor ...........................................45 I/O Reception ..................................................................... 127 Command Transport Protocol Data Unit..................................... 129 Command Application Protocol Data Unit..............................................45 VPP ....................................................................52 Contact Resistance ....93 Characters Returned by ICC at Answer to Reset ...................................................................................................2 Book 1 Application Independent ICC to Terminal Interface Requirements Character Frame ....96 Cold Reset ...........90 Example Exchanges .......................................................................................................................................................54 CWI ..............................51 I/O Transmission.............................................. 174 Conditional Body.................................61 Command READ RECORD........................................................... 127 SELECT .............................. 175 SELECT Command-Response APDUs .............................................................. 90.......... See DDF Directory Discretionary Template .....56 Current Requirement................88 Data Transfer Rates .................93 E EDC ..................................................................... 104 Electrical Characteristics...........................39 Location ....................................................................... 175 Directory Structure .....................................43 Contact Resistance ............. 66.......See CAPDU Command Class ...... 115 Common Core Definitions .. 114...........................................................49 I/O Reception ........................................................................................................................73 Directory Definition File ................................... 75 DAD.................................... 127 Command Processing Status (SW1) ............................................................................................................................................. 74......... 167 Directory Entry Format ................. ............ 87............................96 S-block ...............95 Data Byte ........................... 126 Contact Activation Sequence .....66 Data Element ..82 Index D D .. 48 Deactivation Sequence ................................ 175 Data in ICC Used for Application Selection ....................................90 Command Message Structure .................................................... 125 Command Processing Qualifier (SW2) .... 123....

........................................................... 94........ 121 Application Elementary Files .............37 ICC Clock. 56 Maximum Interval ...............41 ICC I/O Transmission .....................45 IFD Contact Assignment ........................................................... 50 I-block ..... 136 GET RESPONSE ...........37 Contact Assignment .....74 I/O Current Limit...................................................................... 101....... 100 Format Character T0 ............................ See LEN Length of Expected Data ............................................................................................. 116 INS ........................ 81......36 LRC .........73 Inverse .................... See TS Initial etu ....................... ................................................ TA1 to TC3................................................ 155 Extra Guardtime ..................................... 91.................. 91.................................................... 98.................................................................................... 98................................................. 82................ .................... 42..................... 112 Error Conditions .......................................... 101.............................................................................. 143... 104 Lower Voltage ICC Migration ..............................................................60 ICC Mechanical Characteristics ..................... ..................74 Invalid Block ........................... See I-block Initial Character .............................................................................49 I/O Reception .............. 114 Guardtime .............................. 61 ICC Temperature Range .. 97.............................. 74.............................75 File Referencing ................ 98 II ...... 142 Maximum Block Size ........97 Information block ...........................................................73 Issuer Code Table Index ........................Index EMV 4...............74 I I .................73 Longitudinal Redundancy Check .................................................................................................................. 54.......... ........................................ 126 Matching Applications ............ 75 FCI .................................................................................... 131 FI ................96 IC Module Height .................................................. 97 H Historical Bytes .. 126 LEN ............65 INS...........42 ICC Insertion and Contact Activation Sequence....................................................... 102 IFSD........ 97..................................74......................... 44........................... See LRC Loss of Synchronisation ..............................65 Even Parity Checking Bit ...................................................................38 Logic Convention Direct ............................... 104....................43 ICC Contact Assignment ...................................................................................... 108..............................................................................................66 L Language Preference .......40 ICC I/O Reception .................................................. 41...................................................93 Error Recovery .................................................. 123 File Structure............................2 Book 1 Application Independent ICC to Terminal Interface Requirements ICC Electrical Characteristics ................45 M Mandatory Header ..............................................................................83 Interface Characters..................39 Contact Layout ...................................................................... 100...........................................40 ICC VCC ................. 102 IFSI ........... 51 I/O Transmission .. 104 etu .....................39 Page 178 June 2008 ................74 G GET PROCESSING OPTIONS ..76 Implicit Selection................. See Le List of AIDs Method ..... 121 Application Definition Files .......... 146 Location of Contacts ..................91 Instruction Code .................................................39 Location ................................................ 122 FCI Template .................................................................39 Layout................................................................................................................. 115 Chaining .................90 Integrity.............46 ICC Current Requirement . 138 Error Detection and Correction for T=0 ................. 135 INF.... 122 Directory Structure ... 81.................................... 95..............................................77 F F ........................ 100............................................... .....................37 ICC Reset .................. 103 Coding PCB .......... 90.........39 Le ................................................. 167 Examples of Exchanges Using T=0 .................................. 100 Length ............................38 Resistance ...................................... 122 First Block Transmitted ............................................66 Exact Match ...................... ICC ................................................ 122 Mapping onto ISO/IEC 7816-4 ....................................99 Mechanical Characteristics..............................................................48 IFSC .........98 Maximum Current Pulse Envelope................................................................................................ 147 Examples of Directory Structures .................. 105. 138 Layout of Contacts .............. 104 Inverse Logic Convention.........................................

...................95 Negotiable Mode .......... 106 S(WTX Request) Block ............................................ 125 MF ................... 143 PTS ....................................................................... 105 Coding PCB ...... 137 Powering and Depowering ................................. 122 PCB ..................37 Modulo-2........................ 126.......................................................96 Scope ............................... 128 Command-Response APDUs .. 101 Coding PCB ................... 95.............................................................................................................................................. 3 June 2008 Page 179 ........................... 95 Physical Layer ... ans .................................79 PIX....................................... 139 Payment System Environment ............. 94.. 100 S(Response) block ............................................. See R-block References Normative ... 149 Mutually Supported Applications ...................47 Message Structure . See PIX Proprietary Data Elements ...... 108 Normative References ................................... 127 Command Message ...... 127 Receive-ready block ............................................................................... 127 R-block......... 90................ 164 Parity.............99 Module Height ............................................... 97.............................................................92 Content ................................................................... 100 S(IFS Response) Block ...............................................48 Contact Force ...............................................................87 N N ...79 Node Address ...............................46 P P .................................................... 44............................................95 S-block ..... 90....................47 Contact Assignment ............................... 136 Payment System Directory File .................... 107..............................................................................96 READ RECORD ........................... 115 Resumption Information ................................... 105 S(RESYNCH Request) Block .......... 112 Programming Voltage .............90 Padding Format a........... 91.....87 Physical Transportation of Characters ........................................................ ................97 Multi-application ICCs ............................ 90................... Terminal ....... 164 Format n ........................ 5 Notations ... 149 Index PI2 ....................... 127 Format ..................................................... 95 NAK............................................................... 144 Resynchronisation.... See VPP Proprietary Application Identifier Extension ................ 167 Migration to Lower Voltage Cards . iii RID . 93....................................................... 104 Partial Name Selection .................................................EMV 4..................................................................................................... See NAD Normal Status ...66 Parity Error.............................................................................................................................................. 101 S(WTX Response) Block .........48 Contact Location ...................... 100................................................................................................................................................................................................................. 137 O Operating Voltage Ranges ..............................................................................................65 Physical Transportation of Characters Returned at Answer to Reset ............... 122 PSE Method .................................... ............................ 94........... 127 Structure ...................................73 Reset ................................ 95..........................74 P1 ............................... 131 Protocol ....................................... 116 P3 .... 133 Multiple Applications ..........38 Module Height ................. See Transmission Protocols Protocol Control Byte .............. See R-APDU Response Data ............................................. 101............................................................... 74................................................................. 97...... 116 P2 .............................................57 Procedure Byte ...................................................................53 Response APDU ..... 122 Payment System Directory Record Format .............................2 Book 1 Application Independent ICC to Terminal Interface Requirements Contact Location .................................. 97..... 128 Command Reference Control Parameter ................................................... 142 Payment System Application ......................................................................27 R R-APDU ............................................................................ 104 PSE ............................ 101 SAD ..........................73 Reject an ICC ............... an...........37 Mechanical Characteristics................................. 61 Terminal Electrical Characteristics ................69 PI1 ........................................... 106 S(IFS Request) Block ..............76 S S(ABORT Request) Block ..................................................................................................................... See PCB Protocol Error ....................................................... 77 NAD...................................... 5 Registered Application Provider Identifier ............................................................................................................ 104......................................................36 Minimum Interval .....................................................72 Parity Bit ............ See RID Reject an ATR ....................... 106 Revision Log .........................................................

. 130 Command Reference Control Parameter ....... 111.........................................................48 VCC ........................................ 130 Command Options Parameter ...Interface Character............................83 Terminal Electrical Characteristics ...48 Contact Location .................................... 107 Transportation of APDUs by T=1 .......................... 107........................................................49 I/O Reception ........................47 Contact Assignment .................56 Sliding Carriage ............................................................................ See TTL Terminology .......... 148 V VCC ICC Electrical Characteristics. See S-block Supply Voltage ........51 Terminal Logic Using Directories ......................................................................................94 Structure of Command Message ............................. 114 Supervisory block .....................................................74 TA1 ........................................................48 Contact Force ....Interface Character .............75 TA2 ..............................................Interface Character............................................................ 89 Page 180 June 2008 ...........................................................................................................................................................81 TAL ............ See Character Protocol T=0...........................................................Initial Character ........ 127 Transaction Abortion ............. 108 WI ................................................................................................................... 121 TS .................. 101 Syntax Error ....................................................See VCC Supply Voltage (VCC) .......45 Terminal Electrical Characteristics ................80 Temperature Range .... 104 Transmission Protocols ............ 126 Command Message ...........Interface Character ......................................................... 129 Response Message Data Field (FCI) of ADF 133 Response Message Data Field (FCI) of DDF 132 Response Message Data Field (FCI) of PSE ...................................................52 Contact Resistance ...91 Terminal Supply Voltage and Current ................54 Synchronisation ................................... 40....Interface Character..................................62 Warning Status ............................................... 87............ See WI Warm Reset ...................................90 Terminal Behaviour during Answer to Reset ......64 Source Node Address ...........................................80 Work Waiting Time .............................. 90...................51 I/O Transmission...............87 Transport of APDUs by T=0 ................................................See Character Protocol T=0 T=1 ....92 Structure of a Block Block Protocol T=1 ............57 U Using the List of AIDs in the Terminal ...95 SELECT .51 W Waiting Time Integer .............31 Trailer ........................................78 TD2 ..48 Clock .............................47 Terminal Response to Procedure Byte .....54 Voltage Ranges...............Format Character .................79 Stages of a Card Session ............Interface Character .................................................................................77 TC2 ................................................... 106 Transmission Control Parameters....................... 115 Transport of APDUs by T=0 ........... 107 Transportation of APDUs by T=1 ........................... 104 T T=0 .....Index EMV 4............................................................ 66... 90..................53 Short Circuit Resilience ............................. 130 Command-Response APDUs ...Interface Character..................82 TCK ....................... 115 Types of Blocks .......................... 70............................................................................................82 TC1 ........ 131 Terminal Application Layer ................66 Status Byte Coding ...............................Interface Character .......50 Powering and Depowering ..............................................................59 Start Bit........56 Current Requirement......Interface Character........................................................................................... See Block Protocol T=1 Transport Layer ........... 73 TTL................................. 76....80 TC3 .......................................................................42 Terminal Electrical Characteristics ..............................46 VPP........................Check Character .............. 80.................. 160 Template 'BF0C' ..2 Book 1 Application Independent ICC to Terminal Interface Requirements Reset ..........................................................................................................74 Transmission Error ...... 48 Template .............. 145 Terminal Mechanical Characteristics ........ See SAD Specific Mode ..................................56 Temperature Range ............ See Block Protocol T=1 T0 .........................55 Terminal Transport Layer ..........................................................................................................76 TB2 ................ 79 ICC Electrical Characteristics..........................................54 I/O Current Limit ...................... 123 Short Circuit Resilience ....................................................................... 131 SFI ....................................... 115 TB1 ............................Interface Character............... 122.................Interface Character .........83 TD1 .............79 TB3 ........................ 73...54 VPP .... 115 Tree Structure..........................................79 TA3 ................................................................

EMV 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements June 2008 Page 181 .

Sign up to vote on this title
UsefulNot useful