EMV

Integrated Circuit Card
Specifications for Payment Systems


Book 3

Application Specification


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 3

Application Specification


Version 4.2
June 2008

EMV 4.2 Book 3
Application Specification

Page ii June 2008

EMV 4.2 Book 3
Application Specification

June 2008 Page iii
Revision Log - Version 4.2
The following changes have been made to Book 3 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 Specification Updates:
Specification Update Bulletin no. 39: Definition of the new data element:
‗Account Type‘
Specification Update Bulletin no. 41 Third Edition: Corrections to
Common Core Definitions
Specification Update Bulletin no. 42: Voice Referrals
Specification Update Bulletin no. 44: CDA Modified Terminal Behaviour
Specification Update Bulletin no. 45: Enciphered PIN Recovery Errors
Specification Update Bulletin no. 46: Replacement of EMV Session Key
Derivation Method
Specification Update Bulletin no. 47: Support for Proprietary
Authentication Data in CCD
Specification Update Bulletin no. 48: CVM List Processing
Specification Update Bulletin no. 51: Online-only terminals
Specification Update Bulletin no. 54: Missing Mandatory Command
Response Data
Specification Update Bulletin no. 55: Terminal Velocity Checking and
CCD
Specification Update Bulletin no. 66: CCD Setting of CDA Performed in
the CVR
Updated in support of the following Application Notes:
Application Note no. 23: Data Elements in the PDOL
Application Note no. 24: Coding of Transaction Type
Application Note no. 25: Issuer Application Data coding for
CCD-compliant and Non CCD-compliant Applications
Application Note no. 27: Terminal Behaviour for Goods & Services Checks
during the Processing Restriction Function
Revision Log EMV 4.2 Book 3
Application Specification

Page iv June 2008
Application Note no. 31: Coding of the Length Field of BER-TLV Coded
Data Objects not Sent Over the Card-Terminal Interface
Application Note no. 32: Advice Requested in the Cryptogram Information
Data
Application Note no. 34: Padding of Bit Combination Data in DOLs
Minor editorial clarifications, including those described in the following
Specification Update:
Specification Update Bulletin no. 37 Fourth Edition: Editorial Errors in
Release 4.1 of the EMV Specifications

EMV 4.2 Book 3
Application Specification

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 - Data Elements and Commands

5 Data Elements and Files 35
5.1 Data Elements Associated with Financial Transaction Interchange 35
5.2 Data Objects 36
5.2.1 Classes of Data Objects 36
5.3 Files 37
5.3.1 Application Elementary Files 37
5.3.2 File Referencing 37
5.4 Rules for Using a Data Object List (DOL) 38
6 Commands for Financial Transaction 41
6.1 Command APDU Format 41
6.2 Response APDU Format 42
6.3 Coding Conventions 42
6.3.1 Coding of the Class Byte 42
6.3.2 Coding of the Instruction Byte 43
EMV 4.2 Book 3
Application Specification

Page vi June 2008
6.3.3 Coding of Parameter Bytes 43
6.3.4 Coding of Data Field Bytes 44
6.3.5 Coding of the Status Bytes 44
6.3.6 Coding of RFU Data 47
6.4 Logical Channels 47
6.5 Commands 48
6.5.1 APPLICATION BLOCK Command-Response APDUs 49
6.5.2 APPLICATION UNBLOCK Command-Response APDUs 51
6.5.3 CARD BLOCK Command-Response APDUs 52
6.5.4 EXTERNAL AUTHENTICATE Command-Response APDUs 54
6.5.5 GENERATE APPLICATION CRYPTOGRAM Command-Response
APDUs 56
6.5.6 GET CHALLENGE Command-Response APDUs 60
6.5.7 GET DATA Command-Response APDUs 61
6.5.8 GET PROCESSING OPTIONS Command-Response APDUs 63
6.5.9 INTERNAL AUTHENTICATE Command-Response APDUs 65
6.5.10 PIN CHANGE/UNBLOCK Command-Response APDUs 67
6.5.11 READ RECORD Command-Response APDUs 69
6.5.12 VERIFY Command-Response APDUs 71


Part III - Debit and Credit Application Specification

7 Files for Financial Transaction Interchange 77
7.1 Mapping Data Objects 77
7.2 Mandatory Data Objects 78
7.3 Data Retrievable by GET DATA Command 80
7.4 Data Retrievable by GET PROCESSING OPTIONS 80
7.5 Erroneous or Missing Data in the ICC 81
8 Transaction Flow 83
8.1 Exception Handling 83
8.2 Example Flowchart 83
8.3 Additional Functions 85
9 GENERATE AC Command Coding 87
9.1 Command Parameters 89
9.2 Command Data 89
9.2.1 Card Risk Management Data 89
9.2.2 Transaction Certificate Data 90
9.3 Command Use 90
EMV 4.2 Book 3
Application Specification

June 2008 Page vii
9.3.1 GENERATE AC (First Issuance) 91
9.3.2 GENERATE AC (Second Issuance) 91
10 Functions Used in Transaction Processing 93
10.1 Initiate Application Processing 93
10.2 Read Application Data 95
10.3 Offline Data Authentication 97
10.4 Processing Restrictions 100
10.4.1 Application Version Number 100
10.4.2 Application Usage Control 101
10.4.3 Application Effective/Expiration Dates Checking 102
10.5 Cardholder Verification 103
10.5.1 Offline PIN Processing 106
10.5.2 Online PIN Processing 107
10.5.3 Signature Processing 107
10.5.4 Combination CVMs 107
10.5.5 CVM Processing Logic 107
10.6 Terminal Risk Management 113
10.6.1 Floor Limits 114
10.6.2 Random Transaction Selection 114
10.6.3 Velocity Checking 116
10.7 Terminal Action Analysis 117
10.8 Card Action Analysis 121
10.8.1 Terminal Messages for an AAC 122
10.8.2 Advice Messages 122
10.9 Online Processing 123
10.10 Issuer-to-Card Script Processing 125
10.11 Completion 127


Part IV - Annexes

Annex A Data Elements Dictionary 131
A1 Data Elements by Name 131
A2 Data Elements by Tag 154

Annex B Rules for BER-TLV Data Objects 161
B1 Coding of the Tag Field of BER-TLV Data Objects 162
B2 Coding of the Length Field of BER-TLV Data Objects 163
EMV 4.2 Book 3
Application Specification

Page viii June 2008
B3 Coding of the Value Field of Data Objects 164

Annex C Coding of Data Elements Used in Transaction Processing 165
C1 Application Interchange Profile 166
C2 Application Usage Control 167
C3 Cardholder Verification Rule Format 168
C4 Issuer Code Table Index 170
C5 Terminal Verification Results 171
C6 Transaction Status Information 174

Annex D Transaction Log Information 175
D1 Purpose 175
D2 Conditions of Execution 175
D3 Sequence of Execution 175
D4 Description 176
D5 Example 177

Annex E TVR and TSI Bit Settings Following Script Processing 179
E1 Scenarios 179
E2 Additional Information 181

Annex F Status Words Returned in EXTERNAL AUTHENTICATE 183

Part V - Common Core Definitions

Introduction 189
Changed and Added Sections 189
6 Commands for Financial Transaction 190
6.2 Response APDU Format 190
6.5 Commands 190
6.5.4 EXTERNAL AUTHENTICATE Command-Response APDUs 190
6.5.5 GENERATE APPLICATION CRYPTOGRAM Command-
Response APDUs 190
6.5.8 GET PROCESSING OPTIONS Command-Response APDUs 191
6.5.9 INTERNAL AUTHENTICATE Command-Response APDUs 192
EMV 4.2 Book 3
Application Specification

June 2008 Page ix
7 Files for Financial Transaction Interchange 193
7.3 Data Retrievable by GET DATA Command 193
9 GENERATE AC Command Coding 194
9.2 Command Data 194
9.2.2 Transaction Certificate Data 194
9.2.3 Common Core Definitions Card Verification Results 194
9.3 Command Use 204
10 Functions Used in Transaction Processing 205
10.5 Cardholder Verification 205
10.5.1 Offline PIN Processing 205
10.8 Card Action Analysis 205
10.8.1 Terminal Messages for an AAC 205
10.8.2 Advice Messages 205
10.10 Issuer-to-Card Script Processing 205
10.11 Completion 206
10.11.1 Additional Completion Actions for a CCD-Compliant
Application 206
Annex A Data Elements Dictionary 210
Annex C Coding of Data Elements Used in Transaction Processing 212
C7 Issuer Application Data for a Common Core Definitions-Compliant
Application 212
C7.1 Common Core Identifier 212
C7.2 Issuer Application Data for Format Code ‗A‘ 213
C7.3 Card Verification Results 214
C8 Card Status Update for a Common Core Definitions-Compliant
Application 216
Annex D Transaction Log Information 217


Index 219

EMV 4.2 Book 3
Application Specification

Page x June 2008

EMV 4.2 Book 3
Application Specification

June 2008 Page xi
Tables
Table 1: Structure of SFI 38
Table 2: Most Significant Nibble of the Class Byte 42
Table 3: Coding of the Instruction Byte 43
Table 4: Coding of Status Bytes SW1 SW2 45
Table 5: Allocation of Status Bytes 46
Table 6: APPLICATION BLOCK Command Message 49
Table 7: APPLICATION UNBLOCK Command Message 51
Table 8: CARD BLOCK Command Message 52
Table 9: EXTERNAL AUTHENTICATE Command Message 54
Table 10: GENERATE AC Cryptogram Types 56
Table 11: GENERATE AC Command Message 57
Table 12: GENERATE AC Reference Control Parameter 57
Table 13: Format 1 GENERATE AC Response Message Data Field 58
Table 14: Coding of Cryptogram Information Data 59
Table 15: GET CHALLENGE Command Message 60
Table 16: GET DATA Command Message 61
Table 17: GET PROCESSING OPTIONS Command Message 63
Table 18: INTERNAL AUTHENTICATE Command Message 65
Table 19: PIN CHANGE/UNBLOCK Command Message 68
Table 20: READ RECORD Command Message 69
Table 21: READ RECORD Command Reference Control Parameter 69
Table 22: VERIFY Command Message 71
Table 23: VERIFY Command qualifier of reference data (P2) 72
Table 24: Plaintext Offline PIN Block Format 73
Table 25: Data Objects Used by the Offline Data Authentication Algorithm 78
Table 26: Mandatory Data Objects 78
Table 27: Data Required for SDA 79
Table 28: Data Required for DDA and/or CDA 79
Table 29: Data Objects Retrievable by GET DATA Command 80
Table 30: Data Retrievable by GET PROCESSING OPTIONS 80
Table 31: ICC Data Missing Indicator Setting 82
EMV 4.2 Book 3
Application Specification

Page xii June 2008
Table 32: Terminal Action Regarding Application Usage Control 101
Table 33: Data Elements Dictionary 131
Table 34: Data Elements Tags 154
Table 35: Tag Field Structure (First Byte) BER-TLV 162
Table 36: Tag Field Structure (Subsequent Bytes) BER-TLV 162
Table 37: Application Interchange Profile 166
Table 38: Application Usage Control 167
Table 39: CVM Codes 168
Table 40: CVM Condition Codes 169
Table 41: Issuer Code Table Index 170
Table 42: Terminal Verification Results 171
Table 43: Transaction Status Information 174
Table 44: Log Entry 176
Table 45: Example of Log Format 177
Table 46: Terminal Action after (First) EXTERNAL AUTHENTICATE Response
183
Table 47: Account Type 185

Table CCD 1: Body of Response APDU Structure 190
Table CCD 2: Format 2 GENERATE AC Response Message Data Field 191
Table CCD 3: Coding of Cryptogram Information Data 191
Table CCD 4: Format 2 GET PROCESSING OPTIONS Response Message Data
Field 192
Table CCD 5: Format 2 Internal Authenticate Response Message Data Field 192
Table CCD 6: Data Elements Not Used by a CCD-Compliant Application 210
Table CCD 7: Additional Data Elements Defined for CCD 211
Table CCD 8: Common Core Identifier 212
Table CCD 9: Issuer Application Data for Format Code ‗A‘ 213
Table CCD 10: Card Verification Results for Format Code ‗A‘ 214
Table CCD 11: Card Status Update for Cryptogram Version ‗5‘ 216
EMV 4.2 Book 3
Application Specification

June 2008 Page xiii
Figures
Figure 1: Command APDU Structure 41
Figure 2: Response APDU Structure 42
Figure 3: Structural Scheme of Status Bytes 44
Figure 4: Format 1 GET PROCESSING OPTIONS Response Message Data Field
64
Figure 5: READ RECORD Response Message Data Field 70
Figure 6: Transaction Flow Example 84
Figure 7: Use of GENERATE AC Options 88
Figure 8: CVM Processing (Part 1 of 5) 108
Figure 9: CVM Processing (Part 2 of 5) 109
Figure 10: CVM Processing (Part 3 of 5) 110
Figure 11: CVM Processing (Part 4 of 5) 111
Figure 12: CVM Processing (Part 5 of 5) 112
Figure 13: Random Transaction Selection Example 115
Figure 14: Issuer Script Format 126
Figure 15: Issuer Script Command Format (Shown with Three Commands) 126
Figure 16: Primitive BER-TLV Data Object (Data Element) 164
Figure 17: Constructed BER-TLV Data Object 164

EMV 4.2 Book 3
Application Specification

Page xiv June 2008

EMV 4.2 Book 3
Application Specification

June 2008 Page 1
Part I

General
EMV 4.2 Book 3
Application Specification

Page 2 June 2008
EMV 4.2 Book 3
Application Specification

June 2008 Page 3
1 Scope
This document, the Integrated Circuit Card Specifications for Payment Systems -
Book 3, Application Specification defines the terminal and integrated circuit card
(ICC) procedures necessary to effect a payment system transaction in an
international interchange environment.
The Integrated Circuit Card Specifications for Payment Systems includes the
following additional documents, all available on http://www.emvco.com:
- Book 1 - Application Independent ICC to Terminal Interface Requirements
- Book 2 - Security and Key Management
- Book 4 - Cardholder, Attendant, and Acquirer Interface Requirements
1.1 Changes in Version 4.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 specification.
1.2 Structure
Book 3 consists of the following parts:
Part I - General
Part II - Data Elements and Commands
Part III - Debit and Credit Application Specification
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.
Part II describes data elements and files as well as commands for financial
transaction.
1 Scope EMV 4.2 Book 3
1.3 Underlying Standards Application Specification

Page 4 June 2008
Part III specifies the debit and credit application functions including:
- Transaction flow (the sequence of events and the commands issued to the
card)
- Exception processing
- Definition of data elements and commands as they apply to the exchange of
information between an ICC and a terminal. In particular,
 Structure and referencing of files
 The usage of commands between the ICC and the terminal to achieve
application level functions.
The functions described are those necessary to ensure that payment system cards
conforming to this specification can perform a set of core functions in terminals
conforming to this specification. Application functions unique to individual
payment systems and those functions not performed in interchange are not
described, but are not precluded.
Part IV includes a complete data elements dictionary, rules for BER-TLV data
objects, instructions for coding of specific data elements, and transaction log
information. It discusses TVR and TSI bit settings following script processing,
and Status Words returned in response to an EXTERNAL AUTHENTICATE
command.
Part V defines an optional extension to be used when implementing a card
complying to the Common Core Definitions (CCD).
The Book also includes a revision log and an index.
This specification does not address clearing and settlement or any transactions
where the ICC is not present.
1.3 Underlying Standards
This specification is based on the ISO/IEC 7816 series of standards and should be
read in conjunction with those standards. However, if any of the provisions or
definitions in this specification differ from those standards, the provisions herein
shall take precedence.
1.4 Audience
This specification is intended for use by manufacturers of ICCs and terminals,
system designers in payment systems, and financial institution staff responsible
for implementing financial applications in ICCs.

EMV 4.2 Book 3
Application Specification

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 3
Application Specification

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
ISO/IEC 10116 Information technology – Security techniques –
Modes of operation for an n-bit block cipher
EMV 4.2 Book 3 2 Normative References
Application Specification

June 2008 Page 7
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 3
Application Specification

Page 8 June 2008

EMV 4.2 Book 3
Application Specification

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.
Byte 8 bits.
3 Definitions EMV 4.2 Book 3
Application Specification

Page 10 June 2008
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.
Cryptogram Result of a cryptographic operation.
EMV 4.2 Book 3 3 Definitions
Application Specification

June 2008 Page 11
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 of
Book 1.
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 3
Application Specification

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 3 3 Definitions
Application Specification

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 3
Application Specification

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 3 3 Definitions
Application Specification

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 3
Application Specification

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 of Book 1, and displaying a
message indicating that the ICC cannot be used to
complete the transaction
Terminate
Transaction
Stop the current application and deactivate the card.
EMV 4.2 Book 3 3 Definitions
Application Specification

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 3
Application Specification

Page 18 June 2008

EMV 4.2 Book 3
Application Specification

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 Convention)
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
4 Abbreviations, Notations, Conventions, and Terminology EMV 4.2 Book 3
4.1 Abbreviations Application Specification

Page 20 June 2008
ATC Application Transaction Counter
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
CIN 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
EMV 4.2 Book 3 4 Abbreviations, Notations, Conventions, and Terminology
Application Specification 4.1 Abbreviations

June 2008 Page 21
CV Cryptogram Version
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
4 Abbreviations, Notations, Conventions, and Terminology EMV 4.2 Book 3
4.1 Abbreviations Application Specification

Page 22 June 2008
I/O Input/Output
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
ICC 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
IOH High Level Output Current
IOL Low Level Output Current
ISO International Organization for Standardization
IV Initial Vector for session key generation
KM Master Key
KS Session Key
L Length
l.s. Least Significant
Lc Exact Length of Data Sent by the TAL in a Case 3 or 4
Command
EMV 4.2 Book 3 4 Abbreviations, Notations, Conventions, and Terminology
Application Specification 4.1 Abbreviations

June 2008 Page 23
LCOL Lower Consecutive Offline Limit
LDD 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
4 Abbreviations, Notations, Conventions, and Terminology EMV 4.2 Book 3
4.1 Abbreviations Application Specification

Page 24 June 2008
nAs Nanoampere-second
NCA Length of the Certification Authority Public Key Modulus
NF Norme Française
NI Length of the Issuer Public Key Modulus
NIC Length of the ICC Public Key Modulus
NIST National Institute for Standards and Technology
NPE 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
PCA Certification Authority Public Key
PCB Protocol Control Byte
PDOL Processing Options Data Object List
pF Picofarad
PI Issuer Public Key
PIC 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 3 4 Abbreviations, Notations, Conventions, and Terminology
Application Specification 4.1 Abbreviations

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
SCA Certification Authority Private Key
SDA Static Data Authentication
SFI Short File Identifier
SHA-1 Secure Hash Algorithm 1
SI Issuer Private Key
SIC 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
tF Fall Time Between 90% and 10% of Signal Amplitude
TLV Tag Length Value
TPDU Transport Protocol Data Unit
tR Rise Time Between 10% and 90% of Signal Amplitude
TS Initial Character
TSI Transaction Status Information
4 Abbreviations, Notations, Conventions, and Terminology EMV 4.2 Book 3
4.1 Abbreviations Application Specification

Page 26 June 2008
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)
VCC Voltage Measured on VCC Contact
VCC Supply Voltage
VIH High Level Input Voltage
VIL Low Level Input Voltage
VOH High Level Output Voltage
VOL Low Level Output Voltage
VPP Programming Voltage
VPP 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 3 4 Abbreviations, Notations, Conventions, and Terminology
Application Specification 4.2 Notations

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 (SK)[X] The signing of a data block X with an asymmetric
reversible algorithm as specified in Annex A2 of Book 2,
using the private key SK
X = Recover(PK)[Y] The recovery of the data block X with an asymmetric
reversible algorithm as specified in Annex A2 of Book 2,
using the public key PK
C := (A || B) The concatenation of an n-bit number A and an m-bit
number B, which is defined as C = 2
m
A + B.
Leftmost Applies to a sequence of bits, bytes, or digits and used
interchangeably with the term ―most significant‖. If
C = (A || B) as above, then A is the leftmost n bits of C.
4 Abbreviations, Notations, Conventions, and Terminology EMV 4.2 Book 3
4.2 Notations Application Specification

Page 28 June 2008
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 3 4 Abbreviations, Notations, Conventions, and Terminology
Application Specification 4.3 Data Element Format Conventions

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 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 3
4.3 Data Element Format Conventions Application Specification

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 3 4 Abbreviations, Notations, Conventions, and Terminology
Application Specification 4.4 Terminology

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 3
4.4 Terminology Application Specification

Page 32 June 2008

EMV 4.2 Book 3
Application Specification

June 2008 Page 33
Part II

Data Elements and
Commands
EMV 4.2 Book 3
Application Specification

Page 34 June 2008
EMV 4.2 Book 3
Application Specification

June 2008 Page 35
5 Data Elements and Files
An application in the Integrated Circuit Card (ICC) includes a set of items of
information. These items of information may be accessible to the terminal after a
successful application selection (see section 12 of Book 1).
An item of information is called a data element. A data element is the smallest
piece of information that may be identified by a name, a description of logical
content, a format, and a coding.
5.1 Data Elements Associated with Financial
Transaction Interchange
The data elements dictionary defined in Annex A includes those data elements
that may be used for financial transaction interchange. Data elements not
specified in Annex A are outside the scope of these specifications.
Any additional data element transmitted in the response to the SELECT
command (for example, O/S Manufacturer proprietary data) is placed in the field
―FCI Issuer Discretionary Data‖ (tag 'BF0C').
5 Data Elements and Files EMV 4.2 Book 3
5.2 Data Objects Application Specification

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

June 2008 Page 37
5.3 Files
The data objects contained in data files accessible from the ICC are stored in
records. The file structure and referencing method depend on the purpose of the
file. The following sections describe structures and referencing methods. The
layout of the data files accessible from the ICC is left to the discretion of the
issuer except for the directory files described in the following section.
5.3.1 Application Elementary Files
An Application Elementary File (AEF) in the range 1-10, contains one or more
primitive Basic Encoding Rules - TLV (BER-TLV) data objects grouped into
constructed BER-TLV data objects (records) according to Annex B. After selecting
the application, an AEF in the range 1-10 is referred to only by its SFI as
described in section 5.3.2.2.
A data file referred to in this specification consists of a sequence of records
addressed by record number. The data files referred to by SFIs in the range 1-10
contain only data not interpreted by the card, that is, data that is not used by the
card in its internal processes. This file structure is defined as linear. It can be
either linear fixed or linear variable according to ISO/IEC 7816-4. The choice is
left to the issuer and does not affect the reading of the file according to this
specification.
5.3.2 File Referencing
A file may be referred to by a name or a SFI depending on its type.
5.3.2.1 Referencing by Name
Any Application Definition File (ADF) or Directory Definition File (DDF) in the
card is referenced by its Dedicated File (DF) name. A DF name for an ADF
corresponds to the Application Identifier (AID) or contains the AID as the
beginning of the DF name. Each DF name shall be unique within a given card.
5 Data Elements and Files EMV 4.2 Book 3
5.4 Rules for Using a Data Object List (DOL) Application Specification

Page 38 June 2008
5.3.2.2 Referencing by SFI
SFIs are used for the selection of AEFs. Any AEF within a given application is
referenced by a SFI coded on 5 bits in the range 1 to 30. The coding of the SFI is
described in every command that uses it.
Table 1 describes the assignment of SFIs for an EMV application:

Value Meaning
1-10 Governed by this specification
11-20 Payment system-specific
21-30 Issuer-specific
Table 1: Structure of SFI
A SFI shall be unique within an application. The coding of SFIs within the range
1 to 10 is used to address AEFs governed by this specification.
5.4 Rules for Using a Data Object List (DOL)
In several instances, the terminal is asked to build a flexible list of data elements
to be passed to the card under the card‘s direction. To minimise processing within
the ICC, such a list is not TLV encoded but is a single constructed field built by
concatenating several data elements together. Since the elements of the
constructed field are not TLV encoded, it is imperative that the ICC knows the
format of this field when the data is received. This is achieved by including a
Data Object List (DOL) in the ICC, specifying the format of the data to be
included in the constructed field. DOLs currently used in this specification
include:
- the Processing Options Data Object List (PDOL) used with the GET
PROCESSING OPTIONS command
- the Card Risk Management Data Object Lists (CDOL1 and CDOL2) used
with the GENERATE APPLICATION CRYPTOGRAM (AC) command
- the Transaction Certificate Data Object List (TDOL) used to generate a TC
Hash Value
- the Dynamic Data Authentication Data Object List (DDOL) used with the
INTERNAL AUTHENTICATE command
This section describes the rules for constructing a field using a DOL supplied by
the card.
EMV 4.2 Book 3 5 Data Elements and Files
Application Specification 5.4 Rules for Using a Data Object List (DOL)

June 2008 Page 39
A DOL is a concatenated list of entries, with each entry representing a single
data element to be included in the constructed field. The format of each entry is a
one- or two-byte tag identifying the desired data object, followed by a one-byte
length which represents the number of bytes the field shall occupy in the
command data. Only tags representing primitive data objects constructed
according to Annex B shall be used in DOLs.
The terminal shall complete the following steps to build the constructed field:
1. Read the DOL from the ICC.
2. Concatenate all data elements listed in the DOL. The following rules apply to
this concatenation:
a. If the tag of any data object identified in the DOL is unknown to the
terminal or represents a constructed data object, the terminal shall
provide a data element with the length specified and a value of all
hexadecimal zeroes.
b. If a data object is in the list and is meaningful to the terminal but
represents optional static data that is absent from the terminal, the
portion of the command field representing the data object shall be filled
with hexadecimal zeroes.
c. If the length specified in the DOL entry is less than the length of the
actual data object, the leftmost bytes of the data element shall be
truncated if the data object has numeric (n
1
) format, or the rightmost
bytes of the data shall be truncated for any other format.
d. If the length specified in the DOL entry is greater than the length of the
actual data, the actual data shall be padded:
 with leading hexadecimal zeroes if the data has numeric format
 with trailing hexadecimal ‗FF‘s if the data has compressed numeric
(cn
1
) format
 with trailing hexadecimal zeroes for any other format (an, ans or b
including bit combination data
1
)
e. If a data object is in the list and is meaningful to the terminal but
represents data that is not applicable to the current transaction, the
portion of the command field representing the data object shall be filled
with hexadecimal zeroes.
The completed list of data elements shall be concatenated in the sequence in
which the corresponding data objects appear in the DOL.

1
See section 4.3 Data Element Format Convention.
5 Data Elements and Files EMV 4.2 Book 3
5.4 Rules for Using a Data Object List (DOL) Application Specification

Page 40 June 2008
EMV 4.2 Book 3
Application Specification

June 2008 Page 41
6 Commands for Financial Transaction
6.1 Command APDU Format
The command Application Protocol Data Unit (APDU) consists of a mandatory
header of four bytes followed by a conditional body of variable length, as shown in
Figure 1:

CLA INS P1 P2 Lc Data Le
÷ Mandatory Header
2
÷ ÷ Conditional Body ÷
Figure 1: Command APDU Structure
The number of data bytes sent in the command APDU (C-APDU) is denoted by
Lc (length of command data field).
The maximum number of data bytes expected in the response APDU is denoted
by length of expected data (Le). When Le is present and contains the value zero,
the maximum number of available data bytes (up to 256) is expected. When
required in a command message, Le shall always be set to '00'.

2
CLA = Class Byte of the Command Message
INS = Instruction Byte of Command Message
P1 = Parameter 1
P2 = Parameter 2
6 Commands for Financial Transaction EMV 4.2 Book 3
6.2 Response APDU Format Application Specification

Page 42 June 2008
6.2 Response APDU Format
The response APDU format consists of a conditional body of variable length
followed by a mandatory trailer of two bytes, as shown in Figure 2:

Data SW1 SW2
÷ Body ÷ ÷ Trailer ÷
Figure 2: Response APDU Structure
The data field of a response APDU is an object structured as defined in Annex B.
The detailed coding of the objects is provided with the commands described in
subsequent sub-clauses.
6.3 Coding Conventions
This section defines the coding of the header and the body of the messages
(command and response).
6.3.1 Coding of the Class Byte
The most significant nibble of the class byte indicates the type of command as
shown in Table 2:

Hex Meaning
'0' Inter-industry command
'8' Proprietary to this specification
Any other value Outside the scope of this specification
Table 2: Most Significant Nibble of the Class Byte
A command proprietary to this specification is introduced by the most significant
nibble of the class byte set to 8; in other words, the structure of the command and
response messages is according to ISO/IEC 7816-4, and the coding of the
messages is defined within the context of these specifications.
The least significant nibble of the class byte indicates secure messaging and
logical channel mechanisms, according to ISO/IEC 7816-4.
EMV 4.2 Book 3 6 Commands for Financial Transaction
Application Specification 6.3 Coding Conventions

June 2008 Page 43
6.3.2 Coding of the Instruction Byte
The INS byte of a command is structured according to Book 1 section 9.4.1.
Table 3 indicates the coding of INS and its relationship to CLA:

CLA INS Meaning
'8x' '1E' APPLICATION BLOCK
'8x' '18' APPLICATION UNBLOCK
'8x' '16' CARD BLOCK
'0x' '82' EXTERNAL AUTHENTICATE
'8x' 'AE' GENERATE APPLICATION CRYPTOGRAM
'0x' '84' GET CHALLENGE
'8x' 'CA' GET DATA
'8x' 'A8' GET PROCESSING OPTIONS
'0x' '88' INTERNAL AUTHENTICATE
'8x' '24' PERSONAL IDENTIFICATION NUMBER (PIN)
CHANGE/UNBLOCK
'0x' 'B2' READ RECORD
'0x' 'A4' SELECT
'0x' '20' VERIFY
'8x' 'Dx' RFU for the payment systems
'8x' 'Ex' RFU for the payment systems
'9x' 'xx' RFU for manufacturers for proprietary INS coding
'Ex' 'xx' RFU for issuers for proprietary INS coding
Table 3: Coding of the Instruction Byte
Note: Additional INS codes may be assigned in the future by EMVCo using class '8x'. It
is strongly recommended that application providers not define proprietary commands in
class '8x' when they are to be used in the context of these specifications, so that collision
is avoided.
6.3.3 Coding of Parameter Bytes
The parameter bytes P1 P2 may have any value. If not used, a parameter byte
has the value '00'.
6 Commands for Financial Transaction EMV 4.2 Book 3
6.3 Coding Conventions Application Specification

Page 44 June 2008
6.3.4 Coding of Data Field Bytes
When present, a command APDU message data field consists of a string of data
elements.
When present, a response APDU message data field consists of a data object or a
string of data objects encapsulated in a template according to Annex B.
6.3.5 Coding of the Status Bytes
The status bytes SW1 SW2 are returned by the transport layer to the application
layer in any response message and denote the processing state of the command.
The coding of the status words is structured as illustrated in Figure 3:

SW1 SW2
'61xx'
'9000'
'62xx' '63xx' '67xx' to
'6Fxx'
'65xx' '64xx'
Process Completed
Normal Warning
Process Aborted
Execution Checking

Figure 3: Structural Scheme of Status Bytes
EMV 4.2 Book 3 6 Commands for Financial Transaction
Application Specification 6.3 Coding Conventions

June 2008 Page 45

SW1 SW2 Meaning

Normal processing
'90' '00' Process completed (any other value for SW2 is RFU)

Warning processing
'62' '83' State of non-volatile memory unchanged; selected file invalidated
'63' '00' State of non-volatile memory changed; authentication failed
'63' 'Cx' State of non-volatile memory changed; counter provided by 'x'
(from 0-15)

Checking errors
'69' '83' Command not allowed; authentication method blocked
'69' '84' Command not allowed; referenced data invalidated
'69' '85' Command not allowed; conditions of use not satisfied
'6A' '81' Wrong parameter(s) P1 P2; function not supported
'6A' '82' Wrong parameter(s) P1 P2; file not found
'6A' '83' Wrong parameter(s) P1 P2; record not found
'6A' '88' Referenced data (data objects) not found
Table 4: Coding of Status Bytes SW1 SW2
The following values of SW1 SW2 are described in Part II of Book 1 as they apply
to the Transport Protocol Data Unit (TPDU) and are not returned to the APDU:
- '61xx': SW2 indicates the number of response bytes still available.
- '6Cxx': Wrong length Le, SW2 indicates the exact length.
SW1 = '6x' or '90' denotes a normal, warning, or error condition coded according
to ISO/IEC 7816-4.
Other values of SW1 returned by the ICC are not supported by Book 1, Part II.
6 Commands for Financial Transaction EMV 4.2 Book 3
6.3 Coding Conventions Application Specification

Page 46 June 2008
Table 5 shows the coding of the SW1 SW2 status bytes which this specification
requires to be returned in response to specific conditions. The card may generate
status bytes not listed in this table for error and warning conditions not specified
in Part III.

A
P
P
L
I
C
A
T
I
O
N

B
L
O
C
K

A
P
P
L
I
C
A
T
I
O
N

U
N
B
L
O
C
K

C
A
R
D

B
L
O
C
K

E
X
T
E
R
N
A
L

A
U
T
H
E
N
T
I
C
A
T
E

G
E
N
E
R
A
T
E

A
P
P
L
I
C
A
T
I
O
N

C
R
Y
P
T
O
G
R
A
M

G
E
T

C
H
A
L
L
E
N
G
E

G
E
T

D
A
T
A

G
E
T

P
R
O
C
E
S
S
I
N
G

O
P
T
I
O
N
S

I
N
T
E
R
N
A
L

A
U
T
H
E
N
T
I
C
A
T
E

P
I
N

C
H
A
N
G
E
/
U
N
B
L
O
C
K

R
E
A
D

R
E
C
O
R
D

S
E
L
E
C
T

V
E
R
I
F
Y

SW1 SW2
'62' '83' X
'63' '00' X
'63' 'Cx' X
'69' '83' X
'69' '84' X
'69' '85' X X X
'6A' '81' X X
'6A' '82' X
'6A' '83' X
'6A' '88' X
Table 5: Allocation of Status Bytes
The following convention is used in the table:
X = Allowed response code, for which a dedicated action shall be taken or
which has a special meaning for an EMV compliant application. The
meaning of the action is explained in section 10.
EMV 4.2 Book 3 6 Commands for Financial Transaction
Application Specification 6.4 Logical Channels

June 2008 Page 47
When using transmission protocol T=1, for all commands having Le = '00', the
successful execution of the command is indicated by SW1 SW2 = '90 00' or '61 La'.
However, for readability, both response codes are referenced throughout the text
as '90 00' only.
If during transaction processing as described in Part III, the card returns a value
for SW1 SW2 other than those specified in Table 5, and no other action is
indicated elsewhere in these specifications, the transaction shall be terminated.
For example, if the application reads records in a file that contains four records
and, in response to the READ RECORD command for record 5, the card returns
SW1 SW2 = '6400' instead of SW1 SW2 = '6A83', then the transaction would be
terminated.
If during the processing of the GET DATA command, defined in section 6.5.7, the
card returns an error condition, the terminal shall proceed as indicated in
section 10.6.3 (for terminal velocity checking) or in section 6.3.4.1 of Book 4 (for
cardholder verification processing).
If during the processing of an issuer script command, as defined in section 10.10,
the card returns a warning condition (SW1 SW2 = '62XX' or '63xx'), the terminal
shall continue with the next command from the Issuer Script (if any).
For the EXTERNAL AUTHENTICATE command, SW1 SW2 = '6300' means
‗Authentication Failed‘.
6.3.6 Coding of RFU Data
The coding of data (bits and bytes) indicated as RFU and marked as 'x' in the
tables of the specifications shall be set to zero unless otherwise stated.
To allow for migration and support of new functionality, the ICC and the
terminal shall not verify the data indicated as RFU.
6.4 Logical Channels
A logical channel establishes and maintains the link between an application in
the terminal and an application in the card.
A card may support more than one logical channel but only the basic logical
channel is supported by this specification. This limits to one the number of
concurrent applications according to this specification.
6 Commands for Financial Transaction EMV 4.2 Book 3
6.5 Commands Application Specification

Page 48 June 2008
6.5 Commands
This section describes the following APDU command-response pairs:
- APPLICATION BLOCK (post-issuance command)
- APPLICATION UNBLOCK (post-issuance command)
- CARD BLOCK (post-issuance command)
- EXTERNAL AUTHENTICATE
- GENERATE APPLICATION CRYPTOGRAM
- GET CHALLENGE
- GET DATA
- GET PROCESSING OPTIONS
- INTERNAL AUTHENTICATE
- PIN CHANGE/UNBLOCK (post-issuance command)
- READ RECORD
- VERIFY
The post-issuance commands shall only be sent using script processing (see
section 10.10) and secure messaging as specified in Book 2.
EMV 4.2 Book 3 6 Commands for Financial Transaction
Application Specification 6.5 Commands

June 2008 Page 49
6.5.1 APPLICATION BLOCK Command-Response APDUs
6.5.1.1 Definition and Scope
The APPLICATION BLOCK command is a post-issuance command that
invalidates the currently selected application.
Following the successful completion of an APPLICATION BLOCK command:
- An invalidated application shall return the status bytes SW1 SW2 = '6283'
(‗Selected file invalidated‘) in response to a SELECT command.
- An invalidated application shall return only an Application Authentication
Cryptogram (AAC) as AC in response to a GENERATE AC command.
6.5.1.2 Command Message
The APPLICATION BLOCK command message is coded as shown in Table 6:

Code Value
CLA '8C' or '84'; coding according to the secure messaging
specified in Book 2
INS '1E'
P1 '00'; all other values are RFU
P2 '00'; all other values are RFU
Lc Number of data bytes
Data Message Authentication Code (MAC) data
component; coding according to the secure messaging
specified in Book 2
Le Not present
Table 6: APPLICATION BLOCK Command Message
6.5.1.3 Data Field Sent in the Command Message
The data field of the command message contains the MAC data component coded
according to the secure messaging format specified in Book 2.
6.5.1.4 Data Field Returned in the Response Message
No data field is returned in the response message.
6 Commands for Financial Transaction EMV 4.2 Book 3
6.5 Commands Application Specification

Page 50 June 2008
6.5.1.5 Processing State Returned in the Response Message
'9000' indicates a successful execution of the command, whether the application
was already invalidated or not.
EMV 4.2 Book 3 6 Commands for Financial Transaction
Application Specification 6.5 Commands

June 2008 Page 51
6.5.2 APPLICATION UNBLOCK Command-Response
APDUs
6.5.2.1 Definition and Scope
The APPLICATION UNBLOCK command is a post-issuance command that
rehabilitates the currently selected application.
Following the successful completion of an APPLICATION UNBLOCK command,
the restrictions imposed by the APPLICATION BLOCK command are removed.
6.5.2.2 Command Message
The APPLICATION UNBLOCK command message is coded as shown in Table 7.

Code Value
CLA '8C' or '84'; coding according to the secure messaging
specified in Book 2
INS '18'
P1 '00'; all other values are RFU
P2 '00'; all other values are RFU
Lc Number of data bytes
Data MAC data component; coding according to the secure
messaging specified in Book 2
Le Not present
Table 7: APPLICATION UNBLOCK Command Message
6.5.2.3 Data Field Sent in the Command Message
The data field of the command message contains the MAC data component coded
according to the secure messaging format specified in Book 2.
6.5.2.4 Data Field Returned in the Response Message
No data field is returned in the response message.
6.5.2.5 Processing State Returned in the Response Message
'9000' indicates a successful execution of the command, whether the application
was previously invalidated or not.
6 Commands for Financial Transaction EMV 4.2 Book 3
6.5 Commands Application Specification

Page 52 June 2008
6.5.3 CARD BLOCK Command-Response APDUs
6.5.3.1 Definition and Scope
The CARD BLOCK command is a post-issuance command that permanently
disables all applications in the ICC.
The CARD BLOCK command shall disable all applications in the ICC, including
applications that may be selected implicitly.
Following the successful completion of a CARD BLOCK command, all subsequent
SELECT commands shall return the status bytes SW1 SW2 = '6A81' (‗Function
not supported‘) and perform no other action.
6.5.3.2 Command Message
The CARD BLOCK command message is coded as shown in Table 8.

Code Value
CLA '8C' or '84'; coding according to the secure messaging
specified in Book 2
INS '16'
P1 '00'; all other values are RFU
P2 '00'; all other values are RFU
Lc Number of data bytes
Data MAC data component; coding according to the secure
messaging specified in Book 2
Le Not present
Table 8: CARD BLOCK Command Message
6.5.3.3 Data Field Sent in the Command Message
The data field of the command message contains the MAC data component coded
according to the secure messaging format specified in Book 2.
6.5.3.4 Data Field Returned in the Response Message
No data field is returned in the response message.
EMV 4.2 Book 3 6 Commands for Financial Transaction
Application Specification 6.5 Commands

June 2008 Page 53
6.5.3.5 Processing State Returned in the Response Message
'9000' indicates a successful execution of the command, whether the card was
already blocked or not.
6 Commands for Financial Transaction EMV 4.2 Book 3
6.5 Commands Application Specification

Page 54 June 2008
6.5.4 EXTERNAL AUTHENTICATE Command-Response
APDUs
6.5.4.1 Definition and Scope
The EXTERNAL AUTHENTICATE command asks the application in the ICC to
verify a cryptogram.
The ICC returns the processing state of the command.
6.5.4.2 Command Message
The EXTERNAL AUTHENTICATE command message is coded as shown in
Table 9:

Code Value
CLA '00'
INS '82'
P1 '00'
P2 '00'
Lc 8-16
Data Issuer Authentication Data
Le Not present
Table 9: EXTERNAL AUTHENTICATE Command Message
The reference of the algorithm (P1) of the EXTERNAL AUTHENTICATE
command is coded '00', which means that no information is given. The reference
of the algorithm either is known before issuing the command or is provided in the
data field.
6.5.4.3 Data Field Sent in the Command Message
The data field of the command message contains the value field of tag '91' coded
as follows:
- mandatory first 8 bytes containing the cryptogram
- optional additional 1-8 bytes are proprietary
6.5.4.4 Data Field Returned in the Response Message
No data field is returned in the response message.
EMV 4.2 Book 3 6 Commands for Financial Transaction
Application Specification 6.5 Commands

June 2008 Page 55
6.5.4.5 Processing State Returned in the Response Message
'9000' indicates a successful execution of the command.
'6300' indicates ‗Issuer authentication failed‘.
For further information, see Annex F.
6 Commands for Financial Transaction EMV 4.2 Book 3
6.5 Commands Application Specification

Page 56 June 2008
6.5.5 GENERATE APPLICATION CRYPTOGRAM
Command-Response APDUs
6.5.5.1 Definition and Scope
The GENERATE AC command sends transaction-related data to the ICC, which
computes and returns a cryptogram. This cryptogram shall either be an
Application Cryptogram (AC) as specified in this specification or a proprietary
cryptogram. In both cases, the cryptogram shall be of a type specified in Table 10
(for more details, see section 9).
This command is also used when performing the Combined DDA/Application
Cryptogram Generation (CDA) function as described in Book 2 section 6.6.

Type Abbreviation Meaning
Application Authentication
Cryptogram
AAC Transaction declined
Authorisation Request Cryptogram ARQC Online authorisation
requested
Transaction Certificate TC Transaction approved
Table 10: GENERATE AC Cryptogram Types
The cryptogram returned by the ICC may differ from that requested in the
command message according to an internal process in the ICC (as described in
section 9).
EMV 4.2 Book 3 6 Commands for Financial Transaction
Application Specification 6.5 Commands

June 2008 Page 57
6.5.5.2 Command Message
The GENERATE AC command message is coded as shown in Table 11:

Code Value
CLA '80'
INS 'AE'
P1 Reference control parameter (see Table 12)
P2 '00'
Lc Var.
Data Transaction-related data
Le '00'
Table 11: GENERATE AC Command Message
The reference control parameter of the GENERATE AC command is coded as
shown in Table 12:

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 0 AAC
0 1 TC
1 0 ARQC
1 1 RFU
x RFU
0 CDA signature not requested
1 CDA signature requested
x x x x RFU
Table 12: GENERATE AC Reference Control Parameter
6.5.5.3 Data Field Sent in the Command Message
The content of the data field of the command message is coded according to the
rules for the data object list as defined in section 5.4.
6 Commands for Financial Transaction EMV 4.2 Book 3
6.5 Commands Application Specification

Page 58 June 2008
6.5.5.4 Data Field Returned in the Response Message
The data field of the response message consists of a BER-TLV coded data object.
The coding of the data object shall be according to one of the following two
formats.
- Format 1: The data object returned in the response message is a primitive
data object with tag equal to '80'. The value field consists of the concatenation
without delimiters (tag and length) of the value fields of the data objects
specified in Table 13:

Value Presence
Cryptogram Information Data (CID) M
Application Transaction Counter (ATC) M
Application Cryptogram (AC) M
Issuer Application Data (IAD) O
Table 13: Format 1 GENERATE AC Response Message Data Field
- Format 2: The data object returned in the response message is a constructed
data object with tag equal to '77'. The value field may contain several BER-
TLV coded objects, but shall always include the Cryptogram Information
Data, the Application Transaction Counter, and the cryptogram computed by
the ICC (either an AC or a proprietary cryptogram). The utilisation and
interpretation of proprietary data objects which may be included in this
response message are outside the scope of these specifications.
Format 2 shall be used if the response is being returned in a signature as
specified for the CDA function described in section 6.6 of Book 2. The required
data elements for the response are shown in the appropriate tables in that
section.
EMV 4.2 Book 3 6 Commands for Financial Transaction
Application Specification 6.5 Commands

June 2008 Page 59
For both formats, the Cryptogram Information Data returned by the
GENERATE AC response message is coded as shown in Table 14:

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 0 AAC
0 1 TC
1 0 ARQC
1 1 RFU

x x
Payment System-specific
cryptogram
0 No advice required
1 Advice required
x x x Reason/advice code
0 0 0 No information given
0 0 1 Service not allowed
0 1 0 PIN Try Limit exceeded
0 1 1 Issuer authentication failed
1 x x Other values RFU
Table 14: Coding of Cryptogram Information Data
For the Format 2 response template, if any mandatory data element is missing,
the terminal shall terminate the transaction.
6.5.5.5 Processing State Returned in the Response Message
'9000' indicates a successful execution of the command.
6 Commands for Financial Transaction EMV 4.2 Book 3
6.5 Commands Application Specification

Page 60 June 2008
6.5.6 GET CHALLENGE Command-Response APDUs
6.5.6.1 Definition and Scope
The GET CHALLENGE command is used to obtain an unpredictable number
from the ICC for use in a security-related procedure.
The challenge shall be valid only for the next issued command.
6.5.6.2 Command Message
The GET CHALLENGE command message is coded as shown in Table 15:

Code Value
CLA '00'
INS '84'
P1 '00'
P2 '00'
Lc Not present
Data Not present
Le '00'
Table 15: GET CHALLENGE Command Message
6.5.6.3 Data Field Sent in the Command Message
The data field of the command message is not present.
6.5.6.4 Data Field Returned in the Response Message
The data field of the response message contains an 8-byte unpredictable number
generated by the ICC.
6.5.6.5 Processing State Returned in the Response Message
'9000' indicates a successful execution of the command.
EMV 4.2 Book 3 6 Commands for Financial Transaction
Application Specification 6.5 Commands

June 2008 Page 61
6.5.7 GET DATA Command-Response APDUs
6.5.7.1 Definition and Scope
The GET DATA command is used to retrieve a primitive data object not
encapsulated in a record within the current application.
The usage of the GET DATA command in this specification is limited to the
retrieval of the following primitive data objects that are defined in Annex A and
interpreted by the application in the ICC:
- ATC (tag '9F36')
- Last Online ATC Register (tag '9F13')
- PIN Try Counter (tag '9F17')
- Log Format (tag '9F4F')
6.5.7.2 Command Message
The GET DATA command message is coded as shown in Table 16:

Code Value
CLA '80'
INS 'CA'
P1 P2 '9F36', '9F13', '9F17', or '9F4F'
Lc Not present
Data Not present
Le '00'
Table 16: GET DATA Command Message
6.5.7.3 Data Field Sent in the Command Message
The data field of the command message is not present.
6.5.7.4 Data Field Returned in the Response Message
The data field of the response message contains the primitive data object referred
to in P1 P2 of the command message (in other words, including its tag and its
length).
6 Commands for Financial Transaction EMV 4.2 Book 3
6.5 Commands Application Specification

Page 62 June 2008
6.5.7.5 Processing State Returned in the Response Message
'9000' indicates a successful execution of the command.
EMV 4.2 Book 3 6 Commands for Financial Transaction
Application Specification 6.5 Commands

June 2008 Page 63
6.5.8 GET PROCESSING OPTIONS Command-Response
APDUs
6.5.8.1 Definition and Scope
The GET PROCESSING OPTIONS command initiates the transaction within the
ICC.
The ICC returns the Application Interchange Profile (AIP) and the Application
File Locator (AFL).
6.5.8.2 Command Message
The GET PROCESSING OPTIONS command message is coded as shown in
Table 17:

Code Value
CLA '80'
INS 'A8'
P1 '00'; all other values are RFU
P2 '00'; all other values are RFU
Lc var.
Data Processing Options Data Object List
(PDOL) related data
Le '00'
Table 17: GET PROCESSING OPTIONS Command Message
6.5.8.3 Data Field Sent in the Command Message
The data field of the command message is a data object coded according to the
PDOL provided by the ICC, as defined in section 5.4, and is introduced by the tag
'83'. When the data object list is not provided by the ICC, the terminal sets the
length field of the template to zero. Otherwise, the length field of the template is
the total length of the value fields of the data objects transmitted to the ICC.
6 Commands for Financial Transaction EMV 4.2 Book 3
6.5 Commands Application Specification

Page 64 June 2008
6.5.8.4 Data Field Returned in the Response Message
The data field of the response message consists of a BER-TLV coded data object.
The coding of the data object shall be according to one of the following two
formats.
- Format 1: The data object returned in the response message is a primitive
data object with tag equal to '80'. The value field consists of the concatenation
without delimiters (tag and length) of the value fields of the AIP and the AFL.
The coding of the data object returned in the response message is shown in
Figure 4:

'80' Length Application Interchange
Profile
Application File
Locator
Figure 4: Format 1 GET PROCESSING OPTIONS Response Message Data Field
- Format 2: The data object returned in the response message is a constructed
data object with tag equal to '77'. The value field may contain several BER-
TLV coded objects, but shall always include the AIP and the AFL. The
utilisation and interpretation of proprietary data objects which may be
included in this response message are outside the scope of these
specifications.
The AIP specifies the application functions that are supported by the application
in the ICC and is coded according to Part III.
The AFL consists of the list, without delimiters, of files and related records for
the currently selected application that shall be read according to section 10.2.
For the Format 2 response template, if any mandatory data element is missing,
the terminal shall terminate the transaction.
6.5.8.5 Processing State Returned in the Response Message
'9000' indicates a successful execution of the command.
EMV 4.2 Book 3 6 Commands for Financial Transaction
Application Specification 6.5 Commands

June 2008 Page 65
6.5.9 INTERNAL AUTHENTICATE Command-Response
APDUs
6.5.9.1 Definition and Scope
The INTERNAL AUTHENTICATE command initiates the computation of the
Signed Dynamic Application Data by the card using:
- the challenge data sent from the terminal and
- ICC data and
- a relevant private key stored in the card.
The ICC returns the Signed Dynamic Application Data to the terminal.
6.5.9.2 Command Message
The INTERNAL AUTHENTICATE command message is coded as shown in
Table 18:

Code Value
CLA '00'
INS '88'
P1 '00'
P2 '00'
Lc Length of authentication-related data
Data Authentication-related data
Le '00'
Table 18: INTERNAL AUTHENTICATE Command Message
The reference of the algorithm (P1) of the INTERNAL AUTHENTICATE
command is coded '00', which means that no information is given. The reference
of the algorithm either is known before issuing the command or is provided in the
data field.
6.5.9.3 Data Field Sent in the Command Message
The data field of the command message contains the authentication-related data
proprietary to an application. It is coded according to the DDOL as defined in
Book 2.
6 Commands for Financial Transaction EMV 4.2 Book 3
6.5 Commands Application Specification

Page 66 June 2008
6.5.9.4 Data Field Returned in the Response Message
The data field of the response message consists of a BER-TLV coded data object.
The coding of the data object shall be according to one of the following two
formats.
- Format 1: The data object returned in the response message is a primitive
data object with tag equal to '80'. The value field consists of the value field of
the Signed Dynamic Application Data as specified in Book 2.
- Format 2: The data object returned in the response message is a constructed
data object with tag equal to '77'. The value field may contain several BER-
TLV coded objects, but shall always include the Signed Dynamic Application
Data as specified in Book 2. The utilisation and interpretation of proprietary
data objects which may be included in this response message are outside the
scope of these specifications.
For the Format 2 response template, if any mandatory data element is missing,
the terminal shall terminate the transaction.
Note: To ensure that the INTERNAL AUTHENTICATE response data length is within
the 256 byte limit, the length of the Signed Dynamic Application Data plus the length of
the TLV encoded optional data (if present) shall remain within the limits as specified in
Book 2 Annex D.
6.5.9.5 Processing State Returned in the Response Message
'9000' indicates a successful execution of the command.
EMV 4.2 Book 3 6 Commands for Financial Transaction
Application Specification 6.5 Commands

June 2008 Page 67
6.5.10 PIN CHANGE/UNBLOCK Command-Response APDUs
6.5.10.1 Definition and Scope
The PIN CHANGE/UNBLOCK command is a post-issuance command. Its
purpose is to provide the issuer the capability either to unblock the PIN or to
simultaneously change and unblock the reference PIN.
Upon successful completion of the PIN CHANGE/UNBLOCK command, the card
shall perform the following functions:
- The value of the PIN Try Counter shall be reset to the value of the PIN Try
Limit.
- If requested, the value of the reference PIN shall be set to the new PIN value.
If PIN data is transmitted in the command it shall be enciphered for
confidentiality.
Note: The reference PIN, which is stored within the card, is the one that is associated
with the application and which the card uses to check the Transaction PIN Data
transmitted within the VERIFY command.
6 Commands for Financial Transaction EMV 4.2 Book 3
6.5 Commands Application Specification

Page 68 June 2008
6.5.10.2 Command Message
The PIN CHANGE/UNBLOCK command message is coded as shown in Table 19.

Code Value
CLA '8C' or '84'; coding according to the secure
messaging specified in Book 2
INS '24'
P1 '00'
P2 '00', '01', or '02'
Lc Number of data bytes
Data Enciphered PIN data component, if present,
and MAC data component; coding according to
the secure messaging specified in Book 2
Le Not present
Table 19: PIN CHANGE/UNBLOCK Command Message
P2: If P2 is equal to '00', the reference PIN is unblocked and the PIN Try
Counter is reset to the PIN Try Limit. There is no PIN update, since the
PIN CHANGE/UNBLOCK command does not contain a new PIN value.
The usage of P2 equal to '01' or '02' is reserved for payment systems.
Any other value of P2 allowing PIN unblocking and/or PIN changing is out
of the scope of this specification and shall be described for each payment
system individually.
6.5.10.3 Data Field Sent in the Command Message
The data field of the command message contains the PIN data component, if
present, followed by the MAC data component coded according to the secure
messaging format specified in Book 2.
6.5.10.4 Data Field Returned in the Response Message
No data field is returned in the response message.
6.5.10.5 Processing State Returned in the Response Message
'9000' indicates a successful execution of the command.
EMV 4.2 Book 3 6 Commands for Financial Transaction
Application Specification 6.5 Commands

June 2008 Page 69
6.5.11 READ RECORD Command-Response APDUs
6.5.11.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.
6.5.11.2 Command Message
The READ RECORD command message is coded as shown in Table 20:

Code Value
CLA '00'
INS 'B2'
P1 Record number
P2 Reference control parameter (see Table 21)
Lc Not present
Data Not present
Le '00'
Table 20: READ RECORD Command Message
Table 21 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 21: READ RECORD Command Reference Control Parameter
6.5.11.3 Data Field Sent in the Command Message
The data field of the command message is not present.
6 Commands for Financial Transaction EMV 4.2 Book 3
6.5 Commands Application Specification

Page 70 June 2008
6.5.11.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. For SFIs in the range 1-10, the record is a
BER-TLV constructed data object as defined in Annex B and coded as shown in
Figure 5:

'70' Length Record Template
Figure 5: READ RECORD Response Message Data Field
The response message to READ RECORD for SFIs in the range 11-30 is outside
the scope of this specification, except as specified in section 10.3 and in Annex D.
6.5.11.5 Processing State Returned in the Response Message
'9000' indicates a successful execution of the command.
EMV 4.2 Book 3 6 Commands for Financial Transaction
Application Specification 6.5 Commands

June 2008 Page 71
6.5.12 VERIFY Command-Response APDUs
6.5.12.1 Definition and Scope
The VERIFY command initiates in the ICC the comparison of the Transaction
PIN Data sent in the data field of the command with the reference PIN data
associated with the application. The manner in which the comparison is
performed is proprietary to the application in the ICC.
The VERIFY command applies when the Cardholder Verification Method (CVM)
chosen from the CVM List is an offline PIN, as described in section 10.5.
6.5.12.2 Command Message
The VERIFY command message is coded as shown in Table 22:

Code Value
CLA '00'
INS '20'
P1 '00'
P2 Qualifier of the reference data (see Table 23)
Lc Var.
Data Transaction PIN Data
Le Not present
Table 22: VERIFY Command Message
6 Commands for Financial Transaction EMV 4.2 Book 3
6.5 Commands Application Specification

Page 72 June 2008
Table 23 defines the qualifier of the reference data (P2):

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 0 0 0 0 0 0 0 As defined in ISO/IEC 7816-4
3

1 0 0 0 0 0 0 0 Plaintext PIN, format as defined below
1 0 0 0 0 x x x RFU for this specification
1 0 0 0 1 0 0 0 Enciphered PIN, format as defined in
Book 2
1 0 0 0 1 0 x x RFU for this specification
1 0 0 0 1 1 x x RFU for the individual payment
systems
1 0 0 1 x x x x RFU for the issuer
Table 23: VERIFY Command qualifier of reference data (P2)
The processing of the VERIFY command in the ICC will be defined in
combination with the CVM rules as specified in section 10.5.

3
The value of P2 = ‗00‘ is not used by this specification.
EMV 4.2 Book 3 6 Commands for Financial Transaction
Application Specification 6.5 Commands

June 2008 Page 73
The plaintext offline PIN block shall be formatted as follows:

C N P P P P P/F P/F P/F P/F P/F P/F P/F P/F F F

where:

Name Value
C Control field 4 bit binary number with value of 0010 (Hex '2')
N PIN length 4 bit binary number with permissible values of 0100 to
1100 (Hex '4' to 'C')
P PIN digit 4 bit binary number with permissible values of 0000 to
1001 (Hex '0' to '9')
P/F PIN/filler Determined by PIN length
F Filler 4 bit binary number with a value of 1111 (Hex 'F')
Table 24: Plaintext Offline PIN Block Format
P2 = '00' indicates that no particular qualifier is used. The processing of the
VERIFY command in the ICC should know how to find the PIN data
unambiguously.
6.5.12.3 Data Field Sent in the Command Message
The data field of the command message contains the value field of tag '99'.
6.5.12.4 Data Field Returned in the Response Message
No data field is returned in the response message.
6.5.12.5 Processing State Returned in the Response Message
'9000' indicates a successful execution of the command.
When for the currently selected application the comparison between the
Transaction PIN Data and the reference PIN data performed by the VERIFY
command fails, the ICC shall return SW2 = 'Cx', where 'x' represents the number
of retries still possible. When the card returns 'C0', no more retries are left, and
the CVM shall be blocked. Any subsequent VERIFY command applied in the
context of that application shall then fail with SW1 SW2 = '6983'.
6 Commands for Financial Transaction EMV 4.2 Book 3
6.5 Commands Application Specification

Page 74 June 2008

EMV 4.2 Book 3
Application Specification

June 2008 Page 75
Part III

Debit and Credit
Application Specification
EMV 4.2 Book 3
Application Specification

Page 76 June 2008
EMV 4.2 Book 3
Application Specification

June 2008 Page 77
7 Files for Financial Transaction Interchange
The description of the file structure and commands for accessing the files is found
in Part III of Book 1 (for application selection) and Part II of this book (for the
application elementary files). The definition of each of the data objects is defined
in Annex A.
7.1 Mapping Data Objects
The payment system or issuer will map the appropriate data objects to files
according to their needs, subject to the following restrictions:
- All files accessible using the READ RECORD command as defined in this
specification containing data objects defined in this specification shall use
SFIs in the range 1 to 10. These files:
 Shall be linear files readable using the READ RECORD command as
described in this specification.
 May contain multiple records. Each record is limited to 254 bytes,
including tag and length.
 Each record shall be coded as a constructed data object. The tag of the
constructed data object shall be '70' indicating a template proprietary to
this specification, and the length field shall contain the total length of the
encapsulated data objects.
 Shall contain only data objects defined in this specification and coded in
accordance with the BER-TLV described in Annex B.
 May have access conditions to be satisfied for updates, but must be
readable unconditionally.
- Files with SFIs in the range 11 to 20 are reserved for proprietary data to be
specified by the individual payment systems.
- Files with SFIs in the range 21 to 30 are reserved for proprietary data to be
specified by the issuer.
7 Files for Financial Transaction Interchange EMV 4.2 Book 3
7.2 Mandatory Data Objects Application Specification

Page 78 June 2008
- The AFL determines the files and records to be used for processing a
transaction. The use of the AFL is described in section 10.2. The data objects
listed in Table 25 are used by the offline data authentication algorithm and,
when present, should be located in the first record referenced by the AFL.
4


Tag Value
'8F' Certification Authority Public Key Index
'90' Issuer Public Key Certificate
Table 25: Data Objects Used by the Offline Data Authentication Algorithm
Additional information may be found in complementary payment system
documentation.
7.2 Mandatory Data Objects
Table 26 lists the data objects that must be present in the ICC in files read using
the READ RECORD command. All other data objects defined in this specification
to be resident in such files in the card are optional.

Tag Value Presence
'5F24' Application Expiration Date M
'5A' Application Primary Account Number
(PAN)
M
'8C' Card Risk Management Data Object List 1 M
'8D' Card Risk Management Data Object List 2 M
Table 26: Mandatory Data Objects
Table 27 lists the data objects that must be present if the ICC supports offline
static data authentication (SDA). Table 28 lists the data objects that must be
present if the ICC supports offline dynamic data authentication (DDA and/or
CDA).
5
Offline data authentication is required to support offline transactions but
is optional in cards that support only online transactions.

4
This allows the terminal to optionally perform the hashing necessary for data
authentication in parallel with reading and parsing of data for other purposes.
5
The exception may be that the Issuer Public Key Remainder or the ICC Public Key
Remainder could be absent. This is because if the public key modulus can be recovered in
its entirety from the public key certificate there is no need for a remainder.
EMV 4.2 Book 3 7 Files for Financial Transaction Interchange
Application Specification 7.2 Mandatory Data Objects

June 2008 Page 79

Tag Value
'8F' Certification Authority Public Key Index
'90' Issuer Public Key Certificate
'93' Signed Static Application Data
'92' Issuer Public Key Remainder
'9F32' Issuer Public Key Exponent
Table 27: Data Required for SDA

Tag Value
'8F' Certification Authority Public Key Index
'90' Issuer Public Key Certificate
'92' Issuer Public Key Remainder
'9F32' Issuer Public Key Exponent
'9F46' ICC Public Key Certificate
'9F47' ICC Public Key Exponent
'9F48' ICC Public Key Remainder
'9F49' Dynamic Data Authentication Data Object
List (DDOL)
6

Table 28: Data Required for DDA and/or CDA

6
In case the DDOL is not present in the card, the Default DDOL shall be used instead.
7 Files for Financial Transaction Interchange EMV 4.2 Book 3
7.3 Data Retrievable by GET DATA Command Application Specification

Page 80 June 2008
7.3 Data Retrievable by GET DATA Command
Data objects listed in Table 29 are not retrievable by the READ RECORD
command but are retrieved by the terminal using the GET DATA command as
described in this specification.
Of the objects listed here, only the Application Transaction Counter (ATC) is a
mandatory data object, and it can be retrieved by either the GET DATA
command or in the response to a GENERATE AC command. The terminal
retrieves the ATC via the GET DATA command only if the ICC contains the
Lower Consecutive Offline Limit (LCOL) and Upper Consecutive Offline Limit
(UCOL) data objects. If the issuer does not wish terminal velocity checking to be
performed and omits these data objects, the ICC does not need to support the
GET DATA command, unless the card supports retrieval of the PIN Try Counter
or the Log Format using GET DATA.

Tag Value Presence
'9F36' Application Transaction Counter (ATC) M
'9F17' PIN Try Counter O
'9F13' Last Online ATC Register O
'9F4F' Log Format O
Table 29: Data Objects Retrievable by GET DATA Command
7.4 Data Retrievable by GET PROCESSING
OPTIONS
Data objects listed in Table 30 are not retrievable by the READ RECORD
command but are retrieved by the terminal using the GET PROCESSING
OPTIONS command as described in section 6.5.8. Table 30 defines the data
returned, not the format of the response; section 6.5.8.4 describes the format of
the data when returned by the GET PROCESSING OPTIONS command.

Tag Value Presence
'82' Application Interchange Profile M
'94' Application File Locator M
Table 30: Data Retrievable by GET PROCESSING OPTIONS
EMV 4.2 Book 3 7 Files for Financial Transaction Interchange
Application Specification 7.5 Erroneous or Missing Data in the ICC

June 2008 Page 81
7.5 Erroneous or Missing Data in the ICC
Data objects in the card are classified in section 7.2 as either mandatory or
optional. However, some optional data objects must be present to support
optional functions selected by the issuer or must be present to avoid
inconsistencies if other related data objects are present.
When any mandatory data object is missing, the terminal terminates the
transaction. When an optional data object that is required because of the
existence of other data objects or that is required to support functions that must
be performed due to the setting of bits in the Application Interchange Profile is
missing, the terminal shall set the ‗ICC data missing‘ indicator in the Terminal
Verification Results (TVR) to 1.
Table 31 summarises the conditions under which this bit should be set to 1.
If none of the conditions in Table 31 applies, the terminal shall set the bit to 0.
The setting of this bit is in addition to any other actions specified in other
sections of this Book.
It is up to the issuer to ensure that data in the card is of the correct format, and
no format checking other than that specifically defined is mandated on the part
of the terminal. However, if in the course of normal processing the terminal
recognises that data is incorrectly formatted, the terminal shall terminate the
transaction unless otherwise specified in these specifications. This rule includes
(but is not limited to):
- Constructed data objects that do not parse correctly.
- Dates that are out of range (for example, months that are not in the range
1 to 12).
- Other data that must be in a specific range of values but are not.
- Multiple occurrences of a data object that should only appear once.
- An AFL with no entries.
- An AFL entry with invalid syntax, that is, any one or more of the following:
 An SFI of 0 or 31.
 A starting record number of 0.
 An ending record number less than the starting record number
(byte 3 < byte 2).
 Number of records participating in offline data authentication greater
than the number of records (byte 4 > byte 3 - byte 2 + 1).

7 Files for Financial Transaction Interchange EMV 4.2 Book 3
7.5 Erroneous or Missing Data in the ICC Application Specification

Page 82 June 2008
Name Tag ‘ICC Data Missing’ Shall Be Set If ...
Application
Transaction Counter
(ATC)
'9F36' ATC is not returned by GET DATA command
and both Lower and Upper Consecutive Offline
Limit data objects are present
Cardholder
Verification Method
(CVM) List
'8E' Not present and AIP indicates that cardholder
verification is supported
Certification
Authority Public
Key Index
'8F' Not present and AIP indicates any form of offline
data authentication is supported (SDA, DDA or
CDA)
Issuer Public Key
Certificate
'90' Not present and AIP indicates any form of offline
data authentication is supported (SDA, DDA or
CDA)
Issuer Public Key
Exponent
'9F32' Not present and AIP indicates any form of offline
data authentication is supported (SDA, DDA or
CDA)
Issuer Public Key
Remainder
'92' Not present and AIP indicates any form of offline
data authentication is supported (SDA, DDA or
CDA) and the ‗length of the Issuer Public Key‘,
as recovered from the Issuer Public Key
Certificate, indicates that there was insufficient
space for the entire Issuer‘s Public Key in the
certificate
Last Online
Application
Transaction Counter
(ATC) Register
'9F13' Last Online ATC Register is not returned by
GET DATA command and both Lower and
Upper Consecutive Offline Limits are present
Signed Static
Application Data
'93' Not present and AIP indicates SDA supported
ICC Public Key
Certificate
'9F46' Not present and AIP indicates DDA or CDA
supported
ICC Public Key
Exponent
'9F47' Not present and AIP indicates DDA or CDA is
supported
ICC Public Key
Remainder
'9F48' Not present and AIP indicates DDA or CDA is
supported and the ‗length of the ICC Public Key‘,
as recovered from the ICC Public Key
Certificate, indicates that there was insufficient
space for the entire ICC‘s Public Key in the
certificate
Table 31: ICC Data Missing Indicator Setting
EMV 4.2 Book 3
Application Specification

June 2008 Page 83
8 Transaction Flow
The Application Interchange Profile specifies the application functions that are
supported by the card. The terminal shall attempt to execute only those functions
that the ICC supports. The functions shall be performed according to the
Conditions of Execution as specified in section 10.
Book 1 describes all functionality outside the application layer, including the
selection of the application. The functions described here begin after application
selection has taken place.
The remainder of this book deals with the terminal-to-ICC dialogue on the level
of the application logical functions. Section 8.2 describes a possible transaction
flow.
8.1 Exception Handling
Exceptions to normal processing are described in this Book for specific status
codes returned in the status bytes (SW1, SW2) or for missing data. Unless
otherwise specified in these specifications, any SW1 SW2 returned by the
transport layer to the application layer other than '9000', '63Cx', or '6283' shall
cause termination of the transaction.
7
This requirement applies throughout
these specifications except for the Application Selection process described in
Book 1.
8.2 Example Flowchart
The flowchart in Figure 6 gives an example of a transaction flow that may be
used by a terminal for a normal purchase transaction. This flowchart is only an
example, and the order of processing may differ from that given here. All
restrictions on the order of processing are provided in section 10.


7
Other actions may be taken by prior agreement but are outside the scope of this
specification.
8 Transaction Flow EMV 4.2 Book 3
8.2 Example Flowchart Application Specification

Page 84 June 2008
Initiate
Application
Read
Application
Data
Data
Authentication
Terminal Risk
Management
Processing
Restrictions
Cardholder
Verification
Terminal
Action Analysis
Card Action
Analysis
Completion
Script
Processing
Online /
Offline
Decision
Offline
Online
Online
Processing &
Issuer
Authentication
In this example, Terminal
Risk Management is
performed in parallel with
other functions.

Figure 6: Transaction Flow Example
EMV 4.2 Book 3 8 Transaction Flow
Application Specification 8.3 Additional Functions

June 2008 Page 85
8.3 Additional Functions
Provision has been made in this specification for additional functions beyond
those described here. Such additional functions may be:
- future additions to this specification
- proprietary functions implemented by local or national agreement or by the
individual payment systems
The Application Interchange Profile indicates the functions supported in the ICC
according to this specification. Most of the bits in this data object are reserved for
future use (RFU). When a new function is added, a bit in the Application
Interchange Profile will be allocated to indicate support for the new function, and
this specification will be updated to specify the new function and where it fits
into the transaction flow.
Proprietary functions may be added to the terminal and the ICC application as
long as they do not interfere with processing of terminals and ICCs not
implementing the function. For example, offline dynamic data authentication
based on symmetric keys may be added at local option. Such proprietary
functions, while not described in this specification, are not precluded, as long as
the functions specified herein continue to be supported for all ICCs, including
those not implementing the proprietary functions.
8 Transaction Flow EMV 4.2 Book 3
8.3 Additional Functions Application Specification

Page 86 June 2008
EMV 4.2 Book 3
Application Specification

June 2008 Page 87
9 GENERATE AC Command Coding
The GENERATE AC command format and response codes are described fully in
section 6.5.5. This section describes how the various options and data elements
are used in transaction processing.
Earlier processing
Terminal
decision
Terminal requests
ARQC
Card decision
Card responds
with ARQC
Completed
online?
Authorisation
response code
Terminal requests
TC
Card responds
with TC or AAC
Terminal requests
AAC
Terminal requests
TC
Card responds
with AAC
Card responds
with AAC
Terminal requests
AAC
TAC/IAC
default
Card decision
Card responds
with TC
Card responds
with AAC
Reject
offline
Approve
offline
Online
Offline
approve
Reject
Online
No
Reject
Online
Offline
reject
Approve
Reject
Yes
Approve
Online-only terminals may optionally
skip TAC/IAC Default processing, in
which case processing continues with
‘Terminal requests AAC’


9 GENERATE AC Command Coding EMV 4.2 Book 3
Application Specification

Page 88 June 2008
Figure 7 depicts the interaction between the terminal decisions, ICC decisions,
issuer approval, the GENERATE AC command, and the possible ICC responses.
The complete transaction flow is not shown in these charts, only the GENERATE
AC commands, responses, and associated decisions.
Earlier processing
Terminal
decision
Terminal requests
ARQC
Card decision
Card responds
with ARQC
Completed
online?
Authorisation
response code
Terminal requests
TC
Card responds
with TC or AAC
Terminal requests
AAC
Terminal requests
TC
Card responds
with AAC
Card responds
with AAC
Terminal requests
AAC
TAC/IAC
default
Card decision
Card responds
with TC
Card responds
with AAC
Reject
offline
Approve
offline
Online
Offline
approve
Reject
Online
No
Reject
Online
Offline
reject
Approve
Reject
Yes
Approve
Online-only terminals may optionally
skip TAC/IAC Default processing, in
which case processing continues with
‘Terminal requests AAC’


Figure 7: Use of GENERATE AC Options

EMV 4.2 Book 3 9 GENERATE AC Command Coding
Application Specification 9.1 Command Parameters

June 2008 Page 89
9.1 Command Parameters
The GENERATE AC command parameters provide three different options to the
terminal:
- Request for the generation of a TC
- Request for the generation of an ARQC
- Request for the generation of an AAC
9.2 Command Data
The data field of the GENERATE AC command is not TLV encoded, so it is
imperative that the ICC knows the format of this data when the command is
received. This is achieved by allowing the ICC to specify the format of the data to
be included in the GENERATE AC command using a Card Risk Management
Data Object List (CDOL).
9.2.1 Card Risk Management Data
The CDOL is a data object in the ICC that provides to the terminal a list of data
objects that must be passed from the terminal to the ICC in the GENERATE AC
command. There shall be two CDOLs in the ICC, referred to as CDOL1 (tag '8C')
and CDOL2 (tag '8D'). CDOL1 is used with the first GENERATE AC command,
and CDOL2 is used with the second GENERATE AC command (if used). The
terminal uses the appropriate CDOL and the rules specified in section 5.4 to
build the appropriate data field for the command. It is the responsibility of the
terminal to ensure that current data is used in building the GENERATE AC
command. To this end, the command data should be built immediately prior to
issuing the GENERATE AC command.
9 GENERATE AC Command Coding EMV 4.2 Book 3
9.3 Command Use Application Specification

Page 90 June 2008
9.2.2 Transaction Certificate Data
A CDOL may request a TC Hash Value to be included in the command data of a
GENERATE AC command. The TDOL is a data object that provides to the
terminal a list of data objects to be used in generating the TC Hash Value. The
ICC may contain the TDOL, but there may be a default TDOL in the terminal,
specified by the payment system, for use in case the TDOL is not present in the
ICC. To create the hash value, the terminal shall use the TDOL (if present) or
the default TDOL to create the appropriate value for input to the hash algorithm,
applying the rules specified in section 5.4. If the default TDOL is used, the
terminal shall set the ‗Default TDOL used‘ bit in the TVR to 1. If a default TDOL
is required but is not present in the terminal, a default TDOL with no data
objects in the list shall be assumed. If this event occurs, since the default TDOL
was not used, the terminal shall not set the ‗Default TDOL Used‘ bit in the TVR
to 1.
If the terminal issues a second GENERATE AC command during the processing
of a transaction, the terminal shall ensure that the data provided in the TC Hash
Value is current at the time the command is issued.
9.3 Command Use
Either one or two GENERATE AC commands are issued during the processing of
a transaction according to this specification.
The ICC shall respond to the first GENERATE AC command with any of the
following:
- TC
- ARQC
- AAC
The ICC shall respond to a second GENERATE AC command with either a TC or
an AAC.
The possible responses listed above are in hierarchical order, with a TC being the
highest and an AAC being the lowest. The terminal may request a TC, an ARQC,
or an AAC. If the ICC responds with a cryptogram at a higher level or with a
cryptogram of an undefined type, this indicates a logic error in the ICC. If this
occurs after the first GENERATE AC command in a transaction, the transaction
shall be terminated. If it occurs after the second GENERATE AC command, all
processing for the transaction has been completed, and the cryptogram returned
shall be treated as an AAC.
If the ICC response is an approval (TC) or online authorisation request (ARQC)
and the ‗CDA signature requested‘ bit in the GENERATE AC command is 1, the
ICC shall return the GENERATE AC response in a public key signature as
specified in Book 2 section 6.6.
EMV 4.2 Book 3 9 GENERATE AC Command Coding
Application Specification 9.3 Command Use

June 2008 Page 91
9.3.1 GENERATE AC (First Issuance)
The terminal completes its online/offline decision process with a GENERATE AC
command (see section 6.5.5). The form of the command depends upon the decision
made by the terminal:
- If the terminal decides the transaction might be completed offline, it requests
a TC from the ICC. The ICC shall reply with a TC, an ARQC, or an AAC,
depending upon its own analysis of the transaction.
- If the terminal decides the transaction should go online, it requests an ARQC
from the ICC. The ICC shall reply with an ARQC, or an AAC.
- If the terminal decides to reject the transaction, it requests an AAC from the
ICC. The ICC shall reply with an AAC.
If the ICC responds with a TC or an AAC, the terminal completes the transaction
offline.
If the ICC responds with an ARQC, the terminal attempts to go online, sending
an authorisation request message to the issuer. Included in the authorisation
request message is the ARQC for online card authentication.
9.3.2 GENERATE AC (Second Issuance)
Whether the terminal receives an authorisation response message as a result of
online processing or an approval or rejection by using the Issuer Action Code -
Default, it completes the transaction by requesting either a TC (in the case an
approval was obtained) or an AAC (in case the issuer‘s instruction is to reject the
transaction) from the ICC. If a TC was requested, the ICC shall reply with either
a TC or an AAC. If an AAC was requested, the card shall reply with an AAC.
The ICC shall permit at most two GENERATE AC commands in a transaction. If
the terminal issues more than two, the third and all succeeding GENERATE AC
commands shall end with SW1 SW2 = '6985', and no cryptogram shall be
returned.
EMV 4.2 Book 3
Application Specification

June 2008 Page 93
10 Functions Used in Transaction Processing
The following sections shall be read in conjunction with Book 4, Part II, which
may contain additional terminal-specific requirements.
10.1 Initiate Application Processing
Purpose:
The Initiate Application Processing function:
- informs the ICC that the processing of a new transaction is beginning
- provides to the ICC the terminal-related information about the transaction
- obtains from the ICC the Application Interchange Profile and a list of files
that contain the ICC data to be used in processing the transaction
- determines whether the transaction is allowed
Conditions of Execution:
The terminal shall always execute this function.
Sequence of Execution:
This is the first function performed after Application Selection.
Description:
The terminal shall set all bits in the Transaction Status Information (TSI) and
the Terminal Verification Results (TVR) to 0.
8

The PDOL is a list of tags and lengths of terminal-resident data elements needed
by the ICC in processing the GET PROCESSING OPTIONS command. Only data
elements having the terminal as the source of the data may be referenced in the
PDOL.
If the PDOL does not exist, the GET PROCESSING OPTIONS command uses a
command data field of '8300', indicating that the length of the value field in the
command data is zero.

8
There may be some exceptions in the timing for this. For example, these bits could be
set to 0 at the completion of the previous transaction or prior to application selection of
this transaction. The intent here is that the processing steps as described in the
Application Specification presume the bits have been initialised to 0.
10 Functions Used in Transaction Processing EMV 4.2 Book 3
10.1 Initiate Application Processing Application Specification

Page 94 June 2008
If the PDOL exists, the terminal extracts the PDOL from the FCI of the ADF and
uses it to create a concatenated list of data elements without tags or lengths. The
rules specified in section 5.4 apply to processing of the PDOL. If an amount field
(either Amount, Authorised or Amount, Other) is referenced in the PDOL and the
terminal is unable to provide the amount at this point in transaction processing,
the amount field in the data element list shall be filled with hexadecimal zeroes.
The terminal issues the GET PROCESSING OPTIONS command using either
the command data field of '8300' (if there was no PDOL in the ICC) or a data
object constructed with a tag of '83' and the appropriate length according to
BER-TLV encoding rules and a value field that is the concatenated list of data
elements resulting from processing the PDOL. The card returns either:
- The Application Interchange Profile, the Application File Locator (identifying
the files and records containing the data to be used for the transaction), and
status SW1 SW2 = '9000', or
- Status SW1 SW2 = '6985' (‗Conditions of use not satisfied‘), indicating that
the transaction cannot be performed with this application.
The format of the response message is given in section 6.5.8.
If the status words '6985' are returned, the terminal shall eliminate the current
application from consideration and return to the Application Selection function to
select another application.
EMV 4.2 Book 3 10 Functions Used in Transaction Processing
Application Specification 10.2 Read Application Data

June 2008 Page 95
10.2 Read Application Data
Purpose:
Data contained in files in the ICC are required by the terminal to perform the
various functions used in transaction processing as described in this section. The
terminal must read this data from the ICC.
Conditions of Execution:
The terminal shall always execute this function.
Sequence of Execution:
The Read Application Data function is performed immediately following the
Initiate Application Processing function.
Description:
The terminal shall read the files and records indicated in the AFL using the
READ RECORD command identifying the file by its SFI. If an error prevents the
terminal from reading data from the ICC, the transaction shall be terminated
(see section 8.1).
The AFL is a list identifying the files and records to be used in the processing of a
transaction. The terminal is to read only the records named in the AFL. Each
element of the list corresponds to a file to be read and is structured as follows:
- The five most significant bits of the first byte indicate the SFI. The three least
significant bits of the first byte shall be set to zero.
- The second byte indicates the first (or only) record number to be read for that
SFI. The second byte shall never be set to zero.
- The third byte indicates the last record number to be read for that SFI. Its
value is either greater than or equal to the second byte. When the third byte
is greater than the second byte, all the records ranging from the record
number in the second byte to and including the record number in the third
byte shall be read for that SFI. When the third byte is equal to the second
byte, only the record number coded in the second byte shall be read for that
SFI.
- The fourth byte indicates the number of records involved in offline data
authentication starting with the record number coded in the second byte. The
fourth byte may range from zero to the value of the third byte less the value
of the second byte plus 1.
10 Functions Used in Transaction Processing EMV 4.2 Book 3
10.2 Read Application Data Application Specification

Page 96 June 2008
The terminal shall process each entry in the AFL from left to right. A READ
RECORD command as described in section 6.5.11 shall be issued for each record
between the starting record number and the ending record number, inclusively.
Any SW1 SW2 other than '9000' passed to the application layer as a result of
reading any record shall cause the transaction to be terminated. Records
specified in the AFL to be included in offline data authentication shall be
processed as described in section 10.3.
The terminal shall store all recognised data objects read, whether mandatory or
optional, for later use in the transaction processing. Data objects that are not
recognised by the terminal (that is, their tags are unknown by the terminal) shall
not be stored, but records containing such data objects may still participate in
their entirety in offline data authentication, depending upon the coding of the
AFL.
9

All mandatory data objects shall be present in the card. If any mandatory data
objects are not present, the terminal shall terminate the transaction.
Redundant primitive data objects are not permitted. If the terminal encounters
more than one occurrence of a single primitive data object while reading data
from the ICC, the transaction shall be terminated.
Proprietary data files may or may not conform to this specification. Records in
proprietary files may be represented in the AFL and may participate in offline
data authentication if they are readable without conditions by the READ
RECORD command coded according to this specification. Otherwise, the reading
and processing of proprietary files is beyond the scope of this specification.

9
Payment system-specific tags are interpreted within the context of the application RID.
Issuer-specific tags are interpreted within the context of the Issuer Identification Number
(as defined in ISO/IEC 7812-1). Additionally, to satisfy business requirements such as
proprietary domestic processing, multiple issuers may agree on the definition of a private
class tag. Such tags may be interpreted in the context of other data such as Issuer
Country Code.
EMV 4.2 Book 3 10 Functions Used in Transaction Processing
Application Specification 10.3 Offline Data Authentication

June 2008 Page 97
10.3 Offline Data Authentication
Purpose:
Offline data authentication is performed as specified in Book 2. This specification
describes how it is determined whether offline data authentication will be
performed, what kind of authentication will be performed, and how the success or
failure of authentication affects the transaction flow and data recorded in the
TVR and TSI.
Conditions of Execution:
Availability of data in the ICC to support offline data authentication is optional;
its presence is indicated in the Application Interchange Profile. If both the
terminal and the ICC support offline data authentication, the terminal shall
perform this function. Depending on the capabilities of the card and the terminal,
SDA or DDA or CDA is performed.
If both of the following are true, the terminal shall perform CDA as specified in
Book 2:
- The Application Interchange Profile indicates that the card supports CDA.
- The terminal supports CDA.
If all of the following are true, the terminal shall perform DDA as specified in
Book 2:
- The Application Interchange Profile indicates that the card supports DDA.
- The terminal supports DDA.
- Either the card or terminal (or both) does not support CDA.
If all of the following are true, the terminal shall perform SDA as specified in this
specification:
- The Application Interchange Profile indicates that the card supports SDA.
- The terminal supports SDA.
- Either the card or the terminal (or both) does not support DDA.
- Either the card or terminal (or both) does not support CDA.
If neither SDA nor DDA nor CDA is performed, the terminal shall set the ‗Offline
data authentication was not performed‘ bit in the TVR to 1.
Sequence of Execution:
The terminal shall perform offline data authentication in any order after Read
Application Data but before completion of the terminal action analysis.
10 Functions Used in Transaction Processing EMV 4.2 Book 3
10.3 Offline Data Authentication Application Specification

Page 98 June 2008
Note: Although the terminal shall commence performing CDA before completion of
Terminal Action Analysis, the terminal will not normally finish performing CDA until
after it has received the response to the GENERATE AC command. (This is a necessary
consequence of the design of CDA.)
Description:
SDA authenticates static data put into the card by the issuer. DDA and CDA
authenticate ICC-resident data, data from the terminal, and the card itself.
Input to the authentication process is formed from the records identified by the
AFL, followed by the data elements identified by the optional Static Data
Authentication Tag List (tag '9F4A').
Only those records identified in the AFL as participating in offline data
authentication are to be processed. Records are processed in the same sequence
in which they appear within AFL entries. The records identified by a single AFL
entry are to be processed in record number sequence. The first record begins the
input for the authentication process, and each succeeding record is concatenated
at the end of the previous record.
The records read for offline data authentication shall be TLV-coded with tag
equal to '70'.
The data from each record to be included in the offline data authentication input
depends upon the SFI of the file from which the record was read.
- For files with SFI in the range 1 to 10, the record tag ('70') and the record
length are excluded from the offline data authentication process. All other
data in the data field of the response to the READ RECORD command
(excluding SW1 SW2) is included.
- For files with SFI in the range 11 to 30, the record tag ('70') and the record
length are not excluded from the offline data authentication process. Thus all
data in the data field of the response to the READ RECORD command
(excluding SW1 SW2) is included.
If the records read for offline data authentication are not TLV-coded with tag
equal to '70' then offline data authentication shall be considered to have been
performed and to have failed; that is, the terminal shall set the ‗Offline data
authentication was performed‘ bit in the TSI to 1, and shall set the appropriate
‗SDA failed‘ or ‗DDA failed‘ or ‗CDA failed‘ bit in the TVR.
The bytes of the record are included in the concatenation in the order in which
they appear in the command response.
After all records identified by the AFL have been processed, the Static Data
Authentication Tag List is processed, if it exists. If the Static Data
Authentication Tag List exists, it shall contain only the tag for the Application
Interchange Profile. The tag must represent the AIP available in the current
application. The value field of the AIP is to be concatenated to the current end of
the input string. The tag and length of the AIP are not included in the
concatenation.
EMV 4.2 Book 3 10 Functions Used in Transaction Processing
Application Specification 10.3 Offline Data Authentication

June 2008 Page 99
Building of the input list for offline data authentication is considered the first
step in the offline data authentication process. If the input cannot be built
because of a violation of one of the above rules but offline data authentication
should be performed according to the ‗Conditions of Execution‘ above, offline data
authentication shall be considered to have been performed and to have failed;
that is, the terminal shall set the ‗Offline data authentication was performed‘ bit
in the TSI to 1 and shall set the appropriate ‗SDA failed‘ or ‗DDA failed‘ or ‗CDA
failed‘ bit in the TVR.
See Book 2 for additional steps to be performed for offline data authentication.
If SDA is performed but is unsuccessful, the ‗SDA failed‘ bit in the TVR shall be
set to 1; otherwise it shall be set to 0.
If DDA is performed but is unsuccessful, the ‗DDA failed‘ bit in the TVR shall be
set to 1; otherwise it shall be set to 0.
If CDA is performed but is unsuccessful, the ‗CDA failed‘ bit in the TVR shall be
set to 1; otherwise it shall be set to 0.
Upon completion of the offline data authentication function, the terminal shall
set the ‗Offline data authentication was performed‘ bit in the TSI to 1.
10 Functions Used in Transaction Processing EMV 4.2 Book 3
10.4 Processing Restrictions Application Specification

Page 100 June 2008
10.4 Processing Restrictions
Purpose:
The purpose of the Processing Restrictions function is to determine the degree of
compatibility of the application in the terminal with the application in the ICC
and to make any necessary adjustments, including possible rejection of the
transaction.
Conditions of Execution:
The terminal shall always execute this function.
Sequence of Execution:
Functions described here may be performed at any time after Read Application
Data and prior to completion of the terminal action analysis.
Description:
The Processing Restrictions function comprises the following compatibility
checks:
- Application Version Number
- Application Usage Control
- Application Effective/Expiration Dates Checking
10.4.1 Application Version Number
The application within both the terminal and the ICC shall maintain an
Application Version Number assigned by the payment system. The terminal shall
use the version number in the ICC to ensure compatibility. If the Application
Version Number is not present in the ICC, the terminal shall presume the
terminal and ICC application versions are compatible, and transaction
processing shall continue. If the Application Version Number is present in the
ICC, it shall be compared to the Application Version Number maintained in the
terminal. If they are different, the terminal shall set the ‗ICC and terminal have
different application versions‘ bit in the TVR to 1.
EMV 4.2 Book 3 10 Functions Used in Transaction Processing
Application Specification 10.4 Processing Restrictions

June 2008 Page 101
10.4.2 Application Usage Control
The Application Usage Control indicates restrictions limiting the application
geographically or to certain types of transactions. If this data object is present,
the terminal shall make the following checks:
- If the transaction is being conducted at an ATM, the ‗Valid at ATMs‘ bit must
be on in Application Usage Control.
- If the transaction is not being conducted at an ATM, the ‗Valid at terminals
other than ATMs‘ bit must be on in Application Usage Control.
If the Application Usage Control and Issuer Country Code are both present in the
ICC, the terminal shall make the checks described in Table 32.

If:
and if
Issuer Country Code:
then the following bit must be
set to 1 in
Application Usage Control:
Transaction Type
indicates cash
transaction
matches
Terminal Country Code
‗Valid for domestic cash
transactions‘
does not match
Terminal Country Code
‗Valid for international cash
transactions‘
Transaction Type
indicates
purchase (of
goods/services)
matches
Terminal Country Code
‗Valid for domestic goods‘ and/or
‗Valid for domestic services‘
does not match
Terminal Country Code
‗Valid for international goods‘
and/or ‗Valid for international
services‘
transaction has a
cashback amount
matches
Terminal Country Code
‗Domestic cashback allowed‘
does not match
Terminal Country Code
‗International cashback allowed‘
Table 32: Terminal Action Regarding Application Usage Control
If any of the above tests fail, the terminal shall set the ‗Requested service not
allowed for card product‘ bit in the TVR to 1.
10 Functions Used in Transaction Processing EMV 4.2 Book 3
10.4 Processing Restrictions Application Specification

Page 102 June 2008
10.4.3 Application Effective/Expiration Dates Checking
If the Application Effective Date is present in the ICC, the terminal shall check
that the current date is greater than or equal to the Application Effective Date. If
it is not, the terminal shall set the ‗Application not yet effective‘ bit in the TVR
to 1.
The terminal shall check that the current date is less than or equal to the
Application Expiration Date. If it is not, the terminal shall set the ‗Expired
application‘ bit in the TVR to 1.
EMV 4.2 Book 3 10 Functions Used in Transaction Processing
Application Specification 10.5 Cardholder Verification

June 2008 Page 103
10.5 Cardholder Verification
Purpose:
Cardholder verification is performed to ensure that the person presenting the
ICC is the person to whom the application in the card was issued.
Conditions of Execution:
Ability of the ICC to support at least one cardholder verification method is
indicated in the Application Interchange Profile, as shown in Annex C1. If this
bit is set to 1, the terminal shall use the cardholder verification related data in
the ICC to determine whether one of the issuer-specified cardholder verification
methods (CVMs) shall be executed. This process is described below.
Sequence of Execution:
This function may be performed any time after Read Application Data and before
completion of the terminal action analysis.
Description:
The CVM List (tag '8E') is a composite data object consisting of the following:
1. An amount field (4 bytes, binary format), referred to as ‗X‘ in Table 40: CVM
Condition Codes. ‗X‘ is expressed in the Application Currency Code with
implicit decimal point. For example, 123 (hexadecimal '7B') represents £1.23
when the currency code is '826'.
2. A second amount field (4 bytes, binary format), referred to as ‗Y‘ in Table 40.
‗Y‘ is expressed in Application Currency Code with implicit decimal point. For
example, 123 (hexadecimal '7B') represents £1.23 when the currency code is
'826'.
3. A variable-length list of two-byte data elements called Cardholder
Verification Rules (CV Rules). Each CV Rule describes a CVM and the
conditions under which that CVM should be applied (see Annex C3).
If the CVM List is not present in the ICC, the terminal shall terminate
cardholder verification without setting the ‗Cardholder verification was
performed‘ bit in the TSI.
Note: A CVM List with no Cardholder Verification Rules is considered to be the same as
a CVM List not being present.
If the CVM List is present in the ICC, the terminal shall process each rule in the
order in which it appears in the list according to the following specifications.
Cardholder verification is completed when any one CVM is successfully
performed or when the list is exhausted.
10 Functions Used in Transaction Processing EMV 4.2 Book 3
10.5 Cardholder Verification Application Specification

Page 104 June 2008
If the terminal encounters formatting errors in the CVM List such as a list with
an odd number of bytes (that is, with an incomplete CVM Rule), the terminal
shall terminate the transaction as specified in Book 3 section 7.5.
If any of the following is true:
- the conditions expressed in the second byte of a CV Rule are not satisfied, or
- data required by the condition (for example, the Application Currency Code or
Amount, Authorised) is not present, or
- the CVM Condition Code is outside the range of codes understood by the
terminal (which might occur if the terminal application program is at a
different version level than the ICC application),
then the terminal shall bypass the rule and proceed to the next. If there are no
more CV Rules in the list, cardholder verification has not been successful, and
the terminal shall set the ‗Cardholder verification was not successful‘ bit in the
TVR to 1.
If the conditions expressed in the second byte of the CV Rule are satisfied, the
terminal next checks whether it recognises the CVM coded in the first byte of the
CV Rule and proceeds according to the following steps:
1. If the CVM is recognised, the terminal next checks to determine whether it
supports the CVM.
- If the CVM is supported, the terminal shall attempt to perform it.
o If the CVM is performed successfully, cardholder verification is
complete and successful. If the CVM just processed was ‗Fail CVM
Processing‘, the terminal shall set the ‗Cardholder verification was
not successful‘ bit in the TVR (b8 of byte 3) to 1 and no further
CVMs shall be processed regardless of the setting of b7 of byte 1 in
the first byte of the CV Rule.
10

o If the CVM is not performed successfully, processing continues at
step 2.
- If the CVM is not supported, processing continues at step 2. In case the
CVM was PIN-related, then in addition the terminal shall set the ‗PIN
entry required and PIN pad not present or not working‘ bit (b5 of byte 3)
of the TVR to 1.
If the CVM is not recognised, the terminal shall set the ‗Unrecognised CVM‘
bit in the TVR (b7 of byte 3) to 1 and processing continues at step 2.
2. If cardholder verification was not completed in step 1 (that is, the CVM was
not recognised, was not supported, or failed), the terminal examines b7 of
byte 1 of the CV Rule.

10
If a card CVM List contains an entry for 'Fail CVM Processing,' it is strongly
recommended that byte 1 bit 7 be set to 0 for this entry.
EMV 4.2 Book 3 10 Functions Used in Transaction Processing
Application Specification 10.5 Cardholder Verification

June 2008 Page 105
- If b7 is set to 1, processing continues with the next CV Rule, if one is
present.
- If b7 is set to 0, or there are no more CV Rules in the list, cardholder
verification is complete and unsuccessful. The terminal shall set the
‗Cardholder verification was not successful‘ bit in the TVR (b8 of byte 3) to
1.
When cardholder verification is completed, the terminal shall:
- set the CVM Results according to Book 4 section 6.3.4.5
- set the ‗Cardholder verification was performed‘ bit in the TSI to 1.
10 Functions Used in Transaction Processing EMV 4.2 Book 3
10.5 Cardholder Verification Application Specification

Page 106 June 2008
10.5.1 Offline PIN Processing
This section applies to the verification by the ICC of a plaintext or enciphered
PIN presented by the terminal.
If an offline PIN is the selected CVM as determined by the above process, offline
PIN processing may not be successfully performed for any one of the following
reasons:
- The terminal does not support offline PIN.
11
In this case, the terminal shall
set the ‗PIN entry required and PIN pad not present or not working‘ bit in the
TVR to 1.
- The terminal supports offline PIN, but the PIN pad is malfunctioning. In this
case, the terminal shall set the ‗PIN entry required and PIN pad not present
or not working‘ bit in the TVR to 1.
- The terminal bypassed PIN entry at the direction of either the merchant or
the cardholder.
12
In this case, the terminal shall set the ‗PIN entry required,
PIN pad present, but PIN was not entered‘ bit in the TVR to 1. The terminal
shall consider this CVM unsuccessful and shall continue cardholder
verification processing in accordance with the card‘s CVM List.
- The PIN is blocked upon initial use of the VERIFY command or if recovery of
the enciphered PIN Block has failed (the ICC returns SW1 SW2 = '6983' or
'6984' in response to the VERIFY command). In this case, the terminal shall
set the ‗PIN Try Limit exceeded‘ bit in the TVR to 1.
- The number of remaining PIN tries is reduced to zero (indicated by an
SW1 SW2 of '63C0' in the response to the VERIFY command). In this case,
the terminal shall set the ‗PIN Try Limit exceeded‘ bit in the TVR to 1.
The only case in which offline PIN processing is considered successful is when
the ICC returns an SW1 SW2 of '9000' in response to the VERIFY command.

11
This means that the terminal does not support either offline plaintext PIN verification
or offline enciphered PIN verification. If the terminal supports at least one of these
functions, it is considered to support offline PIN for the purposes of setting the TVR bits.
12
Especially for a new cardholder or during conversion to PINs, it is likely that a
cardholder will realize that he or she does not know the PIN. In this case, it is better to
bypass PIN processing with an indication to the issuer of the circumstances than it is to
either terminate the transaction or try numbers until the PIN try count is exhausted. If
the transaction goes online, the issuer can decide whether to accept the transaction
without the PIN.
EMV 4.2 Book 3 10 Functions Used in Transaction Processing
Application Specification 10.5 Cardholder Verification

June 2008 Page 107
10.5.2 Online PIN Processing
If online PIN processing is a required CVM as determined by the above process,
the processing may not be successfully performed for any one of the following
reasons:
- The terminal does not support online PIN. In this case, the terminal shall set
the ‗PIN entry required and PIN pad not present or not working‘ bit in the
TVR to 1.
- The terminal supports online PIN, but the PIN pad is malfunctioning. In this
case, the terminal shall set the ‗PIN entry required and PIN pad not present
or not working‘ bit in the TVR to 1.
- The terminal bypassed PIN entry at the direction of either the merchant or
the cardholder. In this case, the terminal shall set the ‗PIN entry required,
PIN pad present, but PIN was not entered‘ bit in the TVR to 1.
If the online PIN is successfully entered, the terminal shall set the ‗Online PIN
entered‘ bit in the TVR to 1. In this case, cardholder verification is considered
successful and complete.
10.5.3 Signature Processing
If a (paper) signature is a required CVM as determined by the above process, the
terminal shall determine success based upon the terminal‘s capability to support
the signature process (see complementary payment systems documentation for
additional information). If the terminal is able to support signature, the process
is considered successful, and cardholder verification is complete.
10.5.4 Combination CVMs
Some CVMs require multiple verification methods (for example, offline PIN plus
signature). For these CVMs, all methods in the CVM must be successful for
cardholder verification to be considered successful.
10.5.5 CVM Processing Logic
The flows on the following pages illustrate the CVM processing logic but do not
contain all the details of the execution of the selected CVM.
10 Functions Used in Transaction Processing EMV 4.2 Book 3
10.5 Cardholder Verification Application Specification

Page 108 June 2008
Terminal selects first
or next CV Rule
in CVM List
Terminal
recognises
CVM?
Is CVM Code
Supported? *
CVM
Failed?
Any more
CVM entries?
Set 'Unrecognised
CVM' in TVR
Perform 'Selected
CVM Code is not
Supported' Logic
(See T in Part 2 of
flow)
NO
Perform CVM (See
U in Part 3 - Online PIN
V in Part 3 – Signature
W in Part 3 – No CVM Req’d
X in Part 4 – Offline PIN
Z in Part 5 – Combo. CVM)
YES
NO
Set Cardholder
Verification was
Performed in TSI.
NO
CVM List
Processing
CVM List
Processing
Complete
AIP supports
CVM processing
CVM List
present with CV
rules?
CVM
Condition = 'If
terminal supports
CVM'?
A
B
YES
CV Rule
Byte 1
bit 7 = ...
YES
CVM = Fail CVM
NO
C YES
Set 'Cardholder
verification not
successful' in
TVR.
YES
CVM
Condition rules
satisfied? (See
S in Part 2 of
flow)
YES
Set TVR 'ICC
Data Missing'
NO
'1' - Apply
next CVM
'0' -
Fail CVM
processing
C
* Note:
For EMV
defined codes,
support is
indicated in
Terminal
Capabilities.
For non-EMV
defined codes,
support is
known
implicitly.
For
Combination
CVMs, both
CVMs must be
supported.
D
Set CVM Results
to ‘3F0000’ - 'No
CVM performed'
A
B
YES
Is CVM Code
supported? *
YES
Set CVM Results
to ‘Failed’ (See Y
in Part 5 of flow)
CVM
Failed
CVM
Condition =
'Always'?
NO
YES
C
NO
NO
NO
YES
YES
NO
NO
D

Figure 8: CVM Processing (Part 1 of 5)
EMV 4.2 Book 3 10 Functions Used in Transaction Processing
Application Specification 10.5 Cardholder Verification

June 2008 Page 109
Terminal
understands
CVM Condition?
CVM Condition
satisfied?
CVM
Condition data
available?
YES
YES
'CVM Condition Rules
Satisfied?' Logic
CVM Condition
rules
not satisfied.
CVM Condition rules
satisfied.
YES
NO
NO
'Selected CVM Code Is
Not Supported' Logic
CVM
= Offline
PIN?
CVM
= Online
PIN?
Any form of
Offline PIN
supported?
YES
NO
YES
YES
NO
Set 'PIN entry req'd
but PIN pad not
present or not
working' in TVR.
NO
NO
T
(From Part 1
of flow)
S
(From Part 1
of flow)
Continue with
Part 1 of flow
Continue
with Part 1 of
flow

Figure 9: CVM Processing (Part 2 of 5)
10 Functions Used in Transaction Processing EMV 4.2 Book 3
10.5 Cardholder Verification Application Specification

Page 110 June 2008
Set CVM Results to
'Unknown'
PIN pad is
malfunctioning?
Set terminal to print
signature line on
receipt.
Request PIN entry
Set CVM Results to
'Unknown'
Consider that CVM is
successful
Consider that Online
PIN CVM is
successful
PIN entry
bypassed?
NO
NO
Terminal sets 'PIN
entry req'd but PIN
pad not present or
not working' in TVR.
Terminal sets 'PIN
entry req'd but PIN
was not entered' in
TVR.
YES
YES
Consider that
Online PIN CVM is
not successful
Consider that CVM is
successful
Set CVM Results to
'Successful'
W
(From Part 1
of flow)
V
(From Part 1
of flow)
U
(From Part 1
of flow)
Continue
with Part 1 of
flow
Continue
with Part 1 of
flow
Continue
with Part 1 of
flow
Set ‘Online PIN
Entered’ in TVR to ‘1’
Either bypassed for the current
CVM or (optionally) bypassed
during processing of a previous
PIN-related CVM.

Figure 10: CVM Processing (Part 3 of 5)
EMV 4.2 Book 3 10 Functions Used in Transaction Processing
Application Specification 10.5 Cardholder Verification

June 2008 Page 111
Terminal
issues GET
DATA for PIN Try
Counter?
PIN Try Counter
retrieved?
YES
YES
PIN pad is
malfunctioning?
Ask for PIN
entry
Send enciphered or
plaintext PIN to ICC
in VERIFY command
NO
Set PIN Try
Limit exceeded
in TVR
PIN entry
bypassed? *
NO
NO
Terminal sets 'PIN
entry req'd but PIN
was not entered' in
TVR.
YES
Consider that
Offline PIN CVM
is not successful
PIN Try
Counter = 0?
YES
Offline
Enciphered PIN?
Recover the
public key to be
used for PIN
encipherment .
YES
Encipher PIN
using recovered
ICC key
Terminal sets 'PIN
entry req'd but PIN
pad not present or
not working' in
TVR.
YES
Get unpred. number
from ICC with GET
CHALLENGE
Recovery OK?
GET
CHALLENGE
OK?
YES
YES
SW1SW2
= 63Cx with
x > 0?
Set CVM Results to
'Successful'
YES
SW1SW2
= 9000?
SW1SW2
= 63C0, 6983,
6984?
YES
Terminate
transaction
NO
YES
Consider that Offline
PIN CVM is
successful
E
E
NO
NO
NO
NO
NO
NO
X
(From Part 1
of flow)
Continue
with Part 1 of
flow
Continue
with Part 1 of
flow
* Either bypassed for the
current CVM or (optionally)
bypassed during processing
of a previous PIN-related
CVM.
NO
Offline PIN

Figure 11: CVM Processing (Part 4 of 5)
10 Functions Used in Transaction Processing EMV 4.2 Book 3
10.5 Cardholder Verification Application Specification

Page 112 June 2008
Y
(From Part 1
of flow)
Was any CVM
Condition
satisfied?
Set CVM
Results to
‘3F 00 01‘
NO
Set CVM
Results to
‘Failed’ with the
Method Code
and CVM
Condition
reflecting the
last CVM
performed.
YES
Continue with
Part 1 of flow
Setting CVM Results to Failed Combination CVMs
Z
(From Part 1
of flow)
Perform CVM 1
and CVM 2
(See parts 3
and 4 of flow.)
Both CVMs are
successful?
Result of
either CVM is
‘unknown’?
Continue
with Part 1 of
flow
Consider that
Combination CVM
is successful
Set CVM
Results to
'Unknown'
Consider that
Combination CVM
is unsuccessful
Set CVM
Results to
'Successful'
YES
NO
YES NO
CVM
for satisfied CVM
Condition was
recognised and
supported?
NO

Figure 12: CVM Processing (Part 5 of 5)

EMV 4.2 Book 3 10 Functions Used in Transaction Processing
Application Specification 10.6 Terminal Risk Management

June 2008 Page 113
10.6 Terminal Risk Management
Purpose:
Terminal risk management is that portion of risk management performed by the
terminal to protect the acquirer, issuer, and system from fraud. It provides
positive issuer authorisation for high-value transactions and ensures that
transactions initiated from ICCs go online periodically to protect against threats
that might be undetectable in an offline environment. The result of terminal risk
management is the setting of appropriate bits in the TVR.
Conditions of Execution:
Terminal risk management shall be performed if the ‗Terminal risk management
is to be performed ‘ bit in the Application Interchange Profile is set to 1. Random
transaction selection need not be performed by a terminal with no online
capability. If terminal risk management is not performed, sections 10.6.1 through
10.6.3 do not apply.
Note: To better control local risk management, terminals may perform terminal risk
management even when the ‗Terminal risk management is to be performed‘ bit in the
Application Interchange Profile is set to 0.
Sequence of Execution:
Terminal risk management may be performed at any time after Read Application
Data but before issuing the first GENERATE AC command.
Description:
Terminal risk management consists of:
- Floor limit checking
- Random transaction selection
- Velocity checking
Upon completion of terminal risk management, the terminal shall set the
‗Terminal risk management was performed‘ bit in the TSI to 1.
10 Functions Used in Transaction Processing EMV 4.2 Book 3
10.6 Terminal Risk Management Application Specification

Page 114 June 2008
10.6.1 Floor Limits
To prevent split sales, the terminal may have a transaction log of approved
transactions stored in the terminal consisting of at least the Application PAN
and transaction amount and possibly the Application PAN Sequence Number and
Transaction Date. The number of transactions to be stored and maintenance of
the log are outside the scope of this specification, although to prevent split sales
the number of transactions stored may be quite small.
During terminal risk management floor limit checking, the terminal checks the
transaction log (if available) to determine if there is a log entry with the same
Application PAN, and, optionally, the same Application PAN Sequence Number.
If there are several log entries with the same PAN, the terminal selects the most
recent entry. The terminal adds the Amount, Authorised for the current
transaction to the amount stored in the log for that PAN to determine if the sum
exceeds the Terminal Floor Limit. If the sum is greater than or equal to the
Terminal Floor Limit, the terminal shall set the ‗Transaction exceeds floor limit‘
bit in the TVR to 1.
If the terminal does not have a transaction log available or if there is no log entry
with the same PAN, the Amount, Authorised is compared to the appropriate floor
limit. If the amount authorised is equal to or greater than the floor limit, the
terminal sets the ‗Transaction exceeds floor limit‘ bit to 1 in the TVR.
10.6.2 Random Transaction Selection
For each application the relevant payment system specifies, in addition to the
floor limit:
- ‗Target Percentage to be Used for Random Selection‘ (in the range of 0 to 99)
- Threshold Value for Biased Random Selection (which must be zero or a
positive number less than the floor limit)
- ‗Maximum Target Percentage to be Used for Biased Random Selection‘ (also
in the range of 0 to 99 but at least as high as the previous ‗Target Percentage
to be Used for Random Selection‘). This is the desired percentage of
transactions ‗just below‘ the floor limit that will be selected by this algorithm.
Any transaction with a transaction amount less than the Threshold Value for
Biased Random Selection will be subject to selection at random without further
regard for the value of the transaction. The terminal shall generate a random
number in the range of 1 to 99. If this random number is less than or equal to the
‗Target Percentage to be used for Random Selection‘, the transaction shall be
selected.
EMV 4.2 Book 3 10 Functions Used in Transaction Processing
Application Specification 10.6 Terminal Risk Management

June 2008 Page 115
Any transaction with a transaction amount equal to or greater than the
Threshold Value for Biased Random Selection but less than the floor limit will be
subject to selection with bias toward sending higher value transactions online
more frequently (biased random selection). For these transactions, the terminal
shall compare its generated random number against a Transaction Target
Percent, which is a linear interpolation of the target percentages provided by the
payment system (‗Target Percentage to be used for Random Selection‘ and
‗Maximum Target Percentage to be used for Biased Random Selection‘).
13
If the
random number is less than or equal to the Transaction Target Percent, the
transaction shall be selected.
Figure 13 illustrates the probability of selection as a function of the transaction
amount:

Floor
Limit
Biased
Selection
Threshold
P
r
o
b
a
b
i
l
i
t
y

o
f

S
e
l
e
c
t
i
o
n
0
1

Figure 13: Random Transaction Selection Example
If the transaction is selected through the process described in this section, the
terminal shall set the ‗Transaction selected randomly for online processing‘ bit in
the TVR to 1.

13
The Transaction Target Percent is calculated as follows:
Int erpolat ion fact or
Amount , Aut horised Threshold Value
Floor Limit Threshold Value
=
÷
÷
( ) ( )
Transact ion Target Percent = Maximum Target Percent - Target Percent Int erpolat ion fact or
Target Percent
×
+

10 Functions Used in Transaction Processing EMV 4.2 Book 3
10.6 Terminal Risk Management Application Specification

Page 116 June 2008
10.6.3 Velocity Checking
If both the Lower Consecutive Offline Limit (tag '9F14') and Upper Consecutive
Offline Limit (tag '9F23') exist, the terminal shall perform velocity checking as
described in this section.
14
If either of these data objects is not present in the ICC
application, the terminal shall skip this section.
The ATC and Last Online ATC Register shall be read from the ICC using
GET DATA commands. If either of the required data objects is not returned by
the ICC in response to the GET DATA command, or if the value of the ATC is
less than or equal to the value in the Last Online ATC Register, the terminal
shall:
- Set both the ‗Lower consecutive offline limit exceeded‘ and the ‗Upper
consecutive offline limit exceeded‘ bits in the TVR to 1.
- Not set the ‗New card‘ indicator in the TVR unless the Last Online ATC
Register is returned and equals zero.
- End velocity checking for this transaction.
If the required data objects are available, the terminal shall compare the
difference between the ATC and the Last Online ATC Register with the Lower
Consecutive Offline Limit to see if the limit has been exceeded. If the difference is
equal to the Lower Consecutive Offline Limit, this means that the limit has not
yet been exceeded. If the limit has been exceeded, the terminal shall set the
‗Lower consecutive offline limit exceeded‘ bit in the TVR to 1 and also compare
the difference with the Upper Consecutive Offline Limit to see if the upper limit
has been exceeded. If it has, the terminal shall set the ‗Upper consecutive offline
limit exceeded‘ bit in the TVR to 1.
The terminal shall also check the Last Online ATC Register for a zero value. If it
is zero, the terminal shall set the ‗New card‘ bit in the TVR to 1.

14
The purpose of velocity checking is to allow an issuer to request that, after a certain
number of consecutive offline transactions (the Lower Consecutive Offline Limit),
transactions should be completed online. However, if the terminal is incapable of going
online, transactions may still be completed offline until a second (Upper Consecutive
Offline Limit) limit is reached. After the upper limit is reached, the recommendation of
the issuer might be to reject any transaction that cannot be completed online. Once a
transaction has been completed online with successful issuer authentication, the count
begins anew, so that transactions may be processed offline until the lower limit is again
reached.
EMV 4.2 Book 3 10 Functions Used in Transaction Processing
Application Specification 10.7 Terminal Action Analysis

June 2008 Page 117
10.7 Terminal Action Analysis
Purpose:
Once terminal risk management and application functions related to a normal
offline transaction have been completed, the terminal makes the first decision as
to whether the transaction should be approved offline, declined offline, or
transmitted online.
- If the outcome of this decision process is to proceed offline, the terminal issues
a GENERATE AC command to ask the ICC to return a TC.
- If the outcome of the decision is to go online, the terminal issues a
GENERATE AC command to ask the ICC for an Authorisation Request
Cryptogram (ARQC).
- If the decision is to reject the transaction, the terminal issues a GENERATE
AC to ask for an Application Authentication Cryptogram (AAC).
An offline decision made here is not final. If the terminal asks for a TC from the
ICC, the ICC, as a result of card risk management, may return an ARQC or AAC.
Conditions of Execution:
The terminal action analysis function is always performed.
Sequence of Execution:
The terminal action analysis function is performed after terminal risk
management and cardholder and/or merchant transaction data entry has been
completed. It shall be performed prior to the first use of the GENERATE AC
command.
The Issuer Action Code - Default and Terminal Action Code - Default processing
described below shall also be performed after online processing is attempted in
the case where the terminal was unable to process the transaction online.
The terminal action analysis function may be executed at several places during a
transaction to eliminate the need for unnecessary processing. If any processing
results in the setting of a bit in the TVR (for example, failure of cardholder
verification), it may be desirable to perform this function immediately to
determine whether the transaction should be rejected offline based upon the
issuer‘s parameters in the ICC or the acquirer‘s parameters in the terminal.
Recognition of such a decision early in processing may allow the terminal to avoid
prolonging a transaction that will ultimately be rejected. Multiple execution of
this decision process is optional on the part of the terminal.
10 Functions Used in Transaction Processing EMV 4.2 Book 3
10.7 Terminal Action Analysis Application Specification

Page 118 June 2008
Description:
The terminal shall make a preliminary decision to reject the transaction,
complete it online, or complete it offline based upon the TVR, issuer action
preferences, and acquirer action preferences according to the method described in
this section.
The ICC contains (optionally) three data elements to reflect the issuer‘s selected
action to be taken based upon the content of the TVR. Each of the three data
elements has defaults specified here in case any of these data elements are
absent from the ICC. The three data elements are:
- Issuer Action Code - Denial
- Issuer Action Code - Online
- Issuer Action Code - Default
Collectively, these three data objects are termed the Issuer Action Codes. The
purpose of each is described in this section. The format of each is identical and
mirrors the TVR. Each has one bit corresponding to each bit in the TVR, and the
Issuer Action Code (IAC) bit specifies an action to be taken if the corresponding
bit in the TVR is set to 1. Thus, the size and format of each of the Issuer Action
Codes is identical to the TVR.
Similarly, the terminal may contain three data elements to reflect the acquirer‘s
selected action to be taken based upon the content of the TVR. These data
elements are:
- Terminal Action Code - Denial
- Terminal Action Code - Online
- Terminal Action Code - Default
Collectively, these three data objects are termed the Terminal Action Codes. The
purpose of each is described in this section. The format of each is identical and
mirrors the TVR. Each has one bit corresponding to each bit in the TVR, and the
Terminal Action Code (TAC) bit specifies an action to be taken if the
corresponding bit in the TVR is set to 1. Thus, the size and format of each of the
Terminal Action Codes is identical to the TVR and to the Issuer Action Codes.
The existence of each of the Terminal Action Codes is optional. In the absence of
any Terminal Action Code, a default value consisting of all bits set to 0 is to be
used in its place. However, it is strongly recommended that as a minimum, the
Terminal Action Code - Online and Terminal Action Code - Default should be
included with the bits corresponding to ‗Offline data authentication was not
performed‘, and either ‗SDA failed‘, or ‗DDA failed‘ or ‗CDA failed‘ set to 1.
15


15
This protects against a fraudulent card with all the bits in the Issuer Action Code set to
0. Without this protection, such a card could be created with no possibility of going online
or declining transactions. All transactions would be approved offline.
EMV 4.2 Book 3 10 Functions Used in Transaction Processing
Application Specification 10.7 Terminal Action Analysis

June 2008 Page 119
Processing of the action codes is done in pairs, that is, the Issuer Action Code -
Denial is processed together with the Terminal Action Code - Denial, the Issuer
Action Code - Online is processed together with the Terminal Action Code -
Online, and the Issuer Action Code - Default is processed together with the
Terminal Action Code - Default. Processing of the action codes shall be performed
in the order specified here.
If the Issuer Action Code - Denial does not exist, a default value with all bits set
to 0 is to be used. Together, the Issuer Action Code - Denial and the Terminal
Action Code - Denial specify the conditions that cause denial of a transaction
without attempting to go online. If either data object exists, the terminal shall
inspect each bit in the TVR. For each bit in the TVR that has a value of 1, the
terminal shall check the corresponding bits in the Issuer Action Code - Denial
and the Terminal Action Code - Denial. If the corresponding bit in either of the
action codes is set to 1, it indicates that the issuer or the acquirer wishes the
transaction to be rejected offline. In this case, the terminal shall issue a
GENERATE AC command to request an AAC from the ICC. This AAC may be
presented to the issuer to prove card presence during this transaction, but details
of handling a rejected transaction are outside the scope of this specification.
If the Issuer Action Code - Online is not present, a default value with all bits set
to 1 shall be used in its place. Together, the Issuer Action Code - Online and the
Terminal Action Code - Online specify the conditions that cause a transaction to
be completed online. These data objects are meaningful only for terminals
capable of online processing. Offline-only terminals may skip this test and
proceed to checking the Issuer Action Code - Default and Terminal Action Code -
Default, described below. For an online-only terminal, if it has not already
decided to reject the transaction as described above, it shall continue transaction
processing online, and shall issue a GENERATE AC command requesting an
ARQC from the card. For a terminal capable of online processing, if the terminal
has not already decided to reject the transaction as described above, the terminal
shall inspect each bit in the TVR. For each bit in the TVR that has a value of 1,
the terminal shall check the corresponding bits in both the Issuer Action Code -
Online and the Terminal Action Code - Online. If the bit in either of the action
codes is set to 1, the terminal shall complete transaction processing online and
shall issue a GENERATE AC command requesting an ARQC from the ICC.
Otherwise, the terminal shall issue a GENERATE AC command requesting a TC
from the ICC.
10 Functions Used in Transaction Processing EMV 4.2 Book 3
10.7 Terminal Action Analysis Application Specification

Page 120 June 2008
If the Issuer Action Code - Default does not exist, a default value with all bits set
to 1 shall be used in its place. Together, the Issuer Action Code - Default and the
Terminal Action Code - Default specify the conditions that cause the transaction
to be rejected if it might have been approved online but the terminal is for any
reason unable to process the transaction online. The Issuer Action Code - Default
and the Terminal Action Code - Default are used only if the Issuer Action Code -
Online and the Terminal Action Code - Online were not used (for example, in
case of an offline-only terminal) or indicated a desire on the part of the issuer or
the acquirer to process the transaction online but the terminal was unable to go
online. In the event that an online-only terminal was unable to successfully go
online, it may optionally skip TAC/IAC Default processing (shown in Figure 7 for
a transaction that was not completed on-line)
16
. If an online-only terminal does
skip TAC/IAC Default processing, it shall request an AAC with the second
GENERATE AC command. If the terminal has not already rejected the
transaction and the terminal is for any reason unable to process the transaction
online, the terminal shall use this code to determine whether to approve or reject
the transaction offline. If any bit in Issuer Action Code - Default or the Terminal
Action Code - Default and the corresponding bit in the TVR are both set to 1, the
transaction shall be rejected and the terminal shall request an AAC to complete
processing. If no such condition appears, the transaction may be approved offline,
and a GENERATE AC command shall be issued to the ICC requesting a TC.
If CDA is to be performed (as described in section 10.3 of this book and section
6.6 of Book 2), the terminal shall set the bit for ‗CDA Signature Requested‘ in the
GENERATE AC command to 1.

16
Note that if an online-only terminal is unable to successfully go online and TAC/IAC
Default processing is optionally performed, this could result in a TC being requested with
the second GENERATE AC command (depending upon the TAC/IAC Default settings).
EMV 4.2 Book 3 10 Functions Used in Transaction Processing
Application Specification 10.8 Card Action Analysis

June 2008 Page 121
10.8 Card Action Analysis
Purpose:
An ICC may perform its own risk management to protect the issuer from fraud or
excessive credit risk. Details of card risk management algorithms within the ICC
are specific to the issuer and are outside the scope of this specification, but as a
result of the risk management process, an ICC may decide to complete a
transaction online or offline or reject the transaction. The ICC may also decide
that an advice message should be sent to the issuer to inform the issuer of an
exceptional condition.
Conditions of Execution:
The card online/offline decision is specified by its response to the GENERATE AC
command. Therefore, this section applies to all transactions. Whether the ICC
performs any risk management tests is transparent to the terminal and outside
the scope of this specification.
Sequence of Execution:
The card action analysis process is performed when the terminal issues the
GENERATE AC command for a given transaction.
Description:
The result of risk management performed by the ICC is a decision for one of the
following actions to be taken by the terminal:
- Approve the transaction offline. This option is available to the ICC only if the
terminal has made a preliminary decision to complete the transaction offline,
as described in section 10.7.
- Complete the transaction online.
- Reject the transaction.
The decision by the ICC is made known to the terminal by returning a TC, an
ARQC, or an AAC to the terminal in response to a GENERATE AC command, as
described in section 6.5.5.
Upon the completion of the card action analysis function, the terminal shall set
the ‗Card risk management was performed‘ bit in the TSI to 1.
10 Functions Used in Transaction Processing EMV 4.2 Book 3
10.8 Card Action Analysis Application Specification

Page 122 June 2008
10.8.1 Terminal Messages for an AAC
An AAC returned by the card indicates either a rejection of the specific
transaction or a restriction that disallows use of the card in the environment of
the transaction (for example, the card application may be restricted only to
specific merchant categories). In both cases, the card disapproves the transaction,
but the terminal may choose to display different messages in the two cases. The
card may optionally distinguish the cases by the use of the code returned in the
Cryptogram Information Data (see the GENERATE AC command in
section 6.5.5). If an AAC is returned with b3-b1 = '001' in the Cryptogram
Information Data, the AAC was returned due to card restrictions.
10.8.2 Advice Messages
The issuer may wish for an advice message, separate from either an
authorisation request or a clearing message, to be sent in certain exception cases.
(Currently, the only identified such case is ‗PIN Try Limit exceeded‘, but
allowance has been made for the addition of other cases later; see Table 14).
If b4 of the Cryptogram Information Data is 1, the terminal shall process the
transaction as shown in Book 4, sections 6.3.7 and 12.2.5. Further information
may be found in complementary payment system documentation.
EMV 4.2 Book 3 10 Functions Used in Transaction Processing
Application Specification 10.9 Online Processing

June 2008 Page 123
10.9 Online Processing
Purpose:
Online processing is performed to ensure that the issuer can review and
authorise or reject transactions that are outside acceptable limits of risk defined
by the issuer, the payment system, or the acquirer.
Conditions of Execution:
Online processing shall be performed if the ICC returns an ARQC in response to
the first GENERATE AC command for the transaction.
Sequence of Execution:
The online processing function is performed when the terminal receives an ARQC
in response to the first GENERATE AC command.
Description:
In general, online processing is the same as online processing of magnetic stripe
transactions and is not described here. This section is limited to the additional
online processing provided in an ICC environment that is not available in a
magnetic stripe environment.
The ARQC may be sent in the authorisation request message.
18
The
authorisation response message from the issuer may contain the Issuer
Authentication Data (tag '91'). If the Issuer Authentication Data is received in
the authorisation response message and the Application Interchange Profile
indicates that the ICC supports issuer authentication, the Issuer Authentication
Data shall be sent to the ICC in the EXTERNAL AUTHENTICATE command. If
the ICC responds with SW1 SW2 other than '9000', the terminal shall set the
‗Issuer authentication failed‘ bit in the TVR to 1.

18
Actions performed by the acquirer or issuer systems are outside the scope of this
specification. However, an explanation of what is expected to take place at the issuer may
be useful for clarity. The ARQC is a cryptogram generated by the card from transaction
data using an issuer key stored in the card and known at the issuer authorisation system.
The issuer uses this key to authenticate the ARQC and thereby authenticate the card.
This process is termed ‗online card authentication‘ or simply ‗card authentication‘.
Subsequent to card authentication, the issuer may generate a cryptogram on selected
data included in the authorisation response or already known to the card. This
cryptogram is sent to the terminal in the authorisation response as part of the Issuer
Authentication Data. The terminal provides the Issuer Authentication Data to the ICC in
the EXTERNAL AUTHENTICATE command or the second GENERATE AC command,
as described in Part I. The ICC may use the Issuer Authentication Data to authenticate
that the response message originated from the issuer.
10 Functions Used in Transaction Processing EMV 4.2 Book 3
10.9 Online Processing Application Specification

Page 124 June 2008
If the Issuer Authentication Data is received but the Application Interchange
Profile indicates that the ICC does not support issuer authentication, this
indicates that the ICC has combined the issuer authentication function with the
GENERATE AC command. In this case, or if no Issuer Authentication Data is
received, the terminal shall not execute the EXTERNAL AUTHENTICATE
command.
The ICC shall permit at most one EXTERNAL AUTHENTICATE command in a
transaction. If the terminal issues more than one, the second and all succeeding
EXTERNAL AUTHENTICATE commands shall end with SW1 SW2 = '6985'.
Upon completion of online processing, if the EXTERNAL AUTHENTICATE
command was sent to the card by the terminal, the terminal shall set the ‗Issuer
authentication was performed‘ bit in the TSI to 1.
Note: Annex F provides additional information about status words to be returned in
response to an EXTERNAL AUTHENTICATE command.
EMV 4.2 Book 3 10 Functions Used in Transaction Processing
Application Specification 10.10 Issuer-to-Card Script Processing

June 2008 Page 125
10.10 Issuer-to-Card Script Processing
Purpose:
An issuer may provide command scripts to be delivered to the ICC by the
terminal to perform functions that are not necessarily relevant to the current
transaction but are important for the continued functioning of the application in
the ICC. Multiple scripts may be provided with an authorisation response, and
each may contain any number of Issuer Script Commands. Script processing is
provided to allow for functions that are outside the scope of this specification but
are nonetheless necessary.
19

A script may contain Issuer Script Commands not known to the terminal, but the
terminal shall deliver each command to the ICC individually according to this
specification.
Conditions of Execution:
None.
Sequence of Execution:
Two separate script tags are available for use by the issuer. Issuer scripts with
tag '71' shall be processed prior to issuing the final GENERATE AC command.
Issuer scripts with tag '72' shall be processed after issuing the final
GENERATE AC command.

19
An example might be unblocking of an offline PIN, which might be done differently by
various issuers or payment systems.
10 Functions Used in Transaction Processing EMV 4.2 Book 3
10.10 Issuer-to-Card Script Processing Application Specification

Page 126 June 2008
Description:
An Issuer Script is a constructed data object (tag '71' or '72') containing
(optionally) a Script Identifier and a sequence of Issuer Script Command APDUs
to be delivered serially to the ICC. The Script Identifier is optional and is not
interpreted by the terminal; it is meaningful only to the issuer. Figure 14 and
Figure 15 illustrate an Issuer Script containing a Script Identifier and three
commands.

T L T L Script ID Commands
'71' or
'72'
L(¿data, including Script
ID, tags, and lengths)
'9F18' '04' Identifier
(4 bytes)
(see Figure 15)
Figure 14: Issuer Script Format

T
1
L
1
V
1
T
2
L
2
V
2
T
3
L
3
V
3

'86' L(V
1
) Command '86' L(V
2
) Command '86' L(V
3
) Command
Figure 15: Issuer Script Command Format (Shown with Three Commands)
It is possible for multiple Issuer Scripts to be delivered with a single
authorisation response. The terminal shall process each Issuer Script in the
sequence in which it appears in the authorisation response according to the
following rules:
- Issuer Script Commands shall be separated using the BER-TLV coding of the
data objects defining the commands (tag '86').
- Each command shall be delivered to the ICC as a command APDU in the
sequence in which it appeared in the Issuer Script.
- The terminal shall examine only SW1 in the response APDU and perform one
of the following actions:
 If SW1 indicates either normal processing or a ‗warning‘ according to the
conventions described in this specification, the terminal shall continue
with the next command from the Issuer Script (if any).
 If SW1 indicates an ‗error‘ condition, the processing of the Issuer Script
shall be terminated.
If an Issuer Script is processed, the terminal shall set the ‗Script processing was
performed‘ bit in the TSI to 1. If an error occurred in processing a script, the
terminal shall set to 1 either the ‗Script processing failed before final
GENERATE AC‘ in the TVR if the identifying tag of the failing script was '71' or
the ‗Script processing failed after final GENERATE AC‘ in the TVR if the tag
was '72'.
Note: Annex E discusses TVR and TSI bit settings following script processing.
EMV 4.2 Book 3 10 Functions Used in Transaction Processing
Application Specification 10.11 Completion

June 2008 Page 127
10.11 Completion
Purpose:
The completion function closes processing of a transaction.
Conditions of Execution:
The terminal always performs this function unless the transaction is terminated
prematurely by error processing.
Sequence of Execution:
The completion function is always the last function in the transaction processing.
(Script processing may be performed after the completion function.)
Description:
The ICC indicates willingness to complete transaction processing by returning
either a TC or an AAC to either the first or second GENERATE AC command
issued by the terminal. If the terminal decides to go online, completion shall be
done when the second GENERATE AC command is issued.
If the terminal is to perform CDA (as described in section 10.3), the terminal
shall set the ‗CDA signature requested‘ bit in the GENERATE AC command to 1.
See section 9 for additional information on the use of the GENERATE AC
command.

EMV 4.2 Book 3
Application Specification

June 2008 Page 129
Part IV

Annexes
EMV 4.2 Book 3
Application Specification

Page 130 June 2008
EMV 4.2 Book 3
Application Specification

June 2008 Page 131
Annex A Data Elements Dictionary
Table 33 defines those data elements that may be used for financial transaction interchange and their mapping onto data
objects and files. Table 34 lists the data elements in tag sequence.
The characters used in the ―Format‖ column are described in section 4.3, Data Element Format Convention.
A1 Data Elements by Name
Name Description Source Format Template Tag Length
Account Type Indicates the type of account selected on the
terminal, coded as specified in Annex G
Terminal n 2 — ‗5F57‘ 1
Acquirer
Identifier
Uniquely identifies the acquirer within each
payment system
Terminal n 6-11 — '9F01' 6
Additional
Terminal
Capabilities
Indicates the data input and output
capabilities of the terminal
Terminal b — '9F40' 5
Amount,
Authorised
(Binary)
Authorised amount of the transaction
(excluding adjustments)
Terminal b — '81' 4
Table 33: Data Elements Dictionary
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 132
Name Description Source Format Template Tag Length
Amount,
Authorised
(Numeric)
Authorised amount of the transaction
(excluding adjustments)
Terminal n 12 — '9F02' 6
Amount, Other
(Binary)
Secondary amount associated with the
transaction representing a cashback amount
Terminal b — '9F04' 4
Amount, Other
(Numeric)
Secondary amount associated with the
transaction representing a cashback amount
Terminal n 12 — '9F03' 6
Amount,
Reference
Currency
Authorised amount expressed in the reference
currency
Terminal b — '9F3A' 4
Application
Cryptogram
Cryptogram returned by the ICC in response of
the GENERATE AC command
ICC b '77' or '80' '9F26' 8
Application
Currency Code
Indicates the currency in which the account is
managed according to ISO 4217
ICC n 3 '70' or '77' '9F42' 2
Application
Currency
Exponent
Indicates the implied position of the decimal
point from the right of the amount represented
according to ISO 4217
ICC n 1 '70' or '77' '9F44' 1
Application
Discretionary
Data
Issuer or payment system specified data
relating to the application
ICC b '70' or '77' '9F05' 1-32
Application
Effective Date
Date from which the application may be used ICC n 6
YYMMDD
'70' or '77' '5F25' 3
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 133
Name Description Source Format Template Tag Length
Application
Expiration Date
Date after which application expires ICC n 6
YYMMDD
'70' or '77' '5F24' 3
Application File
Locator (AFL)
Indicates the location (SFI, range of records) of
the AEFs related to a given application
ICC var. '77' or '80' '94' var. up
to 252
Application
Identifier (AID) –
card
Identifies the application as described in
ISO/IEC 7816-5
ICC b '61' '4F' 5-16
Application
Identifier (AID) –
terminal
Identifies the application as described in
ISO/IEC 7816-5
Terminal b — '9F06' 5-16
Application
Interchange
Profile
Indicates the capabilities of the card to support
specific functions in the application
ICC b '77' or '80' '82' 2
Application
Label
Mnemonic associated with the AID according
to ISO/IEC 7816-5
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
Primary Account
Number (PAN)
Valid cardholder account number ICC cn
var. up to
19
'70' or '77' '5A' var. up
to 10
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 134
Name Description Source Format Template Tag Length
Application
Primary Account
Number (PAN)
Sequence
Number
Identifies and differentiates cards with the
same PAN
ICC n 2 '70' or '77' '5F34' 1
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
Reference
Currency
1-4 currency codes used between the terminal
and the ICC when the Transaction Currency
Code is different from the Application
Currency Code; each code is 3 digits according
to ISO 4217
ICC n 3 '70' or '77' '9F3B' 2-8
Application
Reference
Currency
Exponent
Indicates the implied position of the decimal
point from the right of the amount, for each of
the 1-4 reference currencies represented
according to ISO 4217
ICC n 1 '70' or '77' '9F43' 1-4
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 135
Name Description Source Format Template Tag Length
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-5
ICC b '70' '61' var. up
to 252
Application
Transaction
Counter (ATC)
Counter maintained by the application in the
ICC (incrementing the ATC is managed by the
ICC)
ICC b '77' or '80' '9F36' 2
Application
Usage Control
Indicates issuer‘s specified restrictions on the
geographic usage and services allowed for the
application
ICC b '70' or '77' '9F07' 2
Application
Version Number
Version number assigned by the payment
system for the application
ICC b '70' or '77' '9F08' 2
Application
Version Number
Version number assigned by the payment
system for the application
Terminal b — '9F09' 2
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 136
Name Description Source Format Template Tag Length
Authorisation
Code
Value generated by the authorisation authority
for an approved transaction
Issuer As defined
by the
Payment
Systems
— '89' 6
Authorisation
Response Code
Code that defines the disposition of a message Issuer/
Terminal
an 2 — '8A' 2
Authorisation
Response
Cryptogram
(ARPC)
Cryptogram generated by the issuer and used
by the card to verify that the response came
from the issuer.
Issuer b — — 4 or 8
Bank Identifier
Code (BIC)
Uniquely identifies a bank as defined in ISO
9362.
ICC var. 'BF0C' or
'73'
'5F54' 8 or 11
Card Risk
Management
Data Object
List 1 (CDOL1)
List of data objects (tag and length) to be
passed to the ICC in the first GENERATE AC
command
ICC b '70' or '77' '8C' var. up
to 252
Card Risk
Management
Data Object
List 2 (CDOL2)
List of data objects (tag and length) to be
passed to the ICC in the second GENERATE
AC command
ICC b '70' or '77' '8D' var. up
to 252
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 137
Name Description Source Format Template Tag Length
Card Status
Update (CSU)
Contains data sent to the ICC to indicate
whether the issuer approves or declines the
transaction, and to initiate actions specified by
the issuer. Transmitted to the card in Issuer
Authentication Data.
Issuer b — — 4
Cardholder
Name
Indicates cardholder name according to
ISO 7813
ICC ans 2-26 '70' or '77' '5F20' 2-26
Cardholder
Name Extended
Indicates the whole cardholder name when
greater than 26 characters using the same
coding convention as in ISO 7813
ICC ans 27-45 '70' or '77' '9F0B' 27-45
Cardholder
Verification
Method (CVM)
List
Identifies a method of verification of the
cardholder supported by the application
ICC b '70' or '77' '8E' var. up
to 252
Cardholder
Verification
Method (CVM)
Results
Indicates the results of the last CVM
performed
Terminal b — '9F34' 3
Certification
Authority Public
Key Check Sum
A check value calculated on the concatenation
of all parts of the Certification Authority
Public Key (RID, Certification Authority Public
Key Index, Certification Authority Public Key
Modulus, Certification Authority Public Key
Exponent) using SHA-1
Terminal b — — 20
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 138
Name Description Source Format Template Tag Length
Certification
Authority Public
Key Exponent
Value of the exponent part of the Certification
Authority Public Key
Terminal b — — 1 or 3
Certification
Authority Public
Key Index
Identifies the certification authority‘s public
key in conjunction with the RID
ICC b '70' or '77' '8F' 1
Certification
Authority Public
Key Index
Identifies the certification authority‘s public
key in conjunction with the RID
Terminal b — '9F22' 1
Certification
Authority Public
Key Modulus
Value of the modulus part of the Certification
Authority Public Key
Terminal b — — NCA
(up to
248)
Command
Template
Identifies the data field of a command message Terminal b — '83' var.
Cryptogram
Information
Data
Indicates the type of cryptogram and the
actions to be performed by the terminal
ICC b '77' or '80' '9F27' 1
Data
Authentication
Code
An issuer assigned value that is retained by
the terminal during the verification process of
the Signed Static Application Data
ICC b — '9F45' 2
Dedicated File
(DF) Name
Identifies the name of the DF as described in
ISO/IEC 7816-4
ICC b '6F' '84' 5-16
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 139
Name Description Source Format Template Tag Length
Default Dynamic
Data
Authentication
Data Object List
(DDOL)
DDOL to be used for constructing the
INTERNAL AUTHENTICATE command if the
DDOL in the card is not present
Terminal b — — var.
Default
Transaction
Certificate Data
Object List
(TDOL)
TDOL to be used for generating the TC Hash
Value if the TDOL in the card is not present
Terminal b — — var.
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-5
ICC var. '61' '73' var. up
to 252
Dynamic Data
Authentication
Data Object List
(DDOL)
List of data objects (tag and length) to be
passed to the ICC in the INTERNAL
AUTHENTICATE command
ICC b '70' or '77' '9F49' up to
252
Enciphered
Personal
Identification
Number (PIN)
Data
Transaction PIN enciphered at the PIN pad for
online verification or for offline verification if
the PIN pad and IFD are not a single
integrated device
Terminal b — — 8
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 140
Name Description Source Format Template Tag Length
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
ICC Dynamic
Number
Time-variant number generated by the ICC, to
be captured by the terminal
ICC b — '9F4C' 2-8
Integrated
Circuit Card
(ICC) PIN
Encipherment
Public Key
Certificate
ICC PIN Encipherment Public Key certified by
the issuer
ICC b '70' or '77' '9F2D' NI
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 141
Name Description Source Format Template Tag Length
Integrated
Circuit Card
(ICC) PIN
Encipherment
Public Key
Exponent
ICC PIN Encipherment Public Key Exponent
used for PIN encipherment
ICC b '70' or '77' '9F2E' 1 or 3
Integrated
Circuit Card
(ICC) PIN
Encipherment
Public Key
Remainder
Remaining digits of the ICC PIN
Encipherment Public Key Modulus
ICC b '70' or '77' '9F2F' NPE ÷
NI + 42
Integrated
Circuit Card
(ICC) Public Key
Certificate
ICC Public Key certified by the issuer ICC b '70' or '77' '9F46' NI
Integrated
Circuit Card
(ICC) Public Key
Exponent
ICC Public Key Exponent used for the
verification of the Signed Dynamic Application
Data
ICC b '70' or '77' '9F47' 1 to 3
Integrated
Circuit Card
(ICC) Public Key
Remainder
Remaining digits of the ICC Public Key
Modulus
ICC b '70' or '77' '9F48' NIC ÷
NI + 42
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 142
Name Description Source Format Template Tag Length
Interface Device
(IFD) Serial
Number
Unique and permanent serial number assigned
to the IFD by the manufacturer
Terminal an 8 — '9F1E' 8
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 Action
Code - Default
Specifies the issuer‘s conditions that cause a
transaction to be rejected if it might have been
approved online, but the terminal is unable to
process the transaction online
ICC b '70' or '77' '9F0D' 5
Issuer Action
Code - Denial
Specifies the issuer‘s conditions that cause the
denial of a transaction without attempt to go
online
ICC b '70' or '77' '9F0E' 5
Issuer Action
Code - Online
Specifies the issuer‘s conditions that cause a
transaction to be transmitted online
ICC b '70' or '77' '9F0F' 5
Issuer
Application Data
Contains proprietary application data for
transmission to the issuer in an online
transaction.
Note: For CCD-compliant applications, Annex C,
section C7 defines the specific coding of the Issuer
Application Data (IAD). To avoid potential conflicts
with CCD-compliant applications, it is strongly
recommended that the IAD data element in an
application that is not CCD-compliant should not
use the coding for a CCD-compliant application
ICC b '77' or '80' '9F10' var. up
to 32
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 143
Name Description Source Format Template Tag Length
Issuer
Authentication
Data
Data sent to the ICC for online issuer
authentication
Issuer b — '91' 8-16
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
Indicates the country of the issuer according to
ISO 3166
ICC n 3 '70' or '77' '5F28' 2
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
Issuer
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 Public
Key Certificate
Issuer public key certified by a certification
authority
ICC b '70' or '77' '90' NCA
Issuer Public
Key Exponent
Issuer public key exponent used for the
verification of the Signed Static Application
Data and the ICC Public Key Certificate
ICC b '70' or '77' '9F32' 1 to 3
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 144
Name Description Source Format Template Tag Length
Issuer Public
Key Remainder
Remaining digits of the Issuer Public Key
Modulus
ICC b '70' or '77' '92' NI ÷
NCA +
36
Issuer Script
Command
Contains a command for transmission to the
ICC
Issuer b '71' or '72' '86' var. up
to 261
Issuer Script
Identifier
Identification of the Issuer Script Issuer b '71' or '72' '9F18' 4
Issuer Script
Results
Indicates the result of the terminal script
processing
Terminal b — — var.
Issuer Script
Template 1
Contains proprietary issuer data for
transmission to the ICC before the second
GENERATE AC command
Issuer b — '71' var.
Issuer Script
Template 2
Contains proprietary issuer data for
transmission to the ICC after the second
GENERATE AC command
Issuer b — '72' var.
Issuer URL The URL provides the location of the Issuer‘s
Library Server on the Internet.
ICC ans 'BF0C' or
'73'
'5F50' var.
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
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 145
Name Description Source Format Template Tag Length
Last Online
Application
Transaction
Counter (ATC)
Register
ATC value of the last transaction that went
online
ICC b — '9F13' 2
Log Entry Provides the SFI of the Transaction Log file
and its number of records
ICC b 'BF0C' or
'73'
'9F4D' 2
Log Format List (in tag and length format) of data objects
representing the logged data elements that are
passed to the terminal when a transaction log
record is read
ICC b — '9F4F' var.
Lower
Consecutive
Offline Limit
Issuer-specified preference for the maximum
number of consecutive offline transactions for
this ICC application allowed in a terminal with
online capability
ICC b '70' or '77' '9F14' 1
Maximum
Target
Percentage to be
used for Biased
Random
Selection
Value used in terminal risk management for
random transaction selection
Terminal — — — —
Merchant
Category Code
Classifies the type of business being done by
the merchant, represented according to
ISO 8583:1993 for Card Acceptor Business
Code
Terminal n 4 — '9F15' 2
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 146
Name Description Source Format Template Tag Length
Merchant
Identifier
When concatenated with the Acquirer
Identifier, uniquely identifies a given merchant
Terminal ans 15 — '9F16' 15
Merchant Name
and Location
Indicates the name and location of the
merchant
Terminal ans — '9F4E' var.
Message Type Indicates whether the batch data capture
record is a financial record or advice
Terminal n 2 — — 1
Personal
Identification
Number (PIN)
Pad Secret Key
Secret key of a symmetric algorithm used by
the PIN pad to encipher the PIN and by the
card reader to decipher the PIN if the PIN pad
and card reader are not integrated
Terminal — — — —
Personal
Identification
Number (PIN)
Try Counter
Number of PIN tries remaining ICC b — '9F17' 1
Point-of-Service
(POS) Entry
Mode
Indicates the method by which the PAN was
entered, according to the first two digits of the
ISO 8583:1987 POS Entry Mode
Terminal n 2 — '9F39' 1
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.
Proprietary
Authentication
Data
Contains issuer data for transmission to the
card in the Issuer Authentication Data of an
online transaction.
Issuer b — — var. up
to 8
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 147
Name Description Source Format Template Tag Length
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
Response
Message
Template
Format 1
Contains the data objects (without tags and
lengths) returned by the ICC in response to a
command
ICC var. — '80' var.
Response
Message
Template
Format 2
Contains the data objects (with tags and
lengths) returned by the ICC in response to a
command
ICC var. — '77' var.
Service Code Service code as defined in ISO/IEC 7813 for
track 1 and track 2
ICC n 3 '70' or '77' '5F30' 2
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 to 30
and with the three high order bits set to zero.
ICC b 'A5' '88' 1
Signed Dynamic
Application Data
Digital signature on critical application
parameters for DDA or CDA
ICC b — '9F4B' NIC
Signed Static
Application Data
Digital signature on critical application
parameters for SDA
ICC b '70' or '77' '93' NI
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 148
Name Description Source Format Template Tag Length
Static Data
Authentication
Tag List
List of tags of primitive data objects defined in
this specification whose value fields are to be
included in the Signed Static or Dynamic
Application Data
ICC — '70' or '77' '9F4A' var.
Target
Percentage to be
Used for Random
Selection
Value used in terminal risk management for
random transaction selection
Terminal — — — —
Terminal Action
Code - Default
Specifies the acquirer‘s conditions that cause a
transaction to be rejected if it might have been
approved online, but the terminal is unable to
process the transaction online
Terminal b — — 5
Terminal Action
Code - Denial
Specifies the acquirer‘s conditions that cause
the denial of a transaction without attempt to
go online
Terminal b — — 5
Terminal Action
Code - Online
Specifies the acquirer‘s conditions that cause a
transaction to be transmitted online
Terminal b — — 5
Terminal
Capabilities
Indicates the card data input, CVM, and
security capabilities of the terminal
Terminal b — '9F33' 3
Terminal
Country Code
Indicates the country of the terminal,
represented according to ISO 3166
Terminal n 3 — '9F1A' 2
Terminal Floor
Limit
Indicates the floor limit in the terminal in
conjunction with the AID
Terminal b — '9F1B' 4
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 149
Name Description Source Format Template Tag Length
Terminal
Identification
Designates the unique location of a terminal at
a merchant
Terminal an 8 — '9F1C' 8
Terminal Risk
Management
Data
Application-specific value used by the card for
risk management purposes
Terminal b — '9F1D' 1-8
Terminal Type Indicates the environment of the terminal, its
communications capability, and its operational
control
Terminal n 2 — '9F35' 1
Terminal
Verification
Results
Status of the different functions as seen from
the terminal
Terminal b — '95' 5
Threshold Value
for Biased
Random
Selection
Value used in terminal risk management for
random transaction selection
Terminal — — — —
Track 1
Discretionary
Data
Discretionary part of track 1 according to
ISO/IEC 7813
ICC ans '70' or '77' '9F1F' var.
Track 2
Discretionary
Data
Discretionary part of track 2 according to
ISO/IEC 7813
ICC cn '70' or '77' '9F20' var.
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 150
Name Description Source Format Template Tag Length
Track 2
Equivalent Data
Contains the data elements of track 2
according to ISO/IEC 7813, excluding start
sentinel, end sentinel, and Longitudinal
Redundancy Check (LRC), as follows:
ICC b '70' or '77' '57' var. up
to 19
Primary Account Number n, var. up
to 19

Field Separator (Hex 'D') b
Expiration Date (YYMM) n 4
Service Code n 3
Discretionary Data (defined by individual
payment systems)
n, var.
Pad with one Hex 'F' if needed to ensure
whole bytes
b
Transaction
Amount
Clearing amount of the transaction, including
tips and other adjustments
Terminal n 12 — — 6
Transaction
Certificate Data
Object List
(TDOL)
List of data objects (tag and length) to be used
by the terminal in generating the TC Hash
Value
ICC b '70' or '77' '97' var. up
to 252
Transaction
Certificate (TC)
Hash Value
Result of a hash function specified in Book 2,
Annex B3.1
Terminal b — '98' 20
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 151
Name Description Source Format Template Tag Length
Transaction
Currency Code
Indicates the currency code of the transaction
according to ISO 4217
Terminal n 3 — '5F2A' 2
Transaction
Currency
Exponent
Indicates the implied position of the decimal
point from the right of the transaction amount
represented according to ISO 4217
Terminal n 1 — '5F36' 1
Transaction Date Local date that the transaction was authorised Terminal n 6
YYMMDD
— '9A' 3
Transaction
Personal
Identification
Number (PIN)
Data
Data entered by the cardholder for the purpose
of the PIN verification
Terminal b — '99' var.
Transaction
Reference
Currency Code
Code defining the common currency used by
the terminal in case the Transaction Currency
Code is different from the Application
Currency Code
Terminal n 3 — '9F3C' 2
Transaction
Reference
Currency
Conversion
Factor used in the conversion from the
Transaction Currency Code to the Transaction
Reference Currency Code
Terminal n 8 — — 4
Transaction
Reference
Currency
Exponent
Indicates the implied position of the decimal
point from the right of the transaction amount,
with the Transaction Reference Currency Code
represented according to ISO 4217
Terminal n 1 — '9F3D' 1
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 152
Name Description Source Format Template Tag Length
Transaction
Sequence
Counter
Counter maintained by the terminal that is
incremented by one for each transaction
Terminal n 4-8 — '9F41' 2-4
Transaction
Status
Information
Indicates the functions performed in a
transaction
Terminal b — '9B' 2
Transaction
Time
Local time that the transaction was authorised Terminal n 6
HHMMSS
— '9F21' 3
Transaction
Type
Indicates the type of financial transaction,
represented by the first two digits of the
ISO 8583:1987 Processing Code. The actual
values to be used for the Transaction Type
data element are defined by the relevant
payment system
Terminal n 2 — '9C' 1
Unpredictable
Number
Value to provide variability and uniqueness to
the generation of a cryptogram
Terminal b — '9F37' 4
Upper
Consecutive
Offline Limit
Issuer-specified preference for the maximum
number of consecutive offline transactions for
this ICC application allowed in a terminal
without online capability
ICC b '70' or '77' '9F23' 1
Table 33: Data Elements Dictionary, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A1 Data Elements by Name

June 2008 Page 153
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 cn is left justified and padded with trailing hexadecimal 'F's.
- 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.
Note: Data that can occur in template '70' or '77' can never occur in both.
Annex A Data Elements Dictionary EMV 4.2 Book 3
A2 Data Elements by Tag Application Specification

Page 154 June 2008
A2 Data Elements by Tag
Name Template Tag
Issuer Identification Number (IIN) 'BF0C' or '73' '42'
Application Identifier (AID) - card '61' '4F'
Application Label '61' or 'A5' '50'
Track 2 Equivalent Data '70' or '77' '57'
Application Primary Account Number (PAN) '70' or '77' '5A'
Cardholder Name '70' or '77' '5F20'
Application Expiration Date '70' or '77' '5F24'
Application Effective Date '70' or '77' '5F25'
Issuer Country Code '70' or '77' '5F28'
Transaction Currency Code — '5F2A'
Language Preference 'A5' '5F2D'
Service Code '70' or '77' '5F30'
Application Primary Account Number (PAN)
Sequence Number
'70' or '77' '5F34'
Transaction Currency Exponent — '5F36'
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' or '77' '61'
File Control Information (FCI) Template — '6F'
Table 34: Data Elements Tags
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A2 Data Elements by Tag

June 2008 Page 155
Name Template Tag
READ RECORD Response Message Template — '70'
Issuer Script Template 1 — '71'
Issuer Script Template 2 — '72'
Directory Discretionary Template '61' '73'
Response Message Template Format 2 — '77'
Response Message Template Format 1 — '80'
Amount, Authorised (Binary) — '81'
Application Interchange Profile '77' or '80' '82'
Command Template — '83'
Dedicated File (DF) Name '6F' '84'
Issuer Script Command '71' or '72' '86'
Application Priority Indicator '61' or 'A5' '87'
Short File Identifier (SFI) 'A5' '88'
Authorisation Code — '89'
Authorisation Response Code — '8A'
Card Risk Management Data Object List 1 (CDOL1) '70' or '77' '8C'
Card Risk Management Data Object List 2 (CDOL2) '70' or '77' '8D'
Cardholder Verification Method (CVM) List '70' or '77' '8E'
Certification Authority Public Key Index '70' or '77' '8F'
Issuer Public Key Certificate '70' or '77' '90'
Issuer Authentication Data — '91'
Issuer Public Key Remainder '70' or '77' '92'
Signed Static Application Data '70' or '77' '93'
Application File Locator (AFL) '77' or '80' '94'
Terminal Verification Results — '95'
Transaction Certificate Data Object List (TDOL) '70' or '77' '97'
Transaction Certificate (TC) Hash Value — '98'
Transaction Personal Identification Number (PIN)
Data
— '99'
Table 34: Data Elements Tags, continued
Annex A Data Elements Dictionary EMV 4.2 Book 3
A2 Data Elements by Tag Application Specification

Page 156 June 2008
Name Template Tag
Transaction Date — '9A'
Transaction Status Information — '9B'
Transaction Type — '9C'
Directory Definition File (DDF) Name '61' '9D'
Acquirer Identifier — '9F01'
Amount, Authorised (Numeric) — '9F02'
Amount, Other (Numeric) — '9F03'
Amount, Other (Binary) — '9F04'
Application Discretionary Data '70' or '77' '9F05'
Application Identifier (AID) - terminal — '9F06'
Application Usage Control '70' or '77' '9F07'
Application Version Number '70' or '77' '9F08'
Application Version Number — '9F09'
Cardholder Name Extended '70' or '77' '9F0B'
Issuer Action Code - Default '70' or '77' '9F0D'
Issuer Action Code - Denial '70' or '77' '9F0E'
Issuer Action Code - Online '70' or '77' '9F0F'
Issuer Application Data '77' or '80' '9F10'
Issuer Code Table Index 'A5' '9F11'
Application Preferred Name '61' or 'A5' '9F12'
Last Online Application Transaction Counter (ATC)
Register
— '9F13'
Lower Consecutive Offline Limit '70' or '77' '9F14'
Merchant Category Code — '9F15'
Merchant Identifier — '9F16'
Personal Identification Number (PIN) Try Counter — '9F17'
Issuer Script Identifier '71' or '72' '9F18'
Table 34: Data Elements Tags, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A2 Data Elements by Tag

June 2008 Page 157
Name Template Tag
Terminal Country Code — '9F1A'
Terminal Floor Limit — '9F1B'
Terminal Identification — '9F1C'
Terminal Risk Management Data — '9F1D'
Interface Device (IFD) Serial Number — '9F1E'
Track 1 Discretionary Data '70' or '77' '9F1F'
Track 2 Discretionary Data '70' or '77' '9F20'
Transaction Time — '9F21'
Certification Authority Public Key Index — '9F22'
Upper Consecutive Offline Limit '70' or '77' '9F23'
Application Cryptogram '77' or '80' '9F26'
Cryptogram Information Data '77' or '80' '9F27'
ICC PIN Encipherment Public Key Certificate '70' or '77' '9F2D'
ICC PIN Encipherment Public Key Exponent '70' or '77' '9F2E'
ICC PIN Encipherment Public Key Remainder '70' or '77' '9F2F'
Issuer Public Key Exponent '70' or '77' '9F32'
Terminal Capabilities — '9F33'
Cardholder Verification Method (CVM) Results — '9F34'
Terminal Type — '9F35'
Application Transaction Counter (ATC) '77' or '80' '9F36'
Unpredictable Number — '9F37'
Processing Options Data Object List (PDOL) 'A5' '9F38'
Point-of-Service (POS) Entry Mode — '9F39'
Amount, Reference Currency — '9F3A'
Application Reference Currency '70' or '77' '9F3B'
Transaction Reference Currency Code — '9F3C'
Transaction Reference Currency Exponent — '9F3D'
Additional Terminal Capabilities — '9F40'
Transaction Sequence Counter — '9F41'
Table 34: Data Elements Tags, continued
Annex A Data Elements Dictionary EMV 4.2 Book 3
A2 Data Elements by Tag Application Specification

Page 158 June 2008
Name Template Tag
Application Currency Code '70' or '77' '9F42'
Application Reference Currency Exponent '70' or '77' '9F43'
Application Currency Exponent '70' or '77' '9F44'
Data Authentication Code — '9F45'
ICC Public Key Certificate '70' or '77' '9F46'
ICC Public Key Exponent '70' or '77' '9F47'
ICC Public Key Remainder '70' or '77' '9F48'
Dynamic Data Authentication Data Object List
(DDOL)
'70' or '77' '9F49'
Static Data Authentication Tag List '70' or '77' '9F4A'
Signed Dynamic Application Data — '9F4B'
ICC Dynamic Number — '9F4C'
Log Entry 'BF0C' or '73' '9F4D'
Merchant Name and Location — '9F4E'
Log Format — '9F4F'
File Control Information (FCI) Proprietary Template '6F' 'A5'
File Control Information (FCI) Issuer Discretionary
Data
'A5' 'BF0C'
Table 34: Data Elements Tags, continued
EMV 4.2 Book 3 Annex A Data Elements Dictionary
Application Specification A2 Data Elements by Tag

June 2008 Page 159

EMV 4.2 Book 3
Application Specification

June 2008 Page 161
Annex B Rules for BER-TLV Data Objects
As defined in ISO/IEC 8825, a BER-TLV data object consists of 2-3 consecutive
fields:
- The tag field (T) consists of one or more consecutive bytes. It indicates a class,
a type, and a number (see Table 35). The tag field of the data objects
described in this specification is coded on one or two bytes.
- The length field (L) consists of one or more consecutive bytes. It indicates the
length of the following field. The length field of the data objects described in
this specification which are transmitted over the card-terminal interface is
coded on one or two bytes.
Note: Three length bytes may be used if needed for templates '71' and '72' and tag
'86' (to express length greater than 255 bytes), as they are not transmitted over the
card-terminal interface.
- The value field (V) indicates the value of the data object. If L = '00', the value
field is not present.
A BER-TLV data object belongs to one of the following two categories:
- A primitive data object where the value field contains a data element for
financial transaction interchange.
- A constructed data object where the value field contains one or more primitive
or constructed data objects. The value field of a constructed data object is
called a template.
The coding of BER-TLV data objects is defined as follows.
Annex B Rules for BER-TLV Data Objects EMV 4.2 Book 3
B1 Coding of the Tag Field of BER-TLV Data Objects Application Specification

Page 162 June 2008
B1 Coding of the Tag Field of BER-TLV Data
Objects
Table 35 describes the first byte of the tag field of a BER-TLV data object:

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 0 Universal class
0 1 Application class
1 0 Context-specific class
1 1 Private class
0 Primitive data object
1 Constructed data object
1 1 1 1 1 See subsequent bytes
Any other value <31 Tag number
Table 35: Tag Field Structure (First Byte) BER-TLV
According to ISO/IEC 8825, Table 36 defines the coding rules of the subsequent
bytes of a BER-TLV tag when tag numbers > 31 are used (that is, bits b5 - b1 of
the first byte equal '11111').

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Another byte follows
0 Last tag byte
Any value > 0 (Part of) tag number
Table 36: Tag Field Structure (Subsequent Bytes) BER-TLV
Before, between, or after TLV-coded data objects, '00' or 'FF' bytes without any
meaning may occur (for example, due to erased or modified TLV-coded data
objects).
EMV 4.2 Book 3 Annex B Rules for BER-TLV Data Objects
Application Specification B2 Coding of the Length Field of BER-TLV Data Objects

June 2008 Page 163
The tag field of a BER-TLV data object is coded according to the following rules:
- The following application class templates defined in ISO/IEC 7816 apply:
'61' and '6F'.
- The following range of application class templates is defined in Part II: '70' to
'7F'. The meaning is then specific to the context of an application according to
this specification. Tags '78', '79', '7D', and '7E' are defined in ISO/IEC 7816-6
and are not used in this specification.
- The application class data objects defined in ISO/IEC 7816 and described in
Part II are used according to the ISO/IEC 7816 definition.
- Context-specific class data objects are defined in the context of this
specification or in the context of the template in which they appear.
- The coding of primitive context-specific class data objects in the ranges '80' to
'9E' and '9F00' to '9F4F' is reserved for this specification.
- The coding of primitive context-specific class data objects in the range '9F50'
to '9F7F' is reserved for the payment systems.
- The coding of primitive and constructed private class data objects is left to the
discretion of the issuer.
B2 Coding of the Length Field of BER-TLV Data
Objects
When bit b8 of the most significant byte of the length field is set to 0, the length
field consists of only one byte. Bits b7 to b1 code the number of bytes of the value
field. The length field is within the range 1 to 127.
When bit b8 of the most significant byte of the length field is set to 1, the
subsequent bits b7 to b1 of the most significant byte code the number of
subsequent bytes in the length field. The subsequent bytes code an integer
representing the number of bytes in the value field. Two bytes are necessary to
express up to 255 bytes in the value field.
Annex B Rules for BER-TLV Data Objects EMV 4.2 Book 3
B3 Coding of the Value Field of Data Objects Application Specification

Page 164 June 2008
B3 Coding of the Value Field of Data Objects
A data element is the value field (V) of a primitive BER-TLV data object. A data
element is the smallest data field that receives an identifier (a tag).
A primitive data object is structured as illustrated in Figure 16:

Tag (T) Length (L) Value (V)
Figure 16: Primitive BER-TLV Data Object (Data Element)
A constructed BER-TLV data object consists of a tag, a length, and a value field
composed of one or more BER-TLV data objects. A record in an AEF governed by
this specification is a constructed BER-TLV data object. A constructed data object
is structured as illustrated in Figure 17:

Tag
(T)
Length
(L)
Primitive or constructed
BER-TLV data object
number 1
... Primitive or constructed
BER-TLV data object
number n
Figure 17: Constructed BER-TLV Data Object
EMV 4.2 Book 3
Application Specification

June 2008 Page 165
Annex C Coding of Data Elements Used in
Transaction Processing
This annex provides the coding for dynamic card data elements and specific data
elements used to control the transaction flow in the terminal or to record the
status of processing for the transaction. In the tables:
- A ‗1‘ means that if that bit has the value 1, the corresponding ‗Meaning‘
applies.
- An ‗x‘ means that the bit does not apply.
Data (bytes or bits) indicated as RFU shall be set to 0.
Annex C Coding Data Elements Used in Trans Processing EMV 4.2 Book 3
C1 Application Interchange Profile Application Specification

Page 166 June 2008
C1 Application Interchange Profile
AIP Byte 1 (Leftmost)
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 x x x x x x x RFU
x 1 x x x x x x SDA supported
x x 1 x x x x x DDA supported
x x x 1 x x x x Cardholder verification is
supported
x x x x 1 x x x Terminal risk management is to
be performed
x x x x x 1 x x Issuer authentication is
supported
20

x x x x x x 0 x RFU
x x x x x x x 1 CDA supported

AIP Byte 2 (Rightmost)
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 x x x x x x x RFU
x 0 x x x x x x RFU
x x 0 x x x x x RFU
x x x 0 x x x x RFU
x x x x 0 x x x RFU
x x x x x 0 x x RFU
x x x x x x 0 x RFU
x x x x x x x 0 RFU
Table 37: Application Interchange Profile

20
When this bit is set to 1, Issuer Authentication using the EXTERNAL
AUTHENTICATE command is supported
EMV 4.2 Book 3 Annex C Coding Data Elements Used in Trans Processing
Application Specification C2 Application Usage Control

June 2008 Page 167
C2 Application Usage Control
Application Usage Control Byte 1 (Leftmost)
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x x x Valid for domestic cash
transactions
x 1 x x x x x x Valid for international cash
transactions
x x 1 x x x x x Valid for domestic goods
x x x 1 x x x x Valid for international goods
x x x x 1 x x x Valid for domestic services
x x x x x 1 x x Valid for international services
x x x x x x 1 x Valid at ATMs
x x x x x x x 1 Valid at terminals other than
ATMs

Application Usage Control Byte 2 (Rightmost)
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x x x Domestic cashback allowed
x 1 x x x x x x International cashback allowed
x x 0 x x x x x RFU
x x x 0 x x x x RFU
x x x x 0 x x x RFU
x x x x x 0 x x RFU
x x x x x x 0 x RFU
x x x x x x x 0 RFU
Table 38: Application Usage Control
Annex C Coding Data Elements Used in Trans Processing EMV 4.2 Book 3
C3 Cardholder Verification Rule Format Application Specification

Page 168 June 2008
C3 Cardholder Verification Rule Format
CV Rule Byte 1 (Leftmost): Cardholder Verification Method (CVM) Codes
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 RFU
0 Fail cardholder verification if this
CVM is unsuccessful
1 Apply succeeding CV Rule if this
CVM is unsuccessful
0 0 0 0 0 0 Fail CVM processing
0 0 0 0 0 1 Plaintext PIN verification
performed by ICC
0 0 0 0 1 0 Enciphered PIN verified online
0 0 0 0 1 1 Plaintext PIN verification
performed by ICC and signature
(paper)
0 0 0 1 0 0 Enciphered PIN verification
performed by ICC
0 0 0 1 0 1 Enciphered PIN verification
performed by ICC and signature
(paper)
0 x x x x x Values in the range 000110-011101
reserved for future use by this
specification
0 1 1 1 1 0 Signature (paper)
0 1 1 1 1 1 No CVM required
1 0 x x x x Values in the range 100000-101111
reserved for use by the individual
payment systems
1 1 x x x x Values in the range 110000-111110
reserved for use by the issuer
1 1 1 1 1 1 This value is not available for use
Table 39: CVM Codes
EMV 4.2 Book 3 Annex C Coding Data Elements Used in Trans Processing
Application Specification C3 Cardholder Verification Rule Format

June 2008 Page 169
CV Rule Byte 2 (Rightmost): Cardholder Verification Method (CVM) Condition
Codes
Value Meaning
'00' Always
'01' If unattended cash
'02' If not unattended cash and not manual cash and not purchase
with cashback
'03' If terminal supports the CVM
21

'04' If manual cash
'05' If purchase with cashback
'06' If transaction is in the application currency
22
and is under X
value (see section 10.5 for a discussion of ―X‖)
'07' If transaction is in the application currency and is over X value
'08' If transaction is in the application currency and is under Y value
(see section 10.5 for a discussion of ―Y‖)
'09' If transaction is in the application currency and is over Y value
'0A' - '7F' RFU
'80' - 'FF' Reserved for use by individual payment systems
Table 40: CVM Condition Codes
Note: For Condition Codes '01', '04', and '05', please refer to EMVCo General Bulletin
No. 14 - Migration Schedule for New CVM Condition Codes.

21
Support for a CVM is described in EMV Book 4, Section 6.3.4 first paragraph..
22
That is, Transaction Currency Code = Application Currency Code.
Annex C Coding Data Elements Used in Trans Processing EMV 4.2 Book 3
C4 Issuer Code Table Index Application Specification

Page 170 June 2008
C4 Issuer Code Table Index

Value Refers to
'01' Part 1 of ISO/IEC 8859
'02' Part 2 of ISO/IEC 8859
'03' Part 3 of ISO/IEC 8859
'04' Part 4 of ISO/IEC 8859
'05' Part 5 of ISO/IEC 8859
'06' Part 6 of ISO/IEC 8859
'07' Part 7 of ISO/IEC 8859
'08' Part 8 of ISO/IEC 8859
'09' Part 9 of ISO/IEC 8859
'10' Part 10 of ISO/IEC 8859
Table 41: Issuer Code Table Index
EMV 4.2 Book 3 Annex C Coding Data Elements Used in Trans Processing
Application Specification C5 Terminal Verification Results

June 2008 Page 171
C5 Terminal Verification Results
TVR Byte 1: (Leftmost)
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x x x Offline data authentication was not
performed
x 1 x x x x x x SDA failed
x x 1 x x x x x ICC data missing
x x x 1 x x x x Card appears on terminal exception
file
23

x x x x 1 x x x DDA failed
x x x x x 1 x x CDA failed
x x x x x x 0 x RFU
x x x x x x x 0 RFU

TVR Byte 2:
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x x x ICC and terminal have different
application versions
x 1 x x x x x x Expired application
x x 1 x x x x x Application not yet effective
x x x 1 x x x x Requested service not allowed for
card product
x x x x 1 x x x New card
x x x x x 0 x x RFU
x x x x x x 0 x RFU
x x x x x x x 0 RFU
Table 42: Terminal Verification Results

23
There is no requirement in this specification for an exception file, but it is recognised
that some terminals may have this capability.
Annex C Coding Data Elements Used in Trans Processing EMV 4.2 Book 3
C5 Terminal Verification Results Application Specification

Page 172 June 2008
TVR Byte 3:
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x x x Cardholder verification was not
successful
x 1 x x x x x x Unrecognised CVM
x x 1 x x x x x PIN Try Limit exceeded
x x x 1 x x x x PIN entry required and PIN pad
not present or not working
x x x x 1 x x x PIN entry required, PIN pad
present, but PIN was not entered
x x x x x 1 x x Online PIN entered
x x x x x x 0 x RFU
x x x x x x x 0 RFU

TVR Byte 4:
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x x x Transaction exceeds floor limit
x 1 x x x x x x Lower consecutive offline limit
exceeded
x x 1 x x x x x Upper consecutive offline limit
exceeded
x x x 1 x x x x Transaction selected randomly for
online processing
x x x x 1 x x x Merchant forced transaction online
x x x x x 0 x x RFU
x x x x x x 0 x RFU
x x x x x x x 0 RFU
Table 42: Terminal Verification Results, continued
EMV 4.2 Book 3 Annex C Coding Data Elements Used in Trans Processing
Application Specification C5 Terminal Verification Results

June 2008 Page 173
TVR Byte 5 (Rightmost):
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x x x Default TDOL used
x 1 x x x x x x Issuer authentication failed
x x 1 x x x x x Script processing failed before final
GENERATE AC
x x x 1 x x x x Script processing failed after final
GENERATE AC
x x x x 0 x x x RFU
x x x x x 0 x x RFU
x x x x x x 0 x RFU
x x x x x x x 0 RFU
Table 42: Terminal Verification Results, continued
Annex C Coding Data Elements Used in Trans Processing EMV 4.2 Book 3
C6 Transaction Status Information Application Specification

Page 174 June 2008
C6 Transaction Status Information
TSI Byte 1 (Leftmost):
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x x x Offline data authentication was
performed
x 1 x x x x x x Cardholder verification was
performed
x x 1 x x x x x Card risk management was
performed
x x x 1 x x x x Issuer authentication was
performed
x x x x 1 x x x Terminal risk management was
performed
x x x x x 1 x x Script processing was performed
x x x x x x 0 x RFU
x x x x x x x 0 RFU

TSI Byte 2 (Rightmost):
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 x x x x x x x RFU
x 0 x x x x x x RFU
x x 0 x x x x x RFU
x x x 0 x x x x RFU
x x x x 0 x x x RFU
x x x x x 0 x x RFU
x x x x x x 0 x RFU
x x x x x x x 0 RFU
Table 43: Transaction Status Information
EMV 4.2 Book 3
Application Specification

June 2008 Page 175
Annex D Transaction Log Information
D1 Purpose
Provide support for accessing a transaction log file by special devices.
D2 Conditions of Execution
This optional function is intended to be executed by special devices.
D3 Sequence of Execution
This function may be executed after Application Selection.
Annex D Transaction Log Information EMV 4.2 Book 3
D4 Description Application Specification

Page 176 June 2008
D4 Description
To get the Transaction Log information, the two following data elements are
used: Log Entry and Log Format.
Table 44 describes the format of the Log Entry data element (tag '9F4D'):

Byte Format Length Value
1 b 1 SFI containing the cyclic transaction log file
2 b 1 Maximum number of records in the transaction log
file
Table 44: Log Entry
Devices that read the transaction log use the Log Entry data element to
determine the location (SFI) and the maximum number of transaction log
records.
The SFI shall be in the range 11 to 30.
The Transaction Log records shall be accessible using the READ RECORD
command as specified in section 6.5.11. The file is a cyclic file as defined in
ISO/IEC 7816-4. Record #1 is the most recent transaction. Record #2 is the next
prior transaction, etc.
The Transaction Log records shall not be designated in the Application File
Locator. Each record is a concatenation of the values identified in the Log Format
data element. The records in the file shall not contain the Application
Elementary File (AEF) Data Template (tag '70').
The Log Format and the Transaction Log records shall remain accessible when
the application is blocked.
To read the transaction log information, the special device uses the following
steps:
- Perform Application Selection and retrieve the Log Entry data element
located in the FCI Issuer Discretionary Data. If the Log Entry data element is
not present, the application does not support the Transaction Log function.
- Issue a GET DATA command to retrieve the Log Format data element.
- Issue READ RECORD commands to read the Transaction Log records.
EMV 4.2 Book 3 Annex D Transaction Log Information
Application Specification D5 Example

June 2008 Page 177
D5 Example
Note that the following data elements are shown for example purposes only.
A Log Entry data element equal to '0F14' indicates that the transaction log file is
located in SFI 15 ('0F') and contains a maximum of 20 records ('14').
A Log Format data element equal to '9A039F21035F2A029F02069F4E149F3602'
indicates that the transaction log records have the following content:

Data Content Tag Length
Transaction Date '9A' 3
Transaction Time '9F21' 3
Transaction Currency Code '5F2A' 2
Amount, Authorised '9F02' 6
Merchant Name and Location '9F4E' 20
Application Transaction Counter '9F36' 2
Table 45: Example of Log Format
In Table 45, lengths and tags are shown for clarity. They do not appear in the log
record which is the concatenation of values (no TLV coding).
Data elements listed in the Log Format may come from the terminal and the
card. Terminal data elements such as Merchant Name and Location might have
been passed to the card in the PDOL or CDOL data.
Annex D Transaction Log Information EMV 4.2 Book 3
D5 Example Application Specification

Page 178 June 2008
EMV 4.2 Book 3
Application Specification

June 2008 Page 179
Annex E TVR and TSI Bit Settings Following
Script Processing
Four possible scenarios can occur when processing a script. These scenarios are
described below, together with the expected results in terms of the setting of the
appropriate TVR bits, the TSI bit, and the Issuer Script Results.
In the following descriptions:
- ―TVR bits‖ refers to TVR byte 5 bit 6 and bit 5 (depending on whether it is a
tag '71' and/or tag '72' script) as defined in Table 42.
- ―TSI bit‖ refers to TSI byte 1 bit 3 as defined in Table 43.
The Issuer Script Results are defined in Book 4, Annex A5.
E1 Scenarios
Scenario 1
A script is received, it parses correctly, the commands are sent to the card, and
the card returns '9000', '62xx', or '63xx' to all commands received.
In this scenario the terminal:
- shall set the TSI bit
- shall not set the TVR bits
- shall set the first byte of the Issuer Script Results to '2x', ‗Script processing
successful‘.
Annex E TVR and TSI Bit Settings Following Script Processing EMV 4.2 Book 3
E1 Scenarios Application Specification

Page 180 June 2008
Scenario 2
A script is received, it parses correctly, the commands are sent to the card, but
the card does not return '9000', '62xx', or '63xx' to one of the commands received.
In this scenario the terminal:
- shall set the TSI bit
- shall set the appropriate TVR bit(s)
- shall set the first byte of the Issuer Script Results to '1x', ‗Script processing
failed‘
- shall send no further commands from that script to the card, even if they
exist.
Scenario 3
A script is received, it does not parse correctly, and so no commands are sent to
the card.
In this scenario the terminal:
- shall set the TSI bit
- shall set the appropriate TVR bit(s)
- shall set the first byte of the Issuer Script Results to '00', ‗Script not
performed‘.
Scenario 4
No script is received. In this scenario the terminal shall set neither the TSI bit
nor the TVR bit(s).
In this event there will be no Issuer Script Results.
EMV 4.2 Book 3 Annex E TVR and TSI Bit Settings Following Script Processing
Application Specification E2 Additional Information

June 2008 Page 181
E2 Additional Information
It is possible, but not recommended, that commands may be sent to the card ‗on
the fly‘ as a script is parsed. In this event:
- If a parsing error occurs before any commands are sent to the card, the
terminal shall set the first byte of the Issuer Script Results to '00' and shall
set the appropriate TVR bits and the TSI bit.
- If a parsing error occurs after any command has been sent to the card, the
terminal shall set the first byte of the Issuer Script Results to '1x', and shall
set the appropriate TVR bits and the TSI bit.
If more than one script is received, the terminal:
- shall set the TSI bit
- shall set the TVR bit(s) (as described in Scenarios 2 and 3) if any error occurs
- shall set the Issuer Script Results as described in Scenarios 1 through 3 for
each script on a script-by-script basis
- shall process all Issuer scripts
Annex E TVR and TSI Bit Settings Following Script Processing EMV 4.2 Book 3
E2 Additional Information Application Specification

Page 182 June 2008

EMV 4.2 Book 3
Application Specification

June 2008 Page 183
Annex F Status Words Returned in
EXTERNAL AUTHENTICATE
The terminal shall issue an EXTERNAL AUTHENTICATE command to the card
only if the card indicates in byte 1 bit 3 of the AIP that it supports issuer
authentication using the EXTERNAL AUTHENTICATE command.
The terminal shall issue only one EXTERNAL AUTHENTICATE command to
the card during a transaction. As stated in section 10.9, there is a complementary
card requirement to this which states that the card shall return status '6985',
‗Command Not Supported‘, to the second and any subsequent EXTERNAL
AUTHENTICATE commands received during the transaction.
Table 46 explains various status values the terminal may receive in response to
the (first) EXTERNAL AUTHENTICATE command issued to the card, and the
action the terminal shall take as a result.
Status Explanation Terminal Action
'9000' Issuer authentication
was successful.
The terminal shall continue with
the transaction.
'6300' or any
other status
except '6985'
and '9000'
Issuer authentication
failed.
The terminal shall set the ‗Issuer
authentication failed‘ bit in the
TVR to 1, and continue with the
transaction.
'6985' Issuer authentication
failed and the card is in
an error state (it has
indicated in the AIP that
it supports EXTERNAL
AUTHENTICATE, but in
the status returned that
it does not).
This condition should never occur;
in the event that it does, the
behaviour of the terminal is
indeterminate and it shall either
terminate the transaction OR set
the ‗Issuer authentication failed‘
bit in the TVR to 1, and continue
with the transaction.
Table 46: Terminal Action after (First) EXTERNAL AUTHENTICATE Response
Annex F Status Words Returned in EXTERNAL AUTHENTICATE EMV 4.2 Book 3
Application Specification

Page 184 June 2008
EMV 4.2 Book 3
Application Specification

June 2008 Page 185
Annex G Account Type

Value Account Type
00 Default - unspecified
10 Savings
20 Cheque/debit
30 Credit
All other
values RFU

Table 47: Account Type
Annex G Account Type EMV 4.2 Book 3
Application Specification

Page 186 June 2008

EMV 4.2 Book 3
Application Specification

June 2008 Page 187
Part V

Common Core
Definitions
EMV 4.2 Book 3
Application Specification

Page 188 June 2008
EMV 4.2 Book 3
Application Specification

June 2008 Page 189
Introduction
This Part describes an optional extension to this Book, to be used when
implementing the Common Core Definitions (CCD).
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 Parts
of all affected Books.
Changed and Added Sections
Each section heading below refers to the section in this Book to which the
additional requirements apply, or introduces new sections where required. 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 3
Application Specification

Page 190 June 2008
Part II - Data Elements and Commands
6 Commands for Financial Transaction
6.2 Response APDU Format
For the following commands used during transaction processing, the body of the
response APDU is a constructed data object with tag equal to '77' of which the
value field may contain one or more BER-TLV coded data objects.
- GENERATE AC
- GET PROCESSING OPTIONS
- INTERNAL AUTHENTICATE

Tag Value
'77' Response Message Template Format 2
Table CCD 1: Body of Response APDU Structure
6.5 Commands
6.5.4 EXTERNAL AUTHENTICATE Command-Response APDUs
6.5.4.1 Definition and Scope
The CCD-compliant application shall support issuer authentication using the
second GENERATE AC command. The CCD-compliant application shall indicate
that the EXTERNAL AUTHENTICATE command is not supported in EMV
applications by setting bit 3 in byte 1 of the AIP to 0.
6.5.5 GENERATE APPLICATION CRYPTOGRAM Command-Response
APDUs
6.5.5.1 Definition and Scope
The CCD-compliant application shall support issuer authentication using the
second GENERATE AC command.
EMV 4.2 Book 3 Common Core Definitions
Application Specification

June 2008 Page 191
6.5.5.3 Data Field Sent in the Command Message
CDOL2 shall include tag '8A' (Authorisation Response Code) and tag '91' (Issuer
Authentication Data).
6.5.5.4 Data Field Returned in the Response Message
The response message shall be a BER-TLV coded constructed data object
introduced by tag '77' and contains only the data shown in Table CCD 2.

Tag Value
'9F27' Cryptogram Information Data
'9F36' Application Transaction Counter
'9F26' Application Cryptogram
'9F10' Issuer Application Data
Table CCD 2: Format 2 GENERATE AC Response Message Data Field
The required data elements for the response returned in an envelope as specified
for the CDA feature (described in section 6.6 of Book 2) are shown in Book 2
Table CCD 1 and Table CCD 2.
The Cryptogram Information Data returned in the GENERATE AC response
message is coded according to Table CCD 3:

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 0 AAC
0 1 TC
1 0 ARQC
1 1 RFU
0 0 Payment System-specific cryptogram
0 No advice required
0 0 0 No information given
Table CCD 3: Coding of Cryptogram Information Data
6.5.8 GET PROCESSING OPTIONS Command-Response APDUs
6.5.8.2 Command Message
The CCD-compliant application shall not preclude support for PDOL.
Common Core Definitions EMV 4.2 Book 3
Application Specification

Page 192 June 2008
6.5.8.4 Data Field Returned in the Response Message
The response message shall be a BER-TLV coded constructed data object
introduced by tag '77' and contains only the data shown in Table CCD 4.

Tag Value
'82' Application Interchange Profile
'94' Application File Locator
Table CCD 4: Format 2 GET PROCESSING OPTIONS Response Message Data
Field
6.5.9 INTERNAL AUTHENTICATE Command-Response APDUs
6.5.9.4 Data Field Returned in the Response Message
The response message shall be a BER-TLV coded constructed data object
introduced by tag '77' and contains only the data shown in Table CCD 5.

Tag Value
'9F4B' Signed Dynamic Application Data
Table CCD 5: Format 2 Internal Authenticate Response Message Data Field
6.5.12.2 Command Message
To allow an issuer to use offline plaintext PIN verification as a possible CVM, a
CCD-compliant card shall support the VERIFY command with parameter
P2 = ‗80‘ as defined in Book 3, Table 23.
EMV 4.2 Book 3 Common Core Definitions
Application Specification

June 2008 Page 193
Part III - Debit and Credit Application
Specification
7 Files for Financial Transaction Interchange
7.3 Data Retrievable by GET DATA Command
The ICC shall support the GET DATA command for retrieval of the primitive
data object with tag '9F17' (PIN Try Counter).
Common Core Definitions EMV 4.2 Book 3
Application Specification

Page 194 June 2008
9 GENERATE AC Command Coding
9.2 Command Data
9.2.2 Transaction Certificate Data
The CCD-compliant application shall not contain a TDOL. The CCD-compliant
application shall not request the terminal to generate a TC Hash Value (that is,
tag '98' shall not be included in CDOL1 or CDOL2).
The following Section 9.2.3 applies to a CCD-compliant application.
9.2.3 Common Core Definitions Card Verification Results
In response to the GENERATE AC command and as part of the Issuer
Application Data, the CCD-compliant application shall return the Card
Verification Results (CVR). The CVR includes information for the issuer
regarding the results of Card Risk Management processing and application
processing. The format of the CVR for a CCD-compliant application is specified in
CCD Annex C7.3.
9.2.3.1 Options Related to Setting/Resetting of Counters and Indicators
The issuer shall have the option of specifying whether a new card is required to
set the ‗Go Online on Next Transaction Was Set‘ bit.
The issuer shall have the option of specifying whether the CCD-compliant
application requires issuer authentication to be performed for the application to
approve (TC) an online transaction.
The issuer shall have the option of specifying whether the CCD-compliant
application requires issuer authentication to pass when performed for the
application to approve (TC) an online transaction.
If the CCD-compliant application does not require issuer authentication to be
performed for the application to approve (TC) an online transaction, the issuer
shall have the option of specifying whether the CCD-compliant application
requires issuer authentication to pass for resetting all the following
non-velocity-checking indicators:
- Issuer Authentication Failed
- Last Online Transaction Not Completed
- Issuer Script Processing Failed
- Go Online on Next Transaction Was Set
EMV 4.2 Book 3 Common Core Definitions
Application Specification

June 2008 Page 195
If the CCD-compliant application does not require issuer authentication to pass
when performed for the application to approve (TC) an online transaction, the
issuer shall have the option of specifying whether the CCD-compliant application
requires issuer authentication to pass for resetting all the following non-velocity
checking indicators:
- Last Online Transaction Not Completed
- Issuer Script Processing Failed
- Go Online on Next Transaction Was Set
If the CCD-compliant application does not require issuer authentication to be
performed or does not require issuer authentication to pass when performed for
the application to approve (TC) an online transaction, the issuer shall have the
option of specifying whether the CCD-compliant application requires issuer
authentication to pass for resetting the velocity-checking offline transaction
count(s) and cumulative amount(s).
The issuer shall have the option of indicating whether the application shall use
the ‗Update Counters‘ bits in the CSU to update the velocity-checking count(s)
and cumulative amount(s) associated with the offline transaction limits referred
to in bits b8 - b5 of byte 3 of the CVR, if the ‗CSU Created by Proxy for the Issuer‘
bit in the CSU is set to 1.
If the ‗CSU Created by Proxy for the Issuer‘ bit is set to 1 in the CSU, and if the
issuer specifies that ‗Update Counters‘ shall not be used, then the issuer shall
have the option of indicating whether the application:
- shall not update the offline counters
- shall set the offline counters to zero
- shall set the offline counters to the upper offline limits
- shall add the transaction to the offline counter(s)
9.2.3.2 Setting and Resetting of Bits in the CVR
The following describes the conditions under which each bit in the CVR of a
Common Core Definitions card is set or reset.
Application Cryptogram Type Returned in Second GENERATE AC
In the first GENERATE AC response, these bits shall be set to Second
GENERATE AC Not Requested.
In the second GENERATE AC response, these bits shall be set to the value of bits
b8 – b7 of the Cryptogram Information Data returned in the response to the
second GENERATE AC command of the current transaction (AAC or TC).
Common Core Definitions EMV 4.2 Book 3
Application Specification

Page 196 June 2008
Application Cryptogram Type Returned in First GENERATE AC
In both the first and second GENERATE AC response, these bits shall be set to
the value of bits b8 – b7 of the Cryptogram Information Data returned in the
response to the first GENERATE AC command of the current transaction (AAC,
TC, or ARQC).
CDA Performed
In the first GENERATE AC response, this bit shall be set if and only if Signed
Dynamic Data is returned in the response to the first GENERATE AC command
of the current transaction.
In the second GENERATE AC response, this bit shall be set if and only if Signed
Dynamic Data is returned in the response to the first or second GENERATE AC
command (or both) of the current transaction.
Offline DDA Performed
In both the first and second GENERATE AC response, this bit shall be set if and
only if Signed Dynamic Application Data is returned in the response to the
INTERNAL AUTHENTICATE command of the current transaction.
Issuer Authentication Not Performed
In the second GENERATE AC response, this bit shall be set if and only if the
CCD-compliant application did not receive Issuer Authentication Data. This may
be the case either if the transaction was unable to go online or if the issuer did
not provide Issuer Authentication Data in the response message.
In the first GENERATE AC response, this bit shall be set to the value it had in
the most recent second GENERATE AC response sent by the CCD-compliant
application.
EMV 4.2 Book 3 Common Core Definitions
Application Specification

June 2008 Page 197
Issuer Authentication Failed
This bit shall be set in the GENERATE AC response if and only if issuer
authentication was performed and failed. In the first GENERATE AC response,
it indicates issuer authentication failed in a previous online transaction. In the
second GENERATE AC response, it indicates either that issuer authentication
failed in the current transaction, or that issuer authentication failed in a
previous transaction and the bit was not reset.
Once set, this bit shall remain set until either:
- issuer authentication is successful,
- or all of the following conditions are true:
 the transaction successfully went online (that is, the Authorisation
Response Code does not indicate that the terminal was unable to go
online),
 issuer authentication was not performed,
 the CCD-compliant application does not require issuer authentication to
be performed for the application to approve (TC) an online transaction,
and
 the CCD-compliant application does not require issuer authentication to
pass for resetting of non-velocity-checking indicators.
Low Order Nibble of PIN Try Counter
In both the first and second GENERATE AC response, these bits shall be set to
the value of the low-order nibble (bits b4-b1) of the PIN Try Counter.
Offline PIN Verification Performed
In both the first and second GENERATE AC response, this bit shall be set if and
only if Offline PIN Verification has been performed (successfully or
unsuccessfully) on the current transaction.
Offline PIN Verification Performed and PIN Not Successfully Verified
In both the first and second GENERATE AC response, this bit shall be set if and
only if Offline PIN Verification has been performed on the current transaction
and the PIN was not successfully verified during processing of the current
transaction.
PIN Try Limit Exceeded
In both the first and second GENERATE AC response, this bit shall be set if and
only if the PIN Try Counter is zero.
Common Core Definitions EMV 4.2 Book 3
Application Specification

Page 198 June 2008
Last Online Transaction Not Completed
This bit shall be set in the first GENERATE AC response if and only if in the
previous transaction, the CCD-compliant application requested to go online and
the transaction was not completed (that is, the second GENERATE AC command
was not received).
Once set, this bit shall remain set until either:
- issuer authentication is successful,
- or all of the following conditions are true:
 the transaction successfully went online (that is, the Authorisation
Response Code does not indicate that the terminal was unable to go
online),
 issuer authentication was not performed,
 the CCD-compliant application does not require issuer authentication to
be performed for the application to approve (TC) an online transaction,
and
 the CCD-compliant application does not require issuer authentication to
pass for resetting of non-velocity-checking indicators.
- or all of the following conditions are true:
 the transaction successfully went online (that is, the Authorisation
Response Code does not indicate that the terminal was unable to go
online),
 issuer authentication was performed and failed,
 the CCD-compliant application does not require issuer authentication to
pass when performed for the application to approve (TC) an online
transaction, and
 the CCD-compliant application does not require issuer authentication to
pass for resetting of non-velocity-checking indicators.
Lower Offline Transaction Count Limit Exceeded
In both the first and second GENERATE AC response, this bit shall be set if the
CCD-compliant application has exceeded an issuer-specified lower limit for the
number of transactions approved offline. This bit may represent the condition of
multiple counters. At the least, all transactions approved offline whose amounts
were not cumulated shall be included in at least one transaction count. This bit
may also be set under additional conditions specified by the issuer.
EMV 4.2 Book 3 Common Core Definitions
Application Specification

June 2008 Page 199
Upper Offline Transaction Count Limit Exceeded
In both the first and second GENERATE AC response, this bit shall be set if the
CCD-compliant application has exceeded an issuer-specified upper limit for the
number of transactions approved offline. This bit may represent the condition of
multiple counters. At the least, all transactions approved offline whose amounts
were not cumulated shall be included in at least one transaction count. This bit
may also be set under additional conditions specified by the issuer.
Lower Cumulative Offline Amount Limit Exceeded
In both the first and second GENERATE AC response, this bit shall be set if the
CCD-compliant application has exceeded an issuer-specified lower limit for
cumulative amounts approved offline. This bit may represent the condition of
multiple counters. At the least, all domestic transactions approved offline shall
be included in at least one cumulative amount. This bit may also be set under
additional conditions specified by the issuer.
Upper Cumulative Offline Amount Limit Exceeded
In both the first and second GENERATE AC response, this bit shall be set if the
CCD-compliant application has exceeded an issuer-specified upper limit for
cumulative amounts approved offline. This bit may represent the condition of
multiple counters. At the least, all domestic transactions approved offline shall
be included in at least one cumulative amount. This bit may also be set under
additional conditions specified by the issuer.
Issuer-discretionary bit 1 – Issuer-discretionary bit 4:
These bits are set in the first and second GENERATE AC response at the
discretion of the issuer. The meaning of these bits is defined by the issuer and is
outside the scope of this specification.
Number of Successfully Processed Issuer Script Commands Containing
Secure Messaging
In the first and second GENERATE AC response, these bits shall be set to the
number of commands successfully processed with secure messaging.
Common Core Definitions EMV 4.2 Book 3
Application Specification

Page 200 June 2008
Issuer Script Processing Failed
In both the first and second GENERATE AC response, this bit shall be set if and
only if processing of a command with secure messaging failed.
Once set, this bit shall remain set until a subsequent GENERATE AC command
where either:
- issuer authentication is successful,
- or all of the following conditions are true:
 the transaction successfully went online (that is, the Authorisation
Response Code does not indicate that the terminal was unable to go
online),
 issuer authentication was not performed
 the CCD-compliant application does not require issuer authentication to
be performed for the application to approve (TC) an online transaction,
and
 the CCD-compliant application does not require issuer authentication to
pass for resetting of non-velocity-checking indicators.
- or all of the following conditions are true:
 the transaction successfully went online (that is, the Authorisation
Response Code does not indicate that the terminal was unable to go
online),
 issuer authentication was performed and failed,
 the CCD-compliant application does not require issuer authentication to
pass when performed for the application to approve (TC) an online
transaction, and
 the CCD-compliant application does not require issuer authentication to
pass for resetting of non-velocity-checking indicators.
Offline Data Authentication Failed on Previous Transaction
In both the first and second GENERATE AC response, this bit shall be set if and
only if, in the TVR returned during the previous transaction, any of the following
bits was set:
- SDA Failed
- DDA Failed
- CDA Failed
Once set, this bit shall remain set until a subsequent transaction is performed
that meets either of the following conditions:
- the previous transaction successfully went online, or
- the previous transaction was approved offline.
EMV 4.2 Book 3 Common Core Definitions
Application Specification

June 2008 Page 201
If either condition is met the bit is reset in the first GENERATE AC response.
Go Online on Next Transaction Was Set
In both the first and second GENERATE AC response, this bit shall be set if and
only if the ‗Set Go Online on Next Transaction‘ bit of the last successfully
recovered CSU was set, or it is a new card and the issuer has specified that a new
card is required to set the ‗Go Online on Next Transaction Was Set‘ bit.
Once set, this bit shall remain set until a subsequent GENERATE AC command
where either:
- all of the following conditions are true:
 issuer authentication is successful, and
 the Set Go Online on Next Transaction bit of the CSU is not set.
- or or all of the following conditions are true:
 the transaction successfully went online (that is, the Authorisation
Response Code does not indicate that the terminal was unable to go
online),
 issuer authentication was not performed,
 the CCD-compliant application does not require issuer authentication to
be performed for the application to approve (TC) an online transaction,
and
 the CCD-compliant application does not require issuer authentication to
pass for resetting of non-velocity-checking indicators.
- or all of the following conditions are true:
 the transaction successfully went online (that is, the Authorisation
Response Code does not indicate that the terminal was unable to go
online),
 issuer authentication was performed and failed,
 the CCD-compliant application does not require issuer authentication to
pass when performed for the application to approve (TC) an online
transaction, and
 the CCD-compliant application does not require issuer authentication for
resetting of non-velocity-checking indicatorss.
Unable to go Online
This bit shall be set in the second GENERATE AC response if and only if the
Authorization Response Code, tag '8A', returned from the terminal indicates the
terminal was unable to go online (set to 'Y3' or 'Z3').
Common Core Definitions EMV 4.2 Book 3
Application Specification

Page 202 June 2008
9.2.3.3 Mandatory Actions Due to CVR Bit Settings
This section provides a list of mandatory actions that shall be taken by the
CCD-compliant application, and issuer-configurable options that shall be
supported by the CCD-compliant application.
Issuer Authentication Not Performed
The issuer shall have the option of specifying that if this bit is set, whether the
CCD-compliant application shall:
- force transactions at online-capable terminals to go online,
- or allow the transaction to remain offline.
The issuer shall have the option of specifying that if this bit is set, and either the
transaction occurs at an offline-only terminal or the terminal is unable to go
online, whether the CCD-compliant application shall:
- be allowed to approve (TC) the transaction, or
- decline the transaction.
Issuer Authentication Failed
The issuer shall have the option of specifying that if this bit is set, whether the
CCD-compliant application shall:
- force transactions at online-capable terminals to go online,
- or allow the transaction to remain offline.
The issuer shall have the option of specifying that if this bit is set, and either the
transaction occurs at an offline-only terminal or the terminal is unable to go
online, whether the CCD-compliant application shall:
- be allowed to approve (TC) the transaction, or
- decline the transaction.
PIN Try Limit Exceeded
The issuer shall have the option of specifying that if this bit is set, the
CCD-compliant application shall decline the transaction offline.
The issuer shall have the option of specifying that if this bit is set, whether the
CCD-compliant application shall:
- force transactions at online-capable terminals to go online,
- or allow the transaction to remain offline.
EMV 4.2 Book 3 Common Core Definitions
Application Specification

June 2008 Page 203
The issuer shall have the option of specifying that if this bit is set, and either the
transaction occurs at an offline-only terminal or the terminal is unable to go
online, whether the CCD-compliant application shall:
- be allowed to approve (TC) the transaction, or
- decline the transaction.
The ICC shall not block the application or the card due to this bit being set.
Last Online Transaction Not Completed
If this bit is set, the CCD-compliant application shall force the transaction at
online-capable terminals to go online.
The issuer shall have the option of specifying that if this bit is set, and either the
transaction occurs at an offline-only terminal or the terminal is unable to go
online, whether the CCD-compliant application shall:
- be allowed to approve (TC) the transaction, or
- decline the transaction.
Lower Offline Transaction Count Limit Exceeded
If this bit is set in the first GENERATE AC response, the CCD-compliant
application shall force the transaction at online-capable terminals to go online.
Upper Offline Transaction Count Limit Exceeded
If this bit is set and either the transaction occurs at an offline-only terminal or
the terminal is unable to go online, the CCD-compliant application shall decline
the transaction. However, the issuer shall have the option of allowing the
CCD-compliant application to override this decline for a transaction at Terminal
Type 26.
Lower Cumulative Offline Amount Limit Exceeded
If this bit is set in the first GENERATE AC response, the CCD-compliant
application shall force the transaction at online-capable terminals to go online.
Upper Cumulative Offline Amount Limit Exceeded
If this bit is set and either the transaction occurs at an offline-only terminal or
the terminal is unable to go online, the CCD-compliant application shall decline
the transaction. However, the issuer shall have the option of allowing the
CCD-compliant application to override this decline for a transaction at Terminal
Type 26.
Common Core Definitions EMV 4.2 Book 3
Application Specification

Page 204 June 2008
Issuer Script Processing Failed
The issuer shall have the option of specifying that if this bit is set, whether the
CCD-compliant application shall:
- force transactions at online-capable terminals to go online,
- or allow the transaction to remain offline.
Go Online on Next Transaction Was Set
The issuer shall have the option of specifying that if this bit is set, and either the
transaction occurs at an offline-only terminal or the terminal is unable to go
online, whether the CCD-compliant application shall:
- be allowed to approve (TC) the transaction, or
- decline the transaction.
9.3 Command Use
The CCD-compliant application shall respond to the first GENERATE AC with
any of the following cryptogram types:
- TC
- ARQC
- AAC
The CCD-compliant application shall respond to the second GENERATE AC (if
applicable) with either of the following cryptogram types:
- TC
- AAC
EMV 4.2 Book 3 Common Core Definitions
Application Specification

June 2008 Page 205
10 Functions Used in Transaction Processing
10.5 Cardholder Verification
The CCD-compliant application shall support Cardholder Verification. It shall
indicate this by setting the Application Interchange Profile byte 1, bit 5 to 1.
10.5.1 Offline PIN Processing
The CCD-compliant application shall be capable of supporting offline plaintext
PIN verification. It is the Issuer‘s option whether or not to use offline plaintext
PIN as a cardholder verification method.
10.8 Card Action Analysis
The CCD-compliant application shall not request that the terminal send an
advice message to the issuer.
10.8.1 Terminal Messages for an AAC
The CCD-compliant application shall set bits b3-b1 of the CID to '000' in the
GENERATE AC command response.
10.8.2 Advice Messages
The CCD-compliant application shall not request the terminal to send an advice
message. Bit b4 of the Cryptogram Information Data shall be set to 0.
10.10 Issuer-to-Card Script Processing
An issuer shall send no more than one issuer script template in an authorization
response message. The script template may contain multiple commands. The
script template may be tag '71' or tag '72'.
Common Core Definitions EMV 4.2 Book 3
Application Specification

Page 206 June 2008
10.11 Completion
The following Section 10.11.1 applies to a CCD-compliant application.
10.11.1 Additional Completion Actions for a CCD-Compliant Application
10.11.1.1 Actions Taken by CCD-compliant Application After Issuer
Authentication is Successful
After issuer authentication is successful, if the ‗CSU Created by Proxy for the
Issuer‘ bit in the CSU is set to 1, and if the issuer specifies that ‗Update
Counters‘ shall not be used, then the following shall govern the behaviour of
velocity-checking counters and cumulative amounts associated with the offline
transaction limits referred to in bits b8-b5 of byte 3 of the CVR:
- If the issuer specifies that the application shall not update the offline
counters, no offline counter or cumulative amount is modified.
- If the issuer specifies that the application shall set the offline counters to
zero, the application will reset all the offline counters and cumulative
amounts to zero. By doing so, the issuer allows the application to accept
offline transactions, up to the offline limits.
- If the issuer specifies that the application shall set the offline counters to the
upper offline limits, the offline counters and cumulative amounts will be set
to their respective upper limits.
- If the issuer specifies that the application shall add the transaction to the
offline counter(s), the transaction will be included in the offline counters or
cumulative amounts as if it were an offline transaction.
This section describes the actions to be taken by the CCD-compliant application
due to the setting of each bit in the CSU after issuer authentication is successful..
Issuer Approves Online Transaction
If ‗Issuer Approves Online Transaction‘ is set and the terminal requests a TC, the
application shall approve the transaction by returning a TC.
If ‗Issuer Approves Online Transaction‘ is not set, the application shall decline
the transaction by returning an AAC.
Card Block
If ‗Card Block‘ is set, all applications in the ICC shall be permanently disabled,
including applications that may be selected implicitly. For all subsequent
SELECT commands the card shall return the status bytes ‗Function not
supported‘ (SW1-SW2 = '6A81') and perform no other action.
EMV 4.2 Book 3 Common Core Definitions
Application Specification

June 2008 Page 207
Application Block
If ‗Application Block‘ is set, the currently selected application shall be
invalidated. An invalidated application shall return the status bytes ‗Selected file
invalidated‘ (SW1-SW2 = '6283') in response to a SELECT command and return
only an AAC in response to the GENERATE AC command.
Update PIN Try Counter
If ‗Update PIN Try Counter‘ is set, the application shall update the PIN Try
Counter (PTC) with the value contained in bits b4-b1 of byte 1 of the CSU. If the
PIN is blocked, updating the value of the PTC with a non-zero value unblocks the
PIN. Updating the value of the PTC with a zero value blocks the PIN.
If ‗Update PIN Try Counter‘ is not set, no update of the PTC shall be performed
by the application.
The value contained in bits b4-b1 of byte 1 of the CSU shall never be interpreted
by the application.
Set Go Online on Next Transaction
If ‗Set Go Online on Next Transaction‘ is set, the application shall force
subsequent transactions at online-capable terminals to go online (that is, the
CCD-compliant application shall return an ARQC in response to the first
GENERATE AC command if a TC or an ARQC is requested). The application
shall continue to try to go online at online-cable terminals until a subsequent
GENERATE AC command where either:
- all of the following conditions are true:
 issuer authentication is successful, and
 the Set Go Online on Next Transaction bit of the CSU is not set.
- or all of the following conditions are true:
 the transaction successfully went online (that is, the Authorisation
Response Code does not indicate that the terminal was unable to go
online),
 issuer authentication was not performed,
 the CCD-compliant application does not require issuer authentication to
be performed for the application to approve (TC) an online transaction,
and
 the CCD-compliant application does not require issuer authentication to
pass for resetting of non-velocity-checking indicators.‖
- or all of the following conditions are true:
 the transaction successfully went online (that is, the Authorisation
Response Code does not indicate that the terminal was unable to go
online),
Common Core Definitions EMV 4.2 Book 3
Application Specification

Page 208 June 2008
 issuer authentication was performed and failed,
 the CCD-compliant application does not require issuer authentication to
pass when performed for the application to approve (TC) an online
transaction, and
 the CCD-compliant application does not require issuer authentication to
pass for resetting of non-velocity-checking indicators.
Update Counters
‗Update Counters‘ (bits b2-b1 of byte 2 of the CSU) govern the behaviour of
velocity-checking counters and cumulative amounts associated with the offline
transaction limits referred to in bits b8-b5 of byte 3 of the CVR if either of the
following is true:
- the ‗CSU Created by Proxy for the Issuer‘ bit in the CSU is set to 0
- the issuer specifies that the application shall use the ‗Update Counters‘ bits
in the CSU to update the velocity-checking count(s) and cumulative
amount(s) regardless of the bit setting for ‗CSU Created by Proxy for the
Issuer‘
If ‗Update Counters‘ is set to ‗Do Not Update Offline Counters‘, no offline counter
or cumulative amount shall be modified.
If ‗Update Counters‘ is set to ‗Reset Offline Counters to Zero‘, the application
shall reset all the offline counters and cumulative amounts to zero. By doing so,
the issuer allows the application to accept offline transactions, up to the offline
limits.
If ‗Update Counters‘ is set to ‗Set Offline Counters to Upper Offline Limits‘, the
application shall set the offline counters and cumulative amounts to their
respective upper limits.
If ‗Update Counters‘ is set to ‗Add Transaction to Offline Counters‘, the
application shall include the transaction in the offline counters or cumulative
amounts as if it were an offline transaction.
10.11.1.2 Other Completion Actions
After the transaction successfully went online (that is, the Authorisation
Response Code does not indicate that the terminal was unable to go online), the
CCD-compliant application shall reset to zero the velocity-checking offline
transaction count(s) and cumulative offline amount(s) if either of the following
are true:
- all of the following conditions are true:
 the terminal requested a TC,
 issuer authentication was not performed,
EMV 4.2 Book 3 Common Core Definitions
Application Specification

June 2008 Page 209
 the CCD-compliant application does not require issuer authentication to
be performed for the application to approve (TC) an online transaction,
and
 the CCD-compliant application does not require issuer authentication to
pass for resetting of velocity-checking counters.
- or all of the following conditions are true:
 the terminal requested a TC,
 issuer authentication was performed and failed,
 the CCD-compliant application does not require issuer authentication to
pass when performed for the application to approve (TC) an online
transaction, and
 the CCD-compliant application does not require issuer authentication to
pass for resetting of velocity-checking counters.
After the transaction successfully went online (that is, the Authorisation
Response Code does not indicate that the terminal was unable to go online), the
CCD-compliant application shall approve the transaction if all of the following
conditions are true:
- the terminal requested a TC, and
- one of the following is true:
 issuer authentication is successful and the ‗Issuer Approves Online
Transaction bit‘ of the recovered CSU is set to 1, or
 issuer authentication was not performed and the CCD-compliant
application does not require issuer authentication to be performed for the
application to approve (TC) an online transaction, or
 issuer authentication was performed and failed and the CCD-compliant
application does not require issuer authentication to pass when performed
for the application to approve (TC) an online transaction.
After the transaction successfully went online (that is, the Authorisation
Response Code does not indicate that the terminal was unable to go online), the
CCD-compliant application shall decline the transaction in the second
GENERATE AC response if either of the following conditions are true:
- both of the following are true:
 issuer authentication was not performed, and
 the CCD-compliant application requires issuer authentication to be
performed for the application to approve (TC) an online transaction,
- or both of the following are true:
 issuer authentication was performed and failed, and
Common Core Definitions EMV 4.2 Book 3
Application Specification

Page 210 June 2008
 the CCD-compliant application requires issuer authentication to pass
when performed for the application to approve (TC) an online transactionl.
After the transaction did not successfully complete online (that is the
Authorisation Response Code indicates that the terminal was unable to go
online), the CCD-compliant application shall decide whether to approve or
decline the transaction.
Part IV - Annexes
Annex A Data Elements Dictionary
For the data elements shown in Table CCD 6:
- If the source is ‗Terminal‘, the data element shall not be included in any DOL
used by a CCD-compliant application.
- If the source is ‗ICC‘, the data element shall not be identified in the AFL of a
CCD-compliant application.

Data Element Name Tag Source
Amount, Reference Currency '9F3A' Terminal
Application Reference Currency '9F3B' ICC
Application Reference Currency Exponent '9F43' ICC
Default Dynamic Data Authentication Data
Object List (DDOL)
— Terminal
Transaction Certificate (TC) Hash Value '98' Terminal
Table CCD 6: Data Elements Not Used by a CCD-Compliant Application
Table CCD 7 lists data elements (in addition to those defined in Annex A) that
are defined within the context of the Common Core Definitions.
EMV 4.2 Book 3 Common Core Definitions
Application Specification

June 2008 Page 211
Name Description Source Format Templat
e
T
a
g
Leng
th
Card
Verification
Results (CVR)
Contains data sent to the
issuer indicating exception
conditions that occurred
during the current and
previous transactions.
Transmitted to the
terminal in Issuer
Application Data as
specified in Table CCD 9.
ICC b — — 5
Common Core
Identifier
(CCI)
Data sent to the issuer
identifying the format of
the Issuer Application
Data and the method for
calculating the Application
Cryptogram. Transmitted
to the terminal in Issuer
Application Data as
specified in Table CCD 9.
Contains the following:
Format Code (FC)
Cryptogram Version
(CV)
ICC b — — 1
Derivation
Key Index
(DKI)
Data sent to the issuer
identifying the issuer‘s
derivation key for deriving
the card‘s ICC Master
Keys. Transmitted to the
terminal in Issuer
Application Data as
specified in Table CCD 9.
ICC b — — 1
Issuer
Discretionary
Data
Contains issuer
proprietary application
data for transmission to
the issuer in an online
transaction. Transmitted
to the terminal in Issuer
Application Data as
specified in Table CCD 9.
ICC b — — 15
Table CCD 7: Additional Data Elements Defined for CCD
Common Core Definitions EMV 4.2 Book 3
Application Specification

Page 212 June 2008
Annex C Coding of Data Elements Used in
Transaction Processing
Please add the following sections after Annex C.6.
C7 Issuer Application Data for a Common Core Definitions-
Compliant Application
The CCD-compliant application shall have an Issuer Application Data (IAD) field
of fixed length, 32 bytes long, with the following attributes:
- Byte 1 shall be set to '0F'.
- Byte 2 shall be the Common Core Identifier (CCI).
- Byte 17 shall be set to '0F'.
The CCD-compliant application shall support the selection of different Issuer
Application Data if:
- the card requests the Terminal Type and the Additional Terminal
Capabilities in PDOL, and
- the values provided by the terminal in the PDOL related data for the
Terminal Type and the first two bytes of the Additional Terminal Capabilities
are '34‘ and '0000' respectively.
C7.1 Common Core Identifier
The CCI shall identify the format of the IAD, and the Cryptogram Version (CV).
Values in the range '00' to '9F' are reserved to avoid conflict with legacy
Cryptogram Version Numbers.

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x x x x Common Core IAD Format Code (FC).
1 0 1 0 CCD Version 4.1 IAD Format (= ‗A‘)
x x x x Common Core Cryptogram Version (CV)
0 1 0 1
CCD Version 4.1 Cryptogram Version
(= ‗5‘)
Table CCD 8: Common Core Identifier
Bits b8 - b5 of the CCI shall indicate the Format Code (FC). Values in the range
'A' - 'F' shall indicate a CCD-specified IAD format (all values RFU by EMVCo for
CCD).
EMV 4.2 Book 3 Common Core Definitions
Application Specification

June 2008 Page 213
Bits b4 - b1 of the CCI shall indicate the Cryptogram Version (CV) for the
Application Cryptogram. The CV indicates:
- The cryptogram input data and key derivation method the CCD-compliant
application uses to generate the Application Cryptogram.
- The cryptogram input data (including CSU coding), key derivation method,
and ARPC method the CCD-compliant application expects the issuer to use
when generating the Authorisation Response Cryptogram.
Values in the range '4' - 'F' shall indicate a CCD-specified cryptogram algorithm
and data set (all values RFU by EMVCo for CCD). Values in the range '0' - '3'
shall indicate a proprietary cryptogram algorithm. When using the CV range
'0' - '3', applications are not CCD-compliant.
C7.2 Issuer Application Data for Format Code ‘A’
The format and coding of the IAD with a Format Code of ‗A‘ shall be as shown in
Table CCD 9:

Byte(s) Contents Description
1 Length Indicator Length of EMVCo-defined data in IAD. Set to '0F'.
2 CCI Common Core Identifier
3 DKI Derivation Key Index
4-8 CVR Card Verification Results (see section C7.3)
9-16 Counters Contents are at the discretion of the Payment
System.
17 Length Indicator Length of Issuer Discretionary Data field in IAD.
Set to '0F'.
18-32 Issuer
Discretionary
Data
Contents are at the discretion of the issuer.
Table CCD 9: Issuer Application Data for Format Code ‘A’
Common Core Definitions EMV 4.2 Book 3
Application Specification

Page 214 June 2008
C7.3 Card Verification Results
The coding of the CVR for a Common Core IAD Format Code of value ‗A‘ shall be
as shown in Table CCD 10.
CVR Byte 1
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x x
Application Cryptogram Type Returned in
Second GENERATE AC
0 0 AAC
0 1 TC
1 0 Second GENERATE AC Not Requested
1 1 RFU
x x
Application Cryptogram Type Returned in
First GENERATE AC
0 0 AAC
0 1 TC
1 0 ARQC
1 1 RFU
1 CDA Performed
1 Offline DDA Performed
1 Issuer Authentication Not Performed
1 Issuer Authentication Failed
CVR Byte 2
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x x x x Low Order Nibble of PIN Try Counter
1 Offline PIN Verification Performed
1
Offline PIN Verification Performed and
PIN Not Successfully Verified
1 PIN Try Limit Exceeded
1 Last Online Transaction Not Completed
Table CCD 10: Card Verification Results for Format Code ‘A’
EMV 4.2 Book 3 Common Core Definitions
Application Specification

June 2008 Page 215
CVR Byte 3
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1
Lower Offline Transaction Count Limit
Exceeded
1
Upper Offline Transaction Count Limit
Exceeded
1
Lower Cumulative Offline Amount Limit
Exceeded
1
Upper Cumulative Offline Amount Limit
Exceeded
1 Issuer-discretionary bit 1
1 Issuer-discretionary bit 2
1 Issuer-discretionary bit 3
1 Issuer-discretionary bit 4
CVR Byte 4
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x x x x
Number of Successfully Processed Issuer
Script Commands Containing Secure
Messaging
1 Issuer Script Processing Failed
1
Offline Data Authentication Failed on
Previous Transaction
1 Go Online on Next Transaction Was Set
1 Unable to go Online
CVR Byte 5
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 0 0 0 0 0 0 0 RFU
Table CCD 10: Card Verification Results for Format Code ‘A’, continued
Common Core Definitions EMV 4.2 Book 3
Application Specification

Page 216 June 2008
C8 Card Status Update for a Common Core Definitions-
Compliant Application
The Issuer Authentication Data shall include a Card Status Update (CSU) of
fixed length, 4 bytes long. The coding of the CSU is shown in Table CCD 11.
CSU Byte 1
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Proprietary Authentication Data Included
0 0 0 RFU
x x x x PIN Try Counter
CSU Byte 2
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Issuer Approves Online Transaction
1 Card Block
1 Application Block
1 Update PIN Try Counter
1 Set Go Online on Next Transaction
1 CSU Created by Proxy for the Issuer
x x Update Counters
0 0 Do Not Update Offline Counters
0 1
Set Offline Counters to Upper Offline
Limits
1 0 Reset Offline Counters to Zero
1 1 Add Transaction to Offline Counter

Note: The ‗CSU Created by Proxy for the Issuer‘ bit shall be set in the CSU if and only if
the CSU is generated by a proxy for the Issuer.
Table CCD 11: Card Status Update for Cryptogram Version ‘5’
EMV 4.2 Book 3 Common Core Definitions
Application Specification

June 2008 Page 217
CSU Byte 3
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 0 0 0 0 0 0 0 RFU
CSU Byte 4
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x x x x x x x x Issuer-Discretionary
Table CCD 11: Card Status Update for Cryptogram Version ‘5’, continued
The default value for issuer-discretionary data in the CSU is zero.
Annex D Transaction Log Information
If the CCD-compliant application supports transaction logging, it shall be
supported using the method specified in Annex D.
EMV 4.2 Book 3
Application Specification

June 2008 Page 219
Index
A
Abbreviations ..................................................... 19
AC ............................. See Application Cryptogram
Account Type ........................................... 131, 185
Acquirer Identifier .................................... 131, 146
Additional Terminal Capabilities ....................... 131
Advice Messages .............................................. 122
AFL ......................... 63, 64, 78, 81, 95, 96, 98, 133
AID ............................................. 37, 133, 135, 148
AIP.... 63, 64, 80, 81, 82, 83, 85, 93, 94, 97, 98, 103,
113, 123, 124, 133
Coding ......................................................... 166
Amount ............................................................ 150
Amount, Authorised .......................................... 104
API................................................................... 134
APPLICATION BLOCK .................................... 49
Application Cryptogram ...... 49, 56, 58, 80, 123, 132
Application Currency Code 103, 104, 132, 134, 151,
169
Application Currency Exponent ......................... 132
Application Discretionary Data ......................... 132
Application Effective Date ........................ 102, 132
Application Elementary File ........... 37, 38, 147, 164
Application Expiration Date ................. 78, 102, 133
Application File Locator ........................... See AFL
Application Identifier .................................See AID
Application Interchange Profile .................. See AIP
Application Label ............................................. 133
Application Preferred Name ...................... 133, 143
Application Primary Account Number (PAN) ..... 78,
133
Application Priority Indicator ............................ 134
Application Template ........................................ 135
Application Transaction Counter ............... See ATC
APPLICATION UNBLOCK ............................... 51
Application Usage Control ................. 100, 101, 135
Coding ......................................................... 167
Application Version Number ..................... 100, 135
ATC ........................... 58, 61, 80, 82, 116, 135, 145
AUC .......................................... 100, 101, 135, 167
Authorisation Code ........................................... 136
Authorisation Response Code ............................ 136
B
Bank Identifier Code ......................................... 136
BER-TLV Data Objects .................................... 161
BIC ..................................See Bank Identifier Code
C
Card Action Analysis ........................................ 121
CARD BLOCK .................................................. 52
Card Risk Management Data Object List 1 ........ See
CDOL1
Card Risk Management Data Object List 2 ........ See
CDOL2
Cardholder Name .............................................. 137
Cardholder Verification ............................ See CVM
Cardholder Verification Method ............... See CVM
CCD ........................ See Common Core Definitions
CDA ........................................................... 98, 166
CDOL1 ........................................... 38, 89, 90, 136
CDOL2 ...................................................... 38, 136
CID ............................................... 58, 59, 122, 138
Class Byte .......................................................... 42
Coding Conventions ............................................ 42
Command ............................................ 41, 138, 144
Command APDU Structure ................................. 41
Commands ......................................................... 48
APPLICATION BLOCK ................................ 49
APPLICATION UNBLOCK .......................... 51
CARD BLOCK .............................................. 52
EXTERNAL AUTHENTICATE .................... 54
GENERATE AC ...................................... 56, 87
GET CHALLENGE ....................................... 60
GET DATA ................................................... 61
GET PROCESSING OPTIONS ...................... 63
INTERNAL AUTHENTICATE...................... 65
PIN CHANGE/UNBLOCK ............................ 67
READ RECORD............................................ 69
VERIFY ........................................................ 71
Common Core Definitions................................. 189
Card Status Update ....................................... 216
Card Verification Results .............................. 214
Cardholder Verification ................................ 205
CID Coding.................................................. 191
Common Core Identifier ............................... 212
Completion .................................................. 206
Data Elements .............................................. 210
Data Retrievable by GET DATA Command .. 193
EXTERNAL AUTHENTICATE .................. 190
Functions Used in Transaction Processing ..... 206
GENERATE AC
Command Coding .................................... 194
GENERATE AC .......................................... 190
GENERATE AC Command Use ................... 204
GET PROCESSING OPTIONS .................... 191
INTERNAL AUTHENTICATE.................... 192
Issuer Application Data ........................ 212, 213
Issuer-to-Card Script Processing ................... 205
Offline PIN Processing ................................. 205
Response APDU Format ............................... 190
Completion ....................................................... 127
Index EMV 4.2 Book 3
Application Specification

Page 220 June 2008
Country Code ........................................... 101, 143
Cryptogram ................................... 56, 58, 117, 132
Cryptogram Information Data..................... See CID
Cryptogram Types .............................................. 56
CSU .................................................. 195, 206, 208
Currency........................................................... 134
Currency Code ................................... 134, 151, 169
Currency exponent ............................................ 151
CV Rule
Coding ......................................................... 168
CVM ....... 71, 82, 103, 106, 107, 137, 148, 168, 169
D
DAC ................................................................. 138
Data Authentication Code ................................. 138
Data Element Format Conventions ...................... 29
Data Elements and Files ...................................... 35
Data Elements Dictionary .................................. 131
Data Field Bytes ................................................. 44
Data Object List (DOL) ....................................... 38
Data Objects ....................................................... 36
Classes ........................................................... 36
DDF ........................................................... 37, 139
DDOL ............................................. 38, 65, 79, 139
Definitions ........................................................... 9
DF Name .......................................................... 138
Directory Definition File ........................... See DDF
Directory Definition File (DDF) Name .............. 139
Directory Definition File Name ................. 139, 147
Directory Discretionary Template ...................... 139
Dynamic Data Authentication Data Object List .. See
DDOL
E
Erroneous Data ................................................... 81
Exception Handling ............................................ 83
Exponent .......................................................... 134
EXTERNAL AUTHENTICATE ......................... 54
Status Words Returned ................................. 183
F
FCI ................................................................... 140
FCI Issuer Discretionary Data ............... 35, 94, 140
File Control Information ............................ See FCI
Files ................................................................... 37
Financial Transaction .............................. 35, 41, 77
Floor Limit ....................................................... 148
Floor Limits ...................................................... 114
Format 1 ........................................................... 147
Format 2 ........................................................... 147
Function
Card Action Analysis ................................... 121
Cardholder Verification ................................ 103
Completion .................................................. 127
Initiate Application Processing........................ 93
Issuer-to-Card Script Processing ................... 125
Offline Data Authentication ............................ 97
Offline PIN Processing ................................. 106
Online PIN Processing.................................. 107
Online Processing......................................... 123
Processing Restrictions ................................. 100
Read Application Data.................................... 95
Signature Processing .................................... 107
Terminal Action Analysis ............................. 117
Terminal Risk Management .......................... 113
Transaction Log ........................................... 175
G
GENERATE AC . 56, 57, 59, 87, 113, 117, 119, 120,
121, 122, 123, 124, 125, 126, 127, 136, 144
Cryptogram Types .......................................... 56
GET CHALLENGE ............................................ 60
GET DATA ........................................................ 61
GET PROCESSING OPTIONS ........................... 63
I
IAC .................................... See Issuer Action Code
IAD ............................................................ 58, 142
IBAN ....... See International Bank Account Number
ICC Dynamic Number ...................................... 140
IFD................................................................... 142
IIN ....................... See Issuer Identification Number
Initiate Application Processing ............................ 93
Instruction Byte .................................................. 43
Interface Device ........................................ 139, 142
INTERNAL AUTHENTICATE .......................... 65
International Bank Account Number .................. 142
Issuer Action Code ....................... 91, 117, 118, 142
Issuer Application Data ............................... 58, 142
Issuer Authentication Data ........... 54, 123, 124, 143
Issuer Code Table Index ............................ 143, 170
Issuer Country Code.......................................... 143
Issuer Identification Number ............................. 143
Issuer-to-Card Script Processing ........................ 125
L
Language .......................................................... 144
Last Online Application Transaction Counter ..... See
LATC
LATC ......................................................... 82, 145
LCOL ............................................ 80, 82, 116, 145
Log Entry ................................................. 145, 176
Log Format ............................................... 145, 177
Logical Channels ................................................ 47
Lower Consecutive Offline Limit ........... See LCOL
EMV 4.2 Book 3 Index
Application Specification

June 2008 Page 221
M
Mandatory Data Objects ...................................... 78
Mapping Data Objects ......................................... 77
MCC ................................................................ 145
Merchant Category Code ................................... 145
Merchant Identifier ........................................... 146
Missing Data ...................................................... 81
N
Non-velocity-checking indicators ...................... 194
Normative References .......................................... 5
Notations ............................................................ 27
O
Offline Data Authentication ................................ 97
Offline PIN Processing...................................... 106
Online PIN Processing ...................................... 107
Online Processing ............................................. 123
P
Padding
Data Elements .............................................. 153
DOL .............................................................. 39
PAN ........................................................... 78, 133
PAN Sequence Number..................................... 134
Parameter Bytes .................................................. 43
PDOL .............................................. 38, 63, 93, 146
Personal Identification Number .................. See PIN
PIN 46, 48, 61, 67, 71, 106, 107, 125, 139, 140, 141,
146, 151, 168, 169
PIN CHANGE/UNBLOCK ................................. 67
Point-of-Service (POS) Entry Mode................... 146
POS .................................................................. 146
Primary Account Number ............. 78, 114, 133, 146
Processing Options Data Object List ....... See PDOL
Processing Restrictions ..................................... 100
Public Key ....................................... 78, 79, 82, 137
Public Key Certificate ...................... 78, 79, 82, 143
Public Key Exponent ..................... 79, 82, 141, 143
Public Key Remainder ..................... 78, 79, 82, 144
R
Random Transaction Selection .......................... 114
Read Application Data ........................................ 95
READ RECORD ................................................ 69
Record ................................................................ 37
Reference Currency .......................................... 151
References
Normative ....................................................... 5
Response ............................................................ 42
Response APDU Structure .................................. 42
Revision Log ...................................................... iii
RFU Data ........................................................... 47
Rules for BER-TLV Data Objects...................... 161
S
Scope .................................................................. 3
Script........................................... 47, 125, 127, 144
SDA Tag List.............................................. 98, 148
SDAD ........................................... 65, 66, 141, 147
Service Code ............................................ 147, 150
SFI ................................................................... 147
Short File Identifier . 37, 38, 69, 81, 95, 98, 133, 147
Signature Processing ......................................... 107
Signed Dynamic Application Data .......... See SDAD
Signed Static Application Data ................ See SSAD
SSAD .................................... 79, 82, 138, 143, 147
Status Bytes ........................................................ 44
Status Words
EXTERNAL AUTHENTICATE .................. 183
SVC ......................................................... 147, 150
T
TC Hash value .................................................. 150
TDOL............................................ 38, 90, 139, 150
Template 70, 131, 135, 138, 139, 140, 144, 147, 154
Terminal Action Analysis .................................. 117
Terminal Action Code ........................ 117, 118, 148
Terminal Capabilities ................................ 131, 148
Terminal Country Code ..................................... 148
Terminal Identification ...................................... 149
Terminal Risk Management .............................. 149
Terminal Type .................................................. 149
Terminal Verification Results .................... See TVR
Terminology ....................................................... 31
Track 1 ............................................................. 149
Track 2 ............................................................. 149
Transaction Certificate Data Object List . See TDOL
Transaction Date ....................................... 114, 151
Transaction Flow ................................................ 83
Transaction Log Information ............................. 175
Transaction Personal Identification Number ....... 151
Transaction Sequence Counter........................... 152
Transaction Status Information ....................See TSI
Transaction Time .............................................. 152
Transaction Type .............................................. 152
TRM ........................................................ 113, 149
TSI 93, 97, 98, 99, 103, 105, 113, 121, 124, 126, 152
Bit Settings Following Script Processing ....... 179
Coding ......................................................... 174
TVR 81, 90, 93, 97, 98, 99, 100, 101, 102, 104, 105,
106, 107, 113, 114, 115, 116, 117, 123, 126, 149,
183
Index EMV 4.2 Book 3
Application Specification

Page 222 June 2008
Bit Settings Following Script Processing ....... 179
Coding ......................................................... 171
U
UCOL ........................................... 80, 82, 116, 152
UN ................................................................... 152
Unpredictable Number ...................................... 152
Upper Consecutive Offline Limit ............ See UCOL
URL ................................................................. 144
V
Velocity Checking ............................................ 116
VERIFY ............................................................. 71

EMV
Integrated Circuit Card Specifications for Payment Systems

Book 3
Application Specification
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 4.2 Book 3 Application Specification

Page ii

June 2008

2 The following changes have been made to Book 3 since the publication of Version 4. 55: Terminal Velocity Checking and CCD Specification Update Bulletin no. 54: Missing Mandatory Command Response Data Specification Update Bulletin no. 25: Issuer Application Data coding for CCD-compliant and Non CCD-compliant Applications Application Note no. 51: Online-only terminals Specification Update Bulletin no. 23: Data Elements in the PDOL Application Note no. Numbering and cross references in this version have been updated to reflect changes introduced by the published bulletins.EMV 4. 47: Support for Proprietary Authentication Data in CCD Specification Update Bulletin no.2 Book 3 Application Specification Revision Log . 41 Third Edition: Corrections to Common Core Definitions Specification Update Bulletin no. Incorporated changes described in the following Specification Updates: Specification Update Bulletin no. 45: Enciphered PIN Recovery Errors Specification Update Bulletin no. 46: Replacement of EMV Session Key Derivation Method Specification Update Bulletin no. 27: Terminal Behaviour for Goods & Services Checks during the Processing Restriction Function June 2008 Page iii .1. 42: Voice Referrals Specification Update Bulletin no. 48: CVM List Processing Specification Update Bulletin no. 66: CCD Setting of CDA Performed in the CVR Updated in support of the following Application Notes: Application Note no. 39: Definition of the new data element: ‗Account Type‘ Specification Update Bulletin no. 24: Coding of Transaction Type Application Note no. 44: CDA Modified Terminal Behaviour Specification Update Bulletin no.Version 4.

34: Padding of Bit Combination Data in DOLs Minor editorial clarifications. 32: Advice Requested in the Cryptogram Information Data Application Note no.1 of the EMV Specifications Page iv June 2008 . 37 Fourth Edition: Editorial Errors in Release 4. 31: Coding of the Length Field of BER-TLV Coded Data Objects not Sent Over the Card-Terminal Interface Application Note no. including those described in the following Specification Update: Specification Update Bulletin no.Revision Log EMV 4.2 Book 3 Application Specification Application Note no.

3 4.4 2 3 4 Changes in Version 4.1 1.2 4.3.1 Application Elementary Files 5.4 Abbreviations Notations Data Element Format Conventions Terminology Part II .4 Rules for Using a Data Object List (DOL) 6 Commands for Financial Transaction 6.2.3 1.2 Data Objects 5.1 4.1 6.3.3.General 1 Scope 1.2 Structure Underlying Standards Audience 3 3 3 4 4 5 9 19 19 27 29 31 Normative References Definitions Abbreviations.Data Elements and Commands 5 Data Elements and Files 5.2 Book 3 Application Specification Contents Part I .3 Coding Conventions 6.2 Command APDU Format Response APDU Format 6.1 Coding of the Class Byte 6.1 Classes of Data Objects 5.3.2 Coding of the Instruction Byte June 2008 Page v .EMV 4.2 1. Conventions. Notations.3 Files 5.1 Data Elements Associated with Financial Transaction Interchange 35 35 36 36 37 37 37 38 41 41 42 42 42 43 5. and Terminology 4.2 File Referencing 5.

2 Book 3 Application Specification 6.4 Coding of Data Field Bytes 6.7 GET DATA Command-Response APDUs 61 6.3.5.5.1 7.2 Command Data 9.3 Command Use Page vi June 2008 .3 Exception Handling Example Flowchart Additional Functions 9 GENERATE AC Command Coding 9.1 Card Risk Management Data 9.3.1 APPLICATION BLOCK Command-Response APDUs 49 6.6 Coding of RFU Data 6.2.1 8.5.EMV 4.2 APPLICATION UNBLOCK Command-Response APDUs 51 6.3 7.5.2 Transaction Certificate Data 9.2 8.4 Logical Channels 43 44 44 47 47 6.5.2 7.1 Command Parameters 9.8 GET PROCESSING OPTIONS Command-Response APDUs 63 6.5.10 PIN CHANGE/UNBLOCK Command-Response APDUs 67 6.Debit and Credit Application Specification 7 Files for Financial Transaction Interchange 7.4 EXTERNAL AUTHENTICATE Command-Response APDUs 54 6.5.5 GENERATE APPLICATION CRYPTOGRAM Command-Response APDUs 56 6.3.3 CARD BLOCK Command-Response APDUs 52 6.12 VERIFY Command-Response APDUs 71 Part III .5 8 Mapping Data Objects Mandatory Data Objects Data Retrievable by GET DATA Command Data Retrievable by GET PROCESSING OPTIONS Erroneous or Missing Data in the ICC 77 77 78 80 80 81 83 83 83 85 87 89 89 89 90 90 Transaction Flow 8.9 INTERNAL AUTHENTICATE Command-Response APDUs 65 6.4 7.2.5.3.3 Coding of Parameter Bytes 6.11 READ RECORD Command-Response APDUs 69 6.5.6 GET CHALLENGE Command-Response APDUs 60 6.5 Commands 48 6.5.5 Coding of the Status Bytes 6.5.5.

4.5.2 10.6.2 Online PIN Processing 10.1 Terminal Messages for an AAC 10.5.1 Offline PIN Processing 10.3 Initiate Application Processing Read Application Data Offline Data Authentication 10.2 Book 3 Application Specification 9.1 9.3.2 GENERATE AC (First Issuance) GENERATE AC (Second Issuance) 91 91 93 93 95 97 100 100 101 102 103 106 107 107 107 107 113 114 114 116 117 121 122 122 123 125 127 10 Functions Used in Transaction Processing 10.6 Terminal Risk Management 10.1 10.5.9 Online Processing 10.6.4 Combination CVMs 10.2 Application Usage Control 10.1 Application Version Number 10.3 Velocity Checking 10.4.8 Card Action Analysis 10.2 Advice Messages 10.11 Issuer-to-Card Script Processing Completion Part IV .5.5 CVM Processing Logic 10.8.Annexes Annex A A1 A2 Annex B B1 B2 Data Elements Dictionary Data Elements by Name Data Elements by Tag Rules for BER-TLV Data Objects Coding of the Tag Field of BER-TLV Data Objects Coding of the Length Field of BER-TLV Data Objects 131 131 154 161 162 163 June 2008 Page vii .4.8.6.3 Signature Processing 10.5 Cardholder Verification 10.5.3.3 Application Effective/Expiration Dates Checking 10.4 Processing Restrictions 10.2 Random Transaction Selection 10.10 10.7 Terminal Action Analysis 10.EMV 4.1 Floor Limits 10.

EMV 4.Common Core Definitions Introduction Changed and Added Sections 6 Commands for Financial Transaction 6.5 Commands 6.4 EXTERNAL AUTHENTICATE Command-Response APDUs 6.5.5.2 Response APDU Format 6.5.5.9 INTERNAL AUTHENTICATE Command-Response APDUs 189 189 190 190 190 190 190 191 192 Page viii June 2008 .8 GET PROCESSING OPTIONS Command-Response APDUs 6.2 Book 3 Application Specification B3 Annex C C1 C2 C3 C4 C5 C6 Annex D D1 D2 D3 D4 D5 Annex E E1 E2 Annex F Coding of the Value Field of Data Objects Coding of Data Elements Used in Transaction Processing Application Interchange Profile Application Usage Control Cardholder Verification Rule Format Issuer Code Table Index Terminal Verification Results Transaction Status Information Transaction Log Information Purpose Conditions of Execution Sequence of Execution Description Example TVR and TSI Bit Settings Following Script Processing Scenarios Additional Information Status Words Returned in EXTERNAL AUTHENTICATE 164 165 166 167 168 170 171 174 175 175 175 175 176 177 179 179 181 183 Part V .5 GENERATE APPLICATION CRYPTOGRAM CommandResponse APDUs 6.

2 Advice Messages 10.5.3 Command Use 10 Functions Used in Transaction Processing 10.2 Issuer Application Data for Format Code ‗A‘ C7.3 Data Retrievable by GET DATA Command 9 GENERATE AC Command Coding 9.5 Cardholder Verification 10.11.2 Book 3 Application Specification 7 Files for Financial Transaction Interchange 7.10 Issuer-to-Card Script Processing 10.1 Common Core Identifier C7.3 Card Verification Results C8 Card Status Update for a Common Core Definitions-Compliant Application Annex D Transaction Log Information 193 193 194 194 194 194 204 205 205 205 205 205 205 205 206 206 210 212 212 212 213 214 216 217 Index 219 June 2008 Page ix .8.8.11 Completion 10.8 Card Action Analysis 10.EMV 4.1 Offline PIN Processing 10.1 Terminal Messages for an AAC 10.1 Additional Completion Actions for a CCD-Compliant Application Annex A Data Elements Dictionary Annex C Coding of Data Elements Used in Transaction Processing C7 Issuer Application Data for a Common Core Definitions-Compliant Application C7.3 Common Core Definitions Card Verification Results 9.2 Command Data 9.2 Transaction Certificate Data 9.2.2.

EMV 4.2 Book 3 Application Specification Page x June 2008 .

EMV 4.2 Book 3 Application Specification Tables Table 1: Structure of SFI Table 2: Most Significant Nibble of the Class Byte Table 3: Coding of the Instruction Byte Table 4: Coding of Status Bytes SW1 SW2 Table 5: Allocation of Status Bytes Table 6: APPLICATION BLOCK Command Message Table 7: APPLICATION UNBLOCK Command Message Table 8: CARD BLOCK Command Message Table 9: EXTERNAL AUTHENTICATE Command Message Table 10: GENERATE AC Cryptogram Types Table 11: GENERATE AC Command Message Table 12: GENERATE AC Reference Control Parameter Table 13: Format 1 GENERATE AC Response Message Data Field Table 14: Coding of Cryptogram Information Data Table 15: GET CHALLENGE Command Message Table 16: GET DATA Command Message Table 17: GET PROCESSING OPTIONS Command Message Table 18: INTERNAL AUTHENTICATE Command Message Table 19: PIN CHANGE/UNBLOCK Command Message Table 20: READ RECORD Command Message Table 21: READ RECORD Command Reference Control Parameter Table 22: VERIFY Command Message Table 23: VERIFY Command qualifier of reference data (P2) Table 24: Plaintext Offline PIN Block Format Table 25: Data Objects Used by the Offline Data Authentication Algorithm Table 26: Mandatory Data Objects Table 27: Data Required for SDA Table 28: Data Required for DDA and/or CDA Table 29: Data Objects Retrievable by GET DATA Command Table 30: Data Retrievable by GET PROCESSING OPTIONS Table 31: ICC Data Missing Indicator Setting 38 42 43 45 46 49 51 52 54 56 57 57 58 59 60 61 63 65 68 69 69 71 72 73 78 78 79 79 80 80 82 June 2008 Page xi .

EMV 4.2 Book 3 Application Specification Table 32: Terminal Action Regarding Application Usage Control Table 33: Data Elements Dictionary Table 34: Data Elements Tags Table 35: Tag Field Structure (First Byte) BER-TLV Table 36: Tag Field Structure (Subsequent Bytes) BER-TLV Table 37: Application Interchange Profile Table 38: Application Usage Control Table 39: CVM Codes Table 40: CVM Condition Codes Table 41: Issuer Code Table Index Table 42: Terminal Verification Results Table 43: Transaction Status Information Table 44: Log Entry Table 45: Example of Log Format 101 131 154 162 162 166 167 168 169 170 171 174 176 177 Table 46: Terminal Action after (First) EXTERNAL AUTHENTICATE Response 183 Table 47: Account Type Table CCD 1: Body of Response APDU Structure Table CCD 2: Format 2 GENERATE AC Response Message Data Field Table CCD 3: Coding of Cryptogram Information Data 185 190 191 191 Table CCD 4: Format 2 GET PROCESSING OPTIONS Response Message Data Field 192 Table CCD 5: Format 2 Internal Authenticate Response Message Data Field 192 Table CCD 6: Data Elements Not Used by a CCD-Compliant Application Table CCD 7: Additional Data Elements Defined for CCD Table CCD 8: Common Core Identifier Table CCD 9: Issuer Application Data for Format Code ‗A‘ Table CCD 10: Card Verification Results for Format Code ‗A‘ Table CCD 11: Card Status Update for Cryptogram Version ‗5‘ 210 211 212 213 214 216 Page xii June 2008 .

EMV 4.2 Book 3 Application Specification Figures Figure 1: Command APDU Structure Figure 2: Response APDU Structure Figure 3: Structural Scheme of Status Bytes 41 42 44 Figure 4: Format 1 GET PROCESSING OPTIONS Response Message Data Field 64 Figure 5: READ RECORD Response Message Data Field Figure 6: Transaction Flow Example Figure 7: Use of GENERATE AC Options Figure 8: CVM Processing (Part 1 of 5) Figure 9: CVM Processing (Part 2 of 5) Figure 10: CVM Processing (Part 3 of 5) Figure 11: CVM Processing (Part 4 of 5) Figure 12: CVM Processing (Part 5 of 5) Figure 13: Random Transaction Selection Example Figure 14: Issuer Script Format Figure 15: Issuer Script Command Format (Shown with Three Commands) Figure 16: Primitive BER-TLV Data Object (Data Element) Figure 17: Constructed BER-TLV Data Object 70 84 88 108 109 110 111 112 115 126 126 164 164 June 2008 Page xiii .

2 Book 3 Application Specification Page xiv June 2008 .EMV 4.

EMV 4.2 Book 3 Application Specification Part I General June 2008 Page 1 .

2 Book 3 Application Specification Page 2 June 2008 .EMV 4.

The Integrated Circuit Card Specifications for Payment Systems includes the following additional documents. abbreviations. The Revision Log at the beginning of the Book provides additional detail about changes to this specification. June 2008 Page 3 . the Integrated Circuit Card Specifications for Payment Systems Book 3. and Acquirer Interface Requirements 1. etc. Attendant. Application Specification defines the terminal and integrated circuit card (ICC) procedures necessary to effect a payment system transaction in an international interchange environment. Application Notes. Part II describes data elements and files as well as commands for financial transaction.2 This release incorporates all relevant Specification Update Bulletins. published up to the date of this release.1 Changes in Version 4.EMV 4. definitions. 1. all available on http://www.emvco.com:    Book 1 . as well as data applicable to all Books: normative references. notations. data element format convention. amendments.Application Independent ICC to Terminal Interface Requirements Book 2 .Security and Key Management Book 4 .2 Book 3 Application Specification 1 Scope This document.Cardholder.2 Structure Book 3 consists of the following parts: Part I Part II Part III Part IV Part V General Data Elements and Commands Debit and Credit Application Specification Annexes Common Core Definitions Part I includes this introduction. and terminology.

4 Audience This specification is intended for use by manufacturers of ICCs and terminals. It discusses TVR and TSI bit settings following script processing. Part IV includes a complete data elements dictionary.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.3 Underlying Standards EMV 4.1 Scope 1. and transaction log information. but are not precluded. The Book also includes a revision log and an index. Application functions unique to individual payment systems and those functions not performed in interchange are not described. system designers in payment systems. The functions described are those necessary to ensure that payment system cards conforming to this specification can perform a set of core functions in terminals conforming to this specification.2 Book 3 Application Specification Part III specifies the debit and credit application functions including:    Transaction flow (the sequence of events and the commands issued to the card) Exception processing Definition of data elements and commands as they apply to the exchange of information between an ICC and a terminal. instructions for coding of specific data elements. and Status Words returned in response to an EXTERNAL AUTHENTICATE command. if any of the provisions or definitions in this specification differ from those standards. 1. the provisions herein shall take precedence. This specification does not address clearing and settlement or any transactions where the ICC is not present. and financial institution staff responsible for implementing financial applications in ICCs. Part V defines an optional extension to be used when implementing a card complying to the Common Core Definitions (CCD).   Structure and referencing of files The usage of commands between the ICC and the terminal to achieve application level functions. rules for BER-TLV data objects. Page 4 June 2008 . 1. In particular.

EMV 4. Additions/changes to ISO 639-1:1988: Codes for the Representation of Names of Languages are available on: http://www.gov/standards/iso6392/php/code_changes. 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. The latest version shall apply unless a publication date is explicitly stated.loc.2 Book 3 Application Specification 2 Normative References The following standards contain provisions that are referenced in these specifications.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 .

Part 1: Mechanisms using a block cipher Information technology – Security techniques – Modes of operation for an n-bit 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 ISO/IEC 10116 Page 6 June 2008 . 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 .1 encoding rules: Specification of Basic Encoding Rules (BER). 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.2 Normative References EMV 4.2 Book 3 Application Specification ISO/IEC 7816-4 Identification cards — Integrated circuit cards — Part 4: Organization.

EMV 4. 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 Book 3 Application Specification 2 Normative References ISO/IEC 10118-3 ISO/IEC 10373 ISO 13491-1 Information technology – Security techniques – Hash-functions – Part 3: Dedicated hash-functions Identification cards – Test methods Banking – Secure cryptographic devices (retail) – Part 1: Concepts.

2 Normative References EMV 4.2 Book 3 Application Specification Page 8 June 2008 .

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

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

It contains the error detection code (EDC) byte(s). 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. A form of offline dynamic data authentication Characters raised in relief from the front surface of a card. Binary addition with no carry. and the sender against forgery by the recipient. The final field of a block.5 of Book 1. A process accomplished by one or more commands and resultant actions that are used to perform all or part of a transaction. The deactivation sequence defined in section 6.1. and protect the sender and the recipient of the data against forgery by third parties. The property that data has not been altered or destroyed in an unauthorised manner.2 Book 3 Application Specification 3 Definitions Cryptographic Algorithm Data Integrity Deactivation Sequence Decipherment Digital Signature An algorithm that transforms data in order to hide or reveal its information content. The reversal of a corresponding encipherment. June 2008 Page 11 . An asymmetric cryptographic transformation of data that allows the recipient of the data to prove the origin and integrity of the data.EMV 4. The reversible transformation of data by a cryptographic algorithm to produce ciphertext.

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

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

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

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

it is computationally infeasible to compute either the originator‘s or the recipient‘s transformation. and displaying a message indicating that the ICC cannot be used to complete the transaction Stop the current application and deactivate the card.Default Terminal Action Code . Character-oriented asynchronous half duplex transmission protocol. Offline static data authentication A cryptographic technique that uses the same secret key for both the originator‘s and recipient‘s transformation.2 Book 3 Application Specification State H Voltage high on a signal line. Voltage low on a signal line. defined to give a logical grouping of data objects. The terminal incorporates the interface device and may also include other components and interfaces such as host communications. Without knowledge of the secret key.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. Terminate Transaction Page 16 June 2008 . which reflect the acquirer-selected action to be taken upon analysis of the TVR:    Terminal Action Code .Denial Terminal Action Code . Any of the following. May indicate a logic one or logic zero depending on the logic convention used with the ICC. May indicate a logic one or logic zero depending on the logic convention used with the ICC. The device used in conjunction with the ICC at the point of transaction to perform a financial transaction.1.5 of Book 1. Block-oriented asynchronous half duplex transmission protocol.3 Definitions EMV 4. Value field of a constructed data object.

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

2 Book 3 Application Specification Page 18 June 2008 .3 Definitions EMV 4.

Conventions.2 Book 3 Application Specification 4 Abbreviations.3) Alphanumeric Special (see section 4.3. Notations.3) Application Protocol Data Unit Application Program Interface Authorisation Response Code Authorisation Response Cryptogram Authorisation Request Cryptogram Application Selection Indicator Abstract Syntax Notation June 2008 Page 19 . Data Element Format Convention) Application Authentication Cryptogram Application Cryptogram Acknowledgment Application Definition File Application Elementary File Application File Locator Application Identifier Application Interchange Profile Alphanumeric (see section 4. and Terminology 4.EMV 4.1 µA µm µs a AAC AC ACK ADF AEF AFL AID AIP an ans APDU API ARC ARPC ARQC ASI ASN Abbreviations Microampere Micrometre Microsecond Alphabetic (see section 4.

1 Abbreviations EMV 4. and Terminology 4.4 Abbreviations. Notations.3) Central Processing Unit Certificate Revocation List Card Status Update Command TPDU Page 20 June 2008 .2 Book 3 Application Specification ATC ATM ATR AUC b BCD BER BIC BGT BWI BWT C CAD C-APDU CBC CCD CCI CDA CDOL CID CIN CLA CLK cn CPU CRL CSU C-TPDU Application Transaction Counter Automated Teller Machine Answer to Reset Application Usage Control Binary (see section 4. Conventions.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.

Seconds June 2008 Page 21 . Notations. and Terminology 4. Conventions. Minutes.2 Book 3 Application Specification 4 Abbreviations.1 Abbreviations CV CVM CVR CV Rule CWI CWT D DAD DC DDA DDF DDOL DES DF DIR DOL ECB EDC EF EN etu f FC FCI GND GP Hex HHMMSS Cryptogram Version Cardholder Verification Method Card Verification Results Cardholder Verification Rule Character Waiting Time Integer Character Waiting Time Bit Rate Adjustment Factor Destination Node Address Direct Current Dynamic Data Authentication Directory Definition File Dynamic Data Authentication Data Object List Data Encryption Standard Dedicated File Directory Data Object List Electronic Code Book Error Detection Code Elementary File European Norm Elementary Time Unit Frequency Format Code File Control Information Ground Grandparent key for session key generation Hexadecimal Hours.EMV 4.

1 Abbreviations EMV 4.4 Abbreviations. Lc Input/Output Issuer Action Code (Denial. Conventions. and Terminology 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 Page 22 June 2008 . Notations. Default.2 Book 3 Application Specification I/O IAC IAD IBAN I-block IC ICC ICC IEC IFD IFS IFSC IFSD IFSI IIN IK INF INS IOH IOL ISO IV KM KS L l.s.

Day Month. Notations.2 Book 3 Application Specification 4 Abbreviations.EMV 4. Year Newton Numeric (see section 4.3) Node Address Negative Acknowledgment Lr LRC M m M m.s. Conventions. and Terminology 4.1 Abbreviations LCOL LDD Le LEN Licc Lower Consecutive Offline Limit Length of the ICC Dynamic Data Maximum Length of Data Expected by the TAL in Response to a Case 2 or 4 Command Length Exact Length of Data Available or Remaining in the ICC (as Determined by the ICC) to be Returned in Response to the Case 2 or 4 Command Received by the ICC Length of Response Data Field Longitudinal Redundancy Check Mandatory Milliohm Megohm Most Significant Meters per Second Milliampere Message Authentication Code Maximum Master File Megahertz Minimum ICC Master Key for session key generation Millimetre Month. MK mm MMDD MMYY N n NAD NAK June 2008 Page 23 . MF MHz min. m/s mA MAC max.

4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations

EMV 4.2 Book 3 Application Specification

nAs 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

Nanoampere-second 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 3 Application Specification

4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations

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 TSI

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 Transaction Status Information

June 2008

Page 25

4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations

EMV 4.2 Book 3 Application Specification

TTL TVR UCOL UL V var. VCC VCC VIH VIL VOH VOL VPP VPP WI WTX WWT YYMM YYMMDD

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

EMV 4.2 Book 3 Application Specification

4 Abbreviations, Notations, Conventions, and Terminology 4.2 Notations

4.2
xx A := B A=B

Notations
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, that is, there exists an integer d such that (A – B) = dn

'0' to '9' and 'A' to 'F'

A  B mod n

A mod n

The reduction of the integer A modulo the integer n, that is, the unique integer r, 0  r < n, for which there exists an integer d such that A = dn + r

A/n

The integer division of A by n, that is, the unique integer d for which there exists an integer r, 0  r < n, such that A = dn + r

Y := ALG(K)[X] 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, using a secret key K Decipherment of a data block Y with a block cipher as specified in Annex A1 of Book 2, 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, using the public key PK The concatenation of an n-bit number A and an m-bit number B, which is defined as C = 2m A + B. 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.

X = Recover(PK)[Y]

C := (A || B) Leftmost

June 2008

Page 27

Notations. If C = (A || B) as above.4 Abbreviations. or digits and used interchangeably with the term ―least significant‖. 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. 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.2 Book 3 Application Specification Rightmost Applies to a sequence of bits. Conventions. If one data block is shorter than the other. bytes. H := Hash[MSG] XY Page 28 June 2008 .2 Notations EMV 4. and Terminology 4.

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

Variable data elements are variable length and may contain any bit combination. Conventions. Additional information on the formats of specific variable data elements is available elsewhere. Page 30 June 2008 .4 Abbreviations.3 Data Element Format Conventions EMV 4.2 Book 3 Application Specification var. Notations. and Terminology 4.

EMV 4. Conventions.2 Book 3 Application Specification 4 Abbreviations.4 Terminology Not defined in this specification and/or outside the scope of this specification Denotes a mandatory requirement Denotes a recommendation proprietary shall should June 2008 Page 31 . and Terminology 4. Notations.4 Terminology 4.

4 Abbreviations. Notations. Conventions. and Terminology 4.2 Book 3 Application Specification Page 32 June 2008 .4 Terminology EMV 4.

2 Book 3 Application Specification Part II Data Elements and Commands June 2008 Page 33 .EMV 4.

EMV 4.2 Book 3 Application Specification Page 34 June 2008 .

2 Book 3 Application Specification 5 Data Elements and Files An application in the Integrated Circuit Card (ICC) includes a set of items of information. a description of logical content. A data element is the smallest piece of information that may be identified by a name.EMV 4. Data elements not specified in Annex A are outside the scope of these specifications. An item of information is called a data element. a format.1 Data Elements Associated with Financial Transaction Interchange The data elements dictionary defined in Annex A includes those data elements that may be used for financial transaction interchange. and a coding. Any additional data element transmitted in the response to the SELECT command (for example. O/S Manufacturer proprietary data) is placed in the field ―FCI Issuer Discretionary Data‖ (tag 'BF0C'). 5. These items of information may be accessible to the terminal after a successful application selection (see section 12 of Book 1). June 2008 Page 35 .

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

2.3. 5. an AEF in the range 1-10 is referred to only by its SFI as described in section 5. The following sections describe structures and referencing methods.2.1 Application Elementary Files An Application Elementary File (AEF) in the range 1-10. Each DF name shall be unique within a given card.3 Files 5. June 2008 Page 37 . 5.2. A data file referred to in this specification consists of a sequence of records addressed by record number. contains one or more primitive Basic Encoding Rules . The layout of the data files accessible from the ICC is left to the discretion of the issuer except for the directory files described in the following section.3. 5.3.TLV (BER-TLV) data objects grouped into constructed BER-TLV data objects (records) according to Annex B.1 Referencing by Name Any Application Definition File (ADF) or Directory Definition File (DDF) in the card is referenced by its Dedicated File (DF) name. It can be either linear fixed or linear variable according to ISO/IEC 7816-4.2 File Referencing A file may be referred to by a name or a SFI depending on its type. A DF name for an ADF corresponds to the Application Identifier (AID) or contains the AID as the beginning of the DF name. This file structure is defined as linear. that is.3 Files The data objects contained in data files accessible from the ICC are stored in records. data that is not used by the card in its internal processes. The file structure and referencing method depend on the purpose of the file.2 Book 3 Application Specification 5 Data Elements and Files 5. The choice is left to the issuer and does not affect the reading of the file according to this specification.3.EMV 4. The data files referred to by SFIs in the range 1-10 contain only data not interpreted by the card. After selecting the application.

specifying the format of the data to be included in the constructed field. it is imperative that the ICC knows the format of this field when the data is received. the terminal is asked to build a flexible list of data elements to be passed to the card under the card‘s direction. DOLs currently used in this specification include:     the Processing Options Data Object List (PDOL) used with the GET PROCESSING OPTIONS command the Card Risk Management Data Object Lists (CDOL1 and CDOL2) used with the GENERATE APPLICATION CRYPTOGRAM (AC) command the Transaction Certificate Data Object List (TDOL) used to generate a TC Hash Value the Dynamic Data Authentication Data Object List (DDOL) used with the INTERNAL AUTHENTICATE command This section describes the rules for constructing a field using a DOL supplied by the card.2 Referencing by SFI SFIs are used for the selection of AEFs. Since the elements of the constructed field are not TLV encoded. The coding of SFIs within the range 1 to 10 is used to address AEFs governed by this specification.4 Rules for Using a Data Object List (DOL) In several instances.3.5 Data Elements and Files 5.2 Book 3 Application Specification 5. Any AEF within a given application is referenced by a SFI coded on 5 bits in the range 1 to 30. To minimise processing within the ICC. This is achieved by including a Data Object List (DOL) in the ICC. 5. Page 38 June 2008 .4 Rules for Using a Data Object List (DOL) EMV 4. Table 1 describes the assignment of SFIs for an EMV application: Value 1-10 11-20 21-30 Meaning Governed by this specification Payment system-specific Issuer-specific Table 1: Structure of SFI A SFI shall be unique within an application. The coding of the SFI is described in every command that uses it. such a list is not TLV encoded but is a single constructed field built by concatenating several data elements together.2.

the leftmost bytes of the data element shall be truncated if the data object has numeric (n 1) format.2 Book 3 Application Specification 5 Data Elements and Files 5. If a data object is in the list and is meaningful to the terminal but represents data that is not applicable to the current transaction. Concatenate all data elements listed in the DOL. The completed list of data elements shall be concatenated in the sequence in which the corresponding data objects appear in the DOL. Only tags representing primitive data objects constructed according to Annex B shall be used in DOLs. 1 See section 4.EMV 4. followed by a one-byte length which represents the number of bytes the field shall occupy in the command data. If the tag of any data object identified in the DOL is unknown to the terminal or represents a constructed data object. June 2008 Page 39 . the actual data shall be padded:    with leading hexadecimal zeroes if the data has numeric format with trailing hexadecimal ‗FF‘s if the data has compressed numeric (cn 1) format with trailing hexadecimal zeroes for any other format (an. c.4 Rules for Using a Data Object List (DOL) A DOL is a concatenated list of entries. the terminal shall provide a data element with the length specified and a value of all hexadecimal zeroes. The following rules apply to this concatenation: a.or two-byte tag identifying the desired data object. d. the portion of the command field representing the data object shall be filled with hexadecimal zeroes. If the length specified in the DOL entry is less than the length of the actual data object. Read the DOL from the ICC. the portion of the command field representing the data object shall be filled with hexadecimal zeroes. If a data object is in the list and is meaningful to the terminal but represents optional static data that is absent from the terminal. The terminal shall complete the following steps to build the constructed field: 1. The format of each entry is a one. b. or the rightmost bytes of the data shall be truncated for any other format. If the length specified in the DOL entry is greater than the length of the actual data.3 Data Element Format Convention. 2. with each entry representing a single data element to be included in the constructed field. ans or b including bit combination data 1) e.

5 Data Elements and Files 5.2 Book 3 Application Specification Page 40 June 2008 .4 Rules for Using a Data Object List (DOL) EMV 4.

EMV 4.1 Command APDU Format The command Application Protocol Data Unit (APDU) consists of a mandatory header of four bytes followed by a conditional body of variable length. Le shall always be set to '00'. The maximum number of data bytes expected in the response APDU is denoted by length of expected data (Le). When required in a command message. as shown in Figure 1: CLA INS P1 P2  Lc Data Conditional Body Le   Mandatory Header 2  Figure 1: Command APDU Structure The number of data bytes sent in the command APDU (C-APDU) is denoted by Lc (length of command data field). When Le is present and contains the value zero. the maximum number of available data bytes (up to 256) is expected. 2 CLA = Class Byte of the Command Message INS = Instruction Byte of Command Message P1 = Parameter 1 P2 = Parameter 2 June 2008 Page 41 .2 Book 3 Application Specification 6 Commands for Financial Transaction 6.

6 Commands for Financial Transaction 6.3 Coding Conventions This section defines the coding of the header and the body of the messages (command and response). The least significant nibble of the class byte indicates secure messaging and logical channel mechanisms. 6. in other words.3. 6. and the coding of the messages is defined within the context of these specifications. according to ISO/IEC 7816-4.2 Book 3 Application Specification 6.1 Coding of the Class Byte The most significant nibble of the class byte indicates the type of command as shown in Table 2: Hex '0' '8' Any other value Meaning Inter-industry command Proprietary to this specification Outside the scope of this specification Table 2: Most Significant Nibble of the Class Byte A command proprietary to this specification is introduced by the most significant nibble of the class byte set to 8. Page 42 June 2008 .2 Response APDU Format The response APDU format consists of a conditional body of variable length followed by a mandatory trailer of two bytes.2 Response APDU Format EMV 4. the structure of the command and response messages is according to ISO/IEC 7816-4. The detailed coding of the objects is provided with the commands described in subsequent sub-clauses. as shown in Figure 2: Data  Body  SW1 SW2  Trailer  Figure 2: Response APDU Structure The data field of a response APDU is an object structured as defined in Annex B.

3 Coding Conventions 6. a parameter byte has the value '00'. June 2008 Page 43 .2 Coding of the Instruction Byte The INS byte of a command is structured according to Book 1 section 9. Table 3 indicates the coding of INS and its relationship to CLA: CLA '8x' '8x' '8x' '0x' '8x' '0x' '8x' '8x' '0x' '8x' '0x' '0x' '0x' '8x' '8x' '9x' 'Ex' INS '1E' '18' '16' '82' 'AE' '84' 'CA' 'A8' '88' '24' 'B2' 'A4' '20' 'Dx' 'Ex' 'xx' 'xx' Meaning APPLICATION BLOCK APPLICATION UNBLOCK CARD BLOCK EXTERNAL AUTHENTICATE GENERATE APPLICATION CRYPTOGRAM GET CHALLENGE GET DATA GET PROCESSING OPTIONS INTERNAL AUTHENTICATE PERSONAL IDENTIFICATION NUMBER (PIN) CHANGE/UNBLOCK READ RECORD SELECT VERIFY RFU for the payment systems RFU for the payment systems RFU for manufacturers for proprietary INS coding RFU for issuers for proprietary INS coding Table 3: Coding of the Instruction Byte Note: Additional INS codes may be assigned in the future by EMVCo using class '8x'.2 Book 3 Application Specification 6 Commands for Financial Transaction 6.3.3. It is strongly recommended that application providers not define proprietary commands in class '8x' when they are to be used in the context of these specifications.3 Coding of Parameter Bytes The parameter bytes P1 P2 may have any value. If not used. so that collision is avoided.EMV 4.1.4. 6.

The coding of the status words is structured as illustrated in Figure 3: SW1 SW2 Process Completed Process Aborted Normal Warning Execution Checking '61xx' '9000' '62xx' '63xx' '64xx' '65xx' '67xx' to '6Fxx' Figure 3: Structural Scheme of Status Bytes Page 44 June 2008 . When present.6 Commands for Financial Transaction 6.2 Book 3 Application Specification 6.3. a command APDU message data field consists of a string of data elements. a response APDU message data field consists of a data object or a string of data objects encapsulated in a template according to Annex B. 6.3 Coding Conventions EMV 4.3.4 Coding of Data Field Bytes When present.5 Coding of the Status Bytes The status bytes SW1 SW2 are returned by the transport layer to the application layer in any response message and denote the processing state of the command.

SW2 indicates the exact length. Part II.2 Book 3 Application Specification 6 Commands for Financial Transaction 6. conditions of use not satisfied Wrong parameter(s) P1 P2. record not found Referenced data (data objects) not found Table 4: Coding of Status Bytes SW1 SW2 '69' '69' '69' '6A' '6A' '6A' '6A' '83' '84' '85' '81' '82' '83' '88' The following values of SW1 SW2 are described in Part II of Book 1 as they apply to the Transport Protocol Data Unit (TPDU) and are not returned to the APDU:   '61xx': SW2 indicates the number of response bytes still available.EMV 4. authentication failed State of non-volatile memory changed. '6Cxx': Wrong length Le. selected file invalidated State of non-volatile memory changed.3 Coding Conventions SW1 '90' '62' '63' '63' SW2 '00' '83' '00' 'Cx' Meaning Normal processing Process completed (any other value for SW2 is RFU) Warning processing State of non-volatile memory unchanged. SW1 = '6x' or '90' denotes a normal. Other values of SW1 returned by the ICC are not supported by Book 1. function not supported Wrong parameter(s) P1 P2. June 2008 Page 45 . file not found Wrong parameter(s) P1 P2. warning. authentication method blocked Command not allowed. or error condition coded according to ISO/IEC 7816-4. referenced data invalidated Command not allowed. counter provided by 'x' (from 0-15) Checking errors Command not allowed.

2 Book 3 Application Specification Table 5 shows the coding of the SW1 SW2 status bytes which this specification requires to be returned in response to specific conditions. GENERATE APPLICATION CRYPTOGRAM GET PROCESSING OPTIONS EXTERNAL AUTHENTICATE INTERNAL AUTHENTICATE APPLICATION UNBLOCK PIN CHANGE/UNBLOCK APPLICATION BLOCK GET CHALLENGE READ RECORD CARD BLOCK GET DATA SELECT X X X SW1 '62' '63' '63' '69' '69' '69' '6A' '6A' '6A' '6A' SW2 '83' '00' 'Cx' '83' '84' '85' '81' '82' '83' '88' X Table 5: Allocation of Status Bytes X X X X X X X X X The following convention is used in the table: X = Allowed response code.6 Commands for Financial Transaction 6.3 Coding Conventions EMV 4. Page 46 June 2008 VERIFY . The meaning of the action is explained in section 10. for which a dedicated action shall be taken or which has a special meaning for an EMV compliant application. The card may generate status bytes not listed in this table for error and warning conditions not specified in Part III.

the terminal shall continue with the next command from the Issuer Script (if any).1 of Book 4 (for cardholder verification processing).3. If during the processing of an issuer script command. 6. A card may support more than one logical channel but only the basic logical channel is supported by this specification. If during transaction processing as described in Part III.4 Logical Channels A logical channel establishes and maintains the link between an application in the terminal and an application in the card. SW1 SW2 = '6300' means ‗Authentication Failed‘.10. then the transaction would be terminated. This limits to one the number of concurrent applications according to this specification. the card returns a value for SW1 SW2 other than those specified in Table 5. If during the processing of the GET DATA command. in response to the READ RECORD command for record 5.4 Logical Channels When using transmission protocol T=1. both response codes are referenced throughout the text as '90 00' only. the card returns an error condition. However. For the EXTERNAL AUTHENTICATE command. the card returns SW1 SW2 = '6400' instead of SW1 SW2 = '6A83'.3. defined in section 6. if the application reads records in a file that contains four records and. the terminal shall proceed as indicated in section 10.5. and no other action is indicated elsewhere in these specifications.4. for all commands having Le = '00'. To allow for migration and support of new functionality.6 Coding of RFU Data The coding of data (bits and bytes) indicated as RFU and marked as 'x' in the tables of the specifications shall be set to zero unless otherwise stated.6.EMV 4. For example.2 Book 3 Application Specification 6 Commands for Financial Transaction 6. 6.7.3 (for terminal velocity checking) or in section 6. as defined in section 10. for readability. the transaction shall be terminated. the successful execution of the command is indicated by SW1 SW2 = '90 00' or '61 La'. June 2008 Page 47 . the ICC and the terminal shall not verify the data indicated as RFU. the card returns a warning condition (SW1 SW2 = '62XX' or '63xx').

6 Commands for Financial Transaction 6.5             Commands This section describes the following APDU command-response pairs: APPLICATION BLOCK (post-issuance command) APPLICATION UNBLOCK (post-issuance command) CARD BLOCK (post-issuance command) EXTERNAL AUTHENTICATE GENERATE APPLICATION CRYPTOGRAM GET CHALLENGE GET DATA GET PROCESSING OPTIONS INTERNAL AUTHENTICATE PIN CHANGE/UNBLOCK (post-issuance command) READ RECORD VERIFY The post-issuance commands shall only be sent using script processing (see section 10.2 Book 3 Application Specification 6. Page 48 June 2008 .10) and secure messaging as specified in Book 2.5 Commands EMV 4.

1. June 2008 Page 49 .2 Book 3 Application Specification 6 Commands for Financial Transaction 6. 6.EMV 4.1.1.1 APPLICATION BLOCK Command-Response APDUs Definition and Scope The APPLICATION BLOCK command is a post-issuance command that invalidates the currently selected application.4 Data Field Returned in the Response Message No data field is returned in the response message.5.5 Commands 6. 6.5.5. coding according to the secure messaging specified in Book 2 '1E' '00'.2 Command Message The APPLICATION BLOCK command message is coded as shown in Table 6: Code CLA INS P1 P2 Lc Data Value '8C' or '84'.1 6. Following the successful completion of an APPLICATION BLOCK command:   An invalidated application shall return the status bytes SW1 SW2 = '6283' (‗Selected file invalidated‘) in response to a SELECT command. An invalidated application shall return only an Application Authentication Cryptogram (AAC) as AC in response to a GENERATE AC command. all other values are RFU Number of data bytes Message Authentication Code (MAC) data component.5. all other values are RFU '00'.1. coding according to the secure messaging specified in Book 2 Not present Table 6: APPLICATION BLOCK Command Message Le 6.5.3 Data Field Sent in the Command Message The data field of the command message contains the MAC data component coded according to the secure messaging format specified in Book 2.

2 Book 3 Application Specification 6.5.5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command.1. whether the application was already invalidated or not.6 Commands for Financial Transaction 6. Page 50 June 2008 .5 Commands EMV 4.

2.2 Book 3 Application Specification 6 Commands for Financial Transaction 6.EMV 4.5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command. 6.1 The APPLICATION UNBLOCK command is a post-issuance command that rehabilitates the currently selected application.3 Data Field Sent in the Command Message The data field of the command message contains the MAC data component coded according to the secure messaging format specified in Book 2.5. June 2008 Page 51 . all other values are RFU '00'.2 Command Message The APPLICATION UNBLOCK command message is coded as shown in Table 7.5. 6. the restrictions imposed by the APPLICATION BLOCK command are removed. coding according to the secure messaging specified in Book 2 '18' '00'.5.4 Data Field Returned in the Response Message No data field is returned in the response message. coding according to the secure messaging specified in Book 2 Not present Table 7: APPLICATION UNBLOCK Command Message 6.5. whether the application was previously invalidated or not.2 APPLICATION UNBLOCK Command-Response APDUs Definition and Scope 6.2.2. all other values are RFU Number of data bytes MAC data component.5 Commands 6. 6.5.2.2. Following the successful completion of an APPLICATION UNBLOCK command. Code CLA INS P1 P2 Lc Data Le Value '8C' or '84'.5.

The CARD BLOCK command shall disable all applications in the ICC.5 Commands EMV 4. 6.3.5.3 Data Field Sent in the Command Message The data field of the command message contains the MAC data component coded according to the secure messaging format specified in Book 2.2 Book 3 Application Specification 6.3 6.1 CARD BLOCK Command-Response APDUs Definition and Scope The CARD BLOCK command is a post-issuance command that permanently disables all applications in the ICC. all subsequent SELECT commands shall return the status bytes SW1 SW2 = '6A81' (‗Function not supported‘) and perform no other action. Following the successful completion of a CARD BLOCK command.5.5. all other values are RFU Number of data bytes MAC data component.5.3. coding according to the secure messaging specified in Book 2 Not present Table 8: CARD BLOCK Command Message 6. Page 52 June 2008 .2 Command Message The CARD BLOCK command message is coded as shown in Table 8.5. Code CLA INS P1 P2 Lc Data Le Value '8C' or '84'. including applications that may be selected implicitly.6 Commands for Financial Transaction 6. coding according to the secure messaging specified in Book 2 '16' '00'.3.4 Data Field Returned in the Response Message No data field is returned in the response message. all other values are RFU '00'. 6.3.

5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command.5.3.2 Book 3 Application Specification 6 Commands for Financial Transaction 6. June 2008 Page 53 .EMV 4.5 Commands 6. whether the card was already blocked or not.

2 Command Message The EXTERNAL AUTHENTICATE command message is coded as shown in Table 9: Code CLA INS P1 P2 Lc Data Le '00' '82' '00' '00' 8-16 Issuer Authentication Data Not present Value Table 9: EXTERNAL AUTHENTICATE Command Message The reference of the algorithm (P1) of the EXTERNAL AUTHENTICATE command is coded '00'.4 Data Field Returned in the Response Message No data field is returned in the response message. The reference of the algorithm either is known before issuing the command or is provided in the data field.5. 6. which means that no information is given.6 Commands for Financial Transaction 6.5.3 Data Field Sent in the Command Message The data field of the command message contains the value field of tag '91' coded as follows:   mandatory first 8 bytes containing the cryptogram optional additional 1-8 bytes are proprietary 6.2 Book 3 Application Specification 6.4. Page 54 June 2008 .5 Commands EMV 4.5.1 The EXTERNAL AUTHENTICATE command asks the application in the ICC to verify a cryptogram.4 EXTERNAL AUTHENTICATE Command-Response APDUs Definition and Scope 6.4.5. The ICC returns the processing state of the command.4. 6.5.4.

5.4. June 2008 Page 55 .5 Commands 6.2 Book 3 Application Specification 6 Commands for Financial Transaction 6. For further information.EMV 4. see Annex F. '6300' indicates ‗Issuer authentication failed‘.5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command.

Page 56 June 2008 . which computes and returns a cryptogram.1 The GENERATE AC command sends transaction-related data to the ICC.5 Commands EMV 4.5. This command is also used when performing the Combined DDA/Application Cryptogram Generation (CDA) function as described in Book 2 section 6. In both cases.5 GENERATE APPLICATION CRYPTOGRAM Command-Response APDUs Definition and Scope 6.6. the cryptogram shall be of a type specified in Table 10 (for more details. see section 9).5.6 Commands for Financial Transaction 6. This cryptogram shall either be an Application Cryptogram (AC) as specified in this specification or a proprietary cryptogram. Type Application Authentication Cryptogram Authorisation Request Cryptogram Transaction Certificate Abbreviation AAC ARQC TC Meaning Transaction declined Online authorisation requested Transaction approved Table 10: GENERATE AC Cryptogram Types The cryptogram returned by the ICC may differ from that requested in the command message according to an internal process in the ICC (as described in section 9).5.2 Book 3 Application Specification 6.

5.5.EMV 4.3 Data Field Sent in the Command Message The content of the data field of the command message is coded according to the rules for the data object list as defined in section 5.2 Book 3 Application Specification 6 Commands for Financial Transaction 6. Transaction-related data '00' Value Table 11: GENERATE AC Command Message The reference control parameter of the GENERATE AC command is coded as shown in Table 12: b8 0 0 1 1 b7 0 1 0 1 x 0 1 x x x x b6 b5 b4 b3 b2 b1 AAC TC ARQC RFU RFU CDA signature not requested CDA signature requested RFU Meaning Table 12: GENERATE AC Reference Control Parameter 6.4.5. June 2008 Page 57 .5.5 Commands 6.2 Command Message The GENERATE AC command message is coded as shown in Table 11: Code CLA INS P1 P2 Lc Data Le '80' 'AE' Reference control parameter (see Table 12) '00' Var.

6 of Book 2. but shall always include the Cryptogram Information Data.5.4 Data Field Returned in the Response Message The data field of the response message consists of a BER-TLV coded data object.5.  Format 1: The data object returned in the response message is a primitive data object with tag equal to '80'. The value field may contain several BERTLV coded objects. and the cryptogram computed by the ICC (either an AC or a proprietary cryptogram). the Application Transaction Counter. The coding of the data object shall be according to one of the following two formats. The value field consists of the concatenation without delimiters (tag and length) of the value fields of the data objects specified in Table 13: Value Cryptogram Information Data (CID) Application Transaction Counter (ATC) Application Cryptogram (AC) Issuer Application Data (IAD) Presence M M M O Table 13: Format 1 GENERATE AC Response Message Data Field  Format 2: The data object returned in the response message is a constructed data object with tag equal to '77'. Format 2 shall be used if the response is being returned in a signature as specified for the CDA function described in section 6.5 Commands EMV 4. The required data elements for the response are shown in the appropriate tables in that section. The utilisation and interpretation of proprietary data objects which may be included in this response message are outside the scope of these specifications.6 Commands for Financial Transaction 6. Page 58 June 2008 .2 Book 3 Application Specification 6.

5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command. if any mandatory data element is missing. the Cryptogram Information Data returned by the GENERATE AC response message is coded as shown in Table 14: b8 0 0 1 1 b7 0 1 0 1 x x 0 1 x 0 0 0 0 1 x 0 0 1 1 x x 0 1 0 1 x b6 b5 b4 b3 b2 b1 AAC TC ARQC RFU Payment System-specific cryptogram No advice required Advice required Reason/advice code No information given Service not allowed PIN Try Limit exceeded Issuer authentication failed Other values RFU Meaning Table 14: Coding of Cryptogram Information Data For the Format 2 response template. 6.EMV 4. the terminal shall terminate the transaction.5.5 Commands For both formats.2 Book 3 Application Specification 6 Commands for Financial Transaction 6.5. June 2008 Page 59 .

6.4 Data Field Returned in the Response Message The data field of the response message contains an 8-byte unpredictable number generated by the ICC.6 Commands for Financial Transaction 6.5.5.1 GET CHALLENGE Command-Response APDUs Definition and Scope The GET CHALLENGE command is used to obtain an unpredictable number from the ICC for use in a security-related procedure.6.6. The challenge shall be valid only for the next issued command.5.5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command.5 Commands EMV 4.3 Data Field Sent in the Command Message The data field of the command message is not present. Page 60 June 2008 .6.2 Command Message The GET CHALLENGE command message is coded as shown in Table 15: Code CLA INS P1 P2 Lc Data Le '00' '84' '00' '00' Not present Not present '00' Value Table 15: GET CHALLENGE Command Message 6.6 6.2 Book 3 Application Specification 6.5. 6. 6.5.5. 6.6.

5.7. including its tag and its length). 6. The usage of the GET DATA command in this specification is limited to the retrieval of the following primitive data objects that are defined in Annex A and interpreted by the application in the ICC:     ATC (tag '9F36') Last Online ATC Register (tag '9F13') PIN Try Counter (tag '9F17') Log Format (tag '9F4F') 6. June 2008 Page 61 .7.1 GET DATA Command-Response APDUs Definition and Scope The GET DATA command is used to retrieve a primitive data object not encapsulated in a record within the current application. '9F17'. '9F13'.EMV 4.5.5. or '9F4F' Not present Not present '00' Value Table 16: GET DATA Command Message 6.2 Book 3 Application Specification 6 Commands for Financial Transaction 6.7 6.5.3 Data Field Sent in the Command Message The data field of the command message is not present.7.7.2 Command Message The GET DATA command message is coded as shown in Table 16: Code CLA INS P1 P2 Lc Data Le '80' 'CA' '9F36'.5.4 Data Field Returned in the Response Message The data field of the response message contains the primitive data object referred to in P1 P2 of the command message (in other words.5 Commands 6.

5 Commands EMV 4.2 Book 3 Application Specification 6.5. Page 62 June 2008 .6 Commands for Financial Transaction 6.5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command.7.

8 GET PROCESSING OPTIONS Command-Response APDUs Definition and Scope 6.EMV 4.8. Otherwise.2 Command Message The GET PROCESSING OPTIONS command message is coded as shown in Table 17: Code CLA INS P1 P2 Lc Data Le '80' 'A8' '00'. the length field of the template is the total length of the value fields of the data objects transmitted to the ICC. all other values are RFU var.5 Commands 6.5. the terminal sets the length field of the template to zero. The ICC returns the Application Interchange Profile (AIP) and the Application File Locator (AFL). 6.8.2 Book 3 Application Specification 6 Commands for Financial Transaction 6. all other values are RFU '00'. When the data object list is not provided by the ICC.1 The GET PROCESSING OPTIONS command initiates the transaction within the ICC.8.3 Data Field Sent in the Command Message The data field of the command message is a data object coded according to the PDOL provided by the ICC.4. June 2008 Page 63 .5.5. and is introduced by the tag '83'. as defined in section 5.5. Processing Options Data Object List (PDOL) related data '00' Value Table 17: GET PROCESSING OPTIONS Command Message 6.

 Format 1: The data object returned in the response message is a primitive data object with tag equal to '80'. The AFL consists of the list.4 Data Field Returned in the Response Message The data field of the response message consists of a BER-TLV coded data object.8.2.5. For the Format 2 response template.5 Commands EMV 4.2 Book 3 Application Specification 6.5. The utilisation and interpretation of proprietary data objects which may be included in this response message are outside the scope of these specifications. The value field may contain several BERTLV coded objects. if any mandatory data element is missing. The coding of the data object returned in the response message is shown in Figure 4: '80' Length Application Interchange Profile Application File Locator Figure 4: Format 1 GET PROCESSING OPTIONS Response Message Data Field  Format 2: The data object returned in the response message is a constructed data object with tag equal to '77'. Page 64 June 2008 . without delimiters. the terminal shall terminate the transaction. 6. of files and related records for the currently selected application that shall be read according to section 10. The AIP specifies the application functions that are supported by the application in the ICC and is coded according to Part III. but shall always include the AIP and the AFL.6 Commands for Financial Transaction 6. The coding of the data object shall be according to one of the following two formats. The value field consists of the concatenation without delimiters (tag and length) of the value fields of the AIP and the AFL.8.5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command.

9.5.5. 6.3 Data Field Sent in the Command Message The data field of the command message contains the authentication-related data proprietary to an application.5 Commands 6. It is coded according to the DDOL as defined in Book 2.1 The INTERNAL AUTHENTICATE command initiates the computation of the Signed Dynamic Application Data by the card using:    the challenge data sent from the terminal and ICC data and a relevant private key stored in the card.2 Book 3 Application Specification 6 Commands for Financial Transaction 6.9. June 2008 Page 65 .5.9 INTERNAL AUTHENTICATE Command-Response APDUs Definition and Scope 6.9. which means that no information is given.2 Command Message The INTERNAL AUTHENTICATE command message is coded as shown in Table 18: Code CLA INS P1 P2 Lc Data Le '00' '88' '00' '00' Length of authentication-related data Authentication-related data '00' Value Table 18: INTERNAL AUTHENTICATE Command Message The reference of the algorithm (P1) of the INTERNAL AUTHENTICATE command is coded '00'. The ICC returns the Signed Dynamic Application Data to the terminal.5. The reference of the algorithm either is known before issuing the command or is provided in the data field. 6.EMV 4.

5 Commands EMV 4. The value field consists of the value field of the Signed Dynamic Application Data as specified in Book 2. the length of the Signed Dynamic Application Data plus the length of the TLV encoded optional data (if present) shall remain within the limits as specified in Book 2 Annex D. 6. but shall always include the Signed Dynamic Application Data as specified in Book 2. The utilisation and interpretation of proprietary data objects which may be included in this response message are outside the scope of these specifications.2 Book 3 Application Specification 6. the terminal shall terminate the transaction. Format 2: The data object returned in the response message is a constructed data object with tag equal to '77'. The coding of the data object shall be according to one of the following two formats.  For the Format 2 response template.9. Note: To ensure that the INTERNAL AUTHENTICATE response data length is within the 256 byte limit. The value field may contain several BERTLV coded objects. if any mandatory data element is missing.5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command.6 Commands for Financial Transaction 6.5.  Format 1: The data object returned in the response message is a primitive data object with tag equal to '80'.4 Data Field Returned in the Response Message The data field of the response message consists of a BER-TLV coded data object.9.5. Page 66 June 2008 .

June 2008 Page 67 .EMV 4.10 6. If PIN data is transmitted in the command it shall be enciphered for confidentiality. the card shall perform the following functions:   The value of the PIN Try Counter shall be reset to the value of the PIN Try Limit.5.1 PIN CHANGE/UNBLOCK Command-Response APDUs Definition and Scope The PIN CHANGE/UNBLOCK command is a post-issuance command.10.2 Book 3 Application Specification 6 Commands for Financial Transaction 6.5. the value of the reference PIN shall be set to the new PIN value.5 Commands 6. Its purpose is to provide the issuer the capability either to unblock the PIN or to simultaneously change and unblock the reference PIN. Upon successful completion of the PIN CHANGE/UNBLOCK command. is the one that is associated with the application and which the card uses to check the Transaction PIN Data transmitted within the VERIFY command. Note: The reference PIN. If requested. which is stored within the card.

and MAC data component. since the PIN CHANGE/UNBLOCK command does not contain a new PIN value. coding according to the secure messaging specified in Book 2 Not present Le Table 19: PIN CHANGE/UNBLOCK Command Message P2: If P2 is equal to '00'. the reference PIN is unblocked and the PIN Try Counter is reset to the PIN Try Limit. if present.3 Data Field Sent in the Command Message The data field of the command message contains the PIN data component.5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command.10. 6.2 Book 3 Application Specification 6.5. '01'. Page 68 June 2008 . 6.5.5. or '02' Number of data bytes Enciphered PIN data component. There is no PIN update. Any other value of P2 allowing PIN unblocking and/or PIN changing is out of the scope of this specification and shall be described for each payment system individually. if present. The usage of P2 equal to '01' or '02' is reserved for payment systems.5. followed by the MAC data component coded according to the secure messaging format specified in Book 2.2 Command Message The PIN CHANGE/UNBLOCK command message is coded as shown in Table 19. coding according to the secure messaging specified in Book 2 '24' '00' '00'.10.6 Commands for Financial Transaction 6.10.4 Data Field Returned in the Response Message No data field is returned in the response message.5 Commands EMV 4. Code CLA INS P1 P2 Lc Data Value '8C' or '84'.10. 6.

5 Commands 6.2 Command Message The READ RECORD command message is coded as shown in Table 20: Code CLA INS P1 P2 Lc Data Le '00' 'B2' Record number Reference control parameter (see Table 21) Not present Not present '00' Table 20: READ RECORD Command Message Table 21 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 21: READ RECORD Command Reference Control Parameter 6.11. The response from the ICC consists of returning the record. June 2008 Page 69 .5.11.11.3 Data Field Sent in the Command Message The data field of the command message is not present.11 6.EMV 4.5.5.5.1 READ RECORD Command-Response APDUs Definition and Scope The READ RECORD command reads a file record in a linear file.2 Book 3 Application Specification 6 Commands for Financial Transaction 6. 6.

5.6 Commands for Financial Transaction 6. the record is a BER-TLV constructed data object as defined in Annex B and coded as shown in Figure 5: '70' Length Record Template Figure 5: READ RECORD Response Message Data Field The response message to READ RECORD for SFIs in the range 11-30 is outside the scope of this specification. except as specified in section 10.11.5 Commands EMV 4.3 and in Annex D.5.2 Book 3 Application Specification 6.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.5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command.11. For SFIs in the range 1-10. Page 70 June 2008 . 6.

2 Command Message The VERIFY command message is coded as shown in Table 22: Code CLA INS P1 P2 Lc Data Le '00' '20' '00' Qualifier of the reference data (see Table 23) Var. The VERIFY command applies when the Cardholder Verification Method (CVM) chosen from the CVM List is an offline PIN.5.2 Book 3 Application Specification 6 Commands for Financial Transaction 6.12 6. 6.12.5.EMV 4.5.1 VERIFY Command-Response APDUs Definition and Scope The VERIFY command initiates in the ICC the comparison of the Transaction PIN Data sent in the data field of the command with the reference PIN data associated with the application. Transaction PIN Data Not present Table 22: VERIFY Command Message Value June 2008 Page 71 . as described in section 10.12. The manner in which the comparison is performed is proprietary to the application in the ICC.5.5 Commands 6.

5 Commands EMV 4. 3 The value of P2 = ‗00‘ is not used by this specification. format as defined in Book 2 RFU for this specification RFU for the individual payment systems RFU for the issuer Table 23: VERIFY Command qualifier of reference data (P2) The processing of the VERIFY command in the ICC will be defined in combination with the CVM rules as specified in section 10.2 Book 3 Application Specification Table 23 defines the qualifier of the reference data (P2): b8 0 1 1 1 1 1 1 b7 0 0 0 0 0 0 0 b6 0 0 0 0 0 0 0 b5 0 0 0 0 0 0 1 b4 0 0 0 1 1 1 x b3 0 0 x 0 0 1 x b2 0 0 x 0 x x x b1 0 0 x 0 x x x Meaning As defined in ISO/IEC 7816-4 3 Plaintext PIN. Page 72 June 2008 . format as defined below RFU for this specification Enciphered PIN.6 Commands for Financial Transaction 6.5.

12. When for the currently selected application the comparison between the Transaction PIN Data and the reference PIN data performed by the VERIFY command fails. Any subsequent VERIFY command applied in the context of that application shall then fail with SW1 SW2 = '6983'. no more retries are left. and the CVM shall be blocked.5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command.5.EMV 4.3 Data Field Sent in the Command Message The data field of the command message contains the value field of tag '99'. 6. 6. The processing of the VERIFY command in the ICC should know how to find the PIN data unambiguously. June 2008 Page 73 . where 'x' represents the number of retries still possible.5. the ICC shall return SW2 = 'Cx'.12.5. When the card returns 'C0'.12.5 Commands The plaintext offline PIN block shall be formatted as follows: C N P P P P P/F P/F P/F P/F P/F P/F P/F P/F F F where: Name C N P P/F F Control field PIN length PIN digit PIN/filler Filler Value 4 bit binary number with value of 0010 (Hex '2') 4 bit binary number with permissible values of 0100 to 1100 (Hex '4' to 'C') 4 bit binary number with permissible values of 0000 to 1001 (Hex '0' to '9') Determined by PIN length 4 bit binary number with a value of 1111 (Hex 'F') Table 24: Plaintext Offline PIN Block Format P2 = '00' indicates that no particular qualifier is used.4 Data Field Returned in the Response Message No data field is returned in the response message.2 Book 3 Application Specification 6 Commands for Financial Transaction 6. 6.

6 Commands for Financial Transaction 6.5 Commands EMV 4.2 Book 3 Application Specification Page 74 June 2008 .

2 Book 3 Application Specification Part III Debit and Credit Application Specification June 2008 Page 75 .EMV 4.

2 Book 3 Application Specification Page 76 June 2008 .EMV 4.

The definition of each of the data objects is defined in Annex A. These files:    Shall be linear files readable using the READ RECORD command as described in this specification.     Files with SFIs in the range 11 to 20 are reserved for proprietary data to be specified by the individual payment systems. Files with SFIs in the range 21 to 30 are reserved for proprietary data to be specified by the issuer.1 Mapping Data Objects The payment system or issuer will map the appropriate data objects to files according to their needs. and the length field shall contain the total length of the encapsulated data objects. The tag of the constructed data object shall be '70' indicating a template proprietary to this specification. Shall contain only data objects defined in this specification and coded in accordance with the BER-TLV described in Annex B.2 Book 3 Application Specification 7 Files for Financial Transaction Interchange The description of the file structure and commands for accessing the files is found in Part III of Book 1 (for application selection) and Part II of this book (for the application elementary files). June 2008 Page 77 . Each record is limited to 254 bytes. including tag and length. Each record shall be coded as a constructed data object. 7. May contain multiple records. but must be readable unconditionally. subject to the following restrictions:  All files accessible using the READ RECORD command as defined in this specification containing data objects defined in this specification shall use SFIs in the range 1 to 10. May have access conditions to be satisfied for updates.EMV 4.

should be located in the first record referenced by the AFL. when present.2 Book 3 Application Specification  The AFL determines the files and records to be used for processing a transaction.2 Mandatory Data Objects EMV 4.7 Files for Financial Transaction Interchange 7. 4 The exception may be that the Issuer Public Key Remainder or the ICC Public Key Remainder could be absent. All other data objects defined in this specification to be resident in such files in the card are optional.5 Offline data authentication is required to support offline transactions but is optional in cards that support only online transactions. 7.4 Tag '8F' '90' Value Certification Authority Public Key Index Issuer Public Key Certificate Table 25: Data Objects Used by the Offline Data Authentication Algorithm Additional information may be found in complementary payment system documentation. Presence M M M M This allows the terminal to optionally perform the hashing necessary for data authentication in parallel with reading and parsing of data for other purposes.2 Mandatory Data Objects Table 26 lists the data objects that must be present in the ICC in files read using the READ RECORD command. This is because if the public key modulus can be recovered in its entirety from the public key certificate there is no need for a remainder. 5 Page 78 June 2008 . Table 28 lists the data objects that must be present if the ICC supports offline dynamic data authentication (DDA and/or CDA).2. Tag '5F24' '5A' '8C' '8D' Value Application Expiration Date Application Primary Account Number (PAN) Card Risk Management Data Object List 1 Card Risk Management Data Object List 2 Table 26: Mandatory Data Objects Table 27 lists the data objects that must be present if the ICC supports offline static data authentication (SDA). The use of the AFL is described in section 10. The data objects listed in Table 25 are used by the offline data authentication algorithm and.

the Default DDOL shall be used instead. June 2008 Page 79 .EMV 4.2 Mandatory Data Objects Tag '8F' '90' '93' '92' '9F32' Value Certification Authority Public Key Index Issuer Public Key Certificate Signed Static Application Data Issuer Public Key Remainder Issuer Public Key Exponent Table 27: Data Required for SDA Tag '8F' '90' '92' '9F32' '9F46' '9F47' '9F48' '9F49' Value Certification Authority Public Key Index Issuer Public Key Certificate Issuer Public Key Remainder Issuer Public Key Exponent ICC Public Key Certificate ICC Public Key Exponent ICC Public Key Remainder Dynamic Data Authentication Data Object List (DDOL) 6 Table 28: Data Required for DDA and/or CDA 6 In case the DDOL is not present in the card.2 Book 3 Application Specification 7 Files for Financial Transaction Interchange 7.

4 Data Retrievable by GET PROCESSING OPTIONS Data objects listed in Table 30 are not retrievable by the READ RECORD command but are retrieved by the terminal using the GET PROCESSING OPTIONS command as described in section 6.3 Data Retrievable by GET DATA Command EMV 4. If the issuer does not wish terminal velocity checking to be performed and omits these data objects.8. unless the card supports retrieval of the PIN Try Counter or the Log Format using GET DATA. and it can be retrieved by either the GET DATA command or in the response to a GENERATE AC command. Tag '9F36' '9F17' '9F13' '9F4F' PIN Try Counter Last Online ATC Register Log Format Value Application Transaction Counter (ATC) Presence M O O O Table 29: Data Objects Retrievable by GET DATA Command 7.4 describes the format of the data when returned by the GET PROCESSING OPTIONS command. not the format of the response. the ICC does not need to support the GET DATA command. Of the objects listed here.5.8. section 6. The terminal retrieves the ATC via the GET DATA command only if the ICC contains the Lower Consecutive Offline Limit (LCOL) and Upper Consecutive Offline Limit (UCOL) data objects. Tag '82' '94' Value Application Interchange Profile Application File Locator Presence M M Table 30: Data Retrievable by GET PROCESSING OPTIONS Page 80 June 2008 . Table 30 defines the data returned.7 Files for Financial Transaction Interchange 7.5. only the Application Transaction Counter (ATC) is a mandatory data object.2 Book 3 Application Specification 7.3 Data Retrievable by GET DATA Command Data objects listed in Table 29 are not retrievable by the READ RECORD command but are retrieved by the terminal using the GET DATA command as described in this specification.

5 Erroneous or Missing Data in the ICC 7. months that are not in the range 1 to 12). Number of records participating in offline data authentication greater than the number of records (byte 4 > byte 3 . Table 31 summarises the conditions under which this bit should be set to 1. An AFL entry with invalid syntax. When an optional data object that is required because of the existence of other data objects or that is required to support functions that must be performed due to the setting of bits in the Application Interchange Profile is missing. the terminal shall set the bit to 0.2 as either mandatory or optional.byte 2 + 1). some optional data objects must be present to support optional functions selected by the issuer or must be present to avoid inconsistencies if other related data objects are present. June 2008 Page 81 . If none of the conditions in Table 31 applies. the terminal shall set the ‗ICC data missing‘ indicator in the Terminal Verification Results (TVR) to 1. the terminal shall terminate the transaction unless otherwise specified in these specifications. if in the course of normal processing the terminal recognises that data is incorrectly formatted. However.EMV 4. An AFL with no entries. any one or more of the following:     An SFI of 0 or 31. A starting record number of 0. the terminal terminates the transaction. Dates that are out of range (for example. An ending record number less than the starting record number (byte 3 < byte 2). This rule includes (but is not limited to):       Constructed data objects that do not parse correctly. However.2 Book 3 Application Specification 7 Files for Financial Transaction Interchange 7. that is. Multiple occurrences of a data object that should only appear once. Other data that must be in a specific range of values but are not. When any mandatory data object is missing. It is up to the issuer to ensure that data in the card is of the correct format. The setting of this bit is in addition to any other actions specified in other sections of this Book. and no format checking other than that specifically defined is mandated on the part of the terminal.5 Erroneous or Missing Data in the ICC Data objects in the card are classified in section 7.

ATC is not returned by GET DATA command and both Lower and Upper Consecutive Offline Limit data objects are present Not present and AIP indicates that cardholder verification is supported Not present and AIP indicates any form of offline data authentication is supported (SDA. as recovered from the Issuer Public Key Certificate. indicates that there was insufficient space for the entire ICC‘s Public Key in the certificate '8E' '8F' '90' '9F32' '92' Last Online Application Transaction Counter (ATC) Register Signed Static Application Data ICC Public Key Certificate ICC Public Key Exponent ICC Public Key Remainder '9F13' '93' '9F46' '9F47' '9F48' Table 31: ICC Data Missing Indicator Setting Page 82 June 2008 . indicates that there was insufficient space for the entire Issuer‘s Public Key in the certificate Last Online ATC Register is not returned by GET DATA command and both Lower and Upper Consecutive Offline Limits are present Not present and AIP indicates SDA supported Not present and AIP indicates DDA or CDA supported Not present and AIP indicates DDA or CDA is supported Not present and AIP indicates DDA or CDA is supported and the ‗length of the ICC Public Key‘... DDA or CDA) Not present and AIP indicates any form of offline data authentication is supported (SDA.2 Book 3 Application Specification Name Application Transaction Counter (ATC) Cardholder Verification Method (CVM) List Certification Authority Public Key Index Issuer Public Key Certificate Issuer Public Key Exponent Issuer Public Key Remainder Tag '9F36' ‘ICC Data Missing’ Shall Be Set If .7 Files for Financial Transaction Interchange 7.5 Erroneous or Missing Data in the ICC EMV 4. DDA or CDA) and the ‗length of the Issuer Public Key‘. DDA or CDA) Not present and AIP indicates any form of offline data authentication is supported (SDA. as recovered from the ICC Public Key Certificate. DDA or CDA) Not present and AIP indicates any form of offline data authentication is supported (SDA.

The remainder of this book deals with the terminal-to-ICC dialogue on the level of the application logical functions. SW2) or for missing data.2 Example Flowchart The flowchart in Figure 6 gives an example of a transaction flow that may be used by a terminal for a normal purchase transaction. 7 June 2008 Page 83 . including the selection of the application.EMV 4. or '6283' shall cause termination of the transaction. All restrictions on the order of processing are provided in section 10. Other actions may be taken by prior agreement but are outside the scope of this specification. Unless otherwise specified in these specifications.2 describes a possible transaction flow. 8. This flowchart is only an example. '63Cx'. 8. Book 1 describes all functionality outside the application layer. The functions described here begin after application selection has taken place. The terminal shall attempt to execute only those functions that the ICC supports.1 Exception Handling Exceptions to normal processing are described in this Book for specific status codes returned in the status bytes (SW1. Section 8. The functions shall be performed according to the Conditions of Execution as specified in section 10.7 This requirement applies throughout these specifications except for the Application Selection process described in Book 1.2 Book 3 Application Specification 8 Transaction Flow The Application Interchange Profile specifies the application functions that are supported by the card. and the order of processing may differ from that given here. any SW1 SW2 returned by the transport layer to the application layer other than '9000'.

Terminal Risk Management is performed in parallel with other functions.8 Transaction Flow 8.2 Example Flowchart EMV 4. Terminal Risk Management Processing Restrictions Cardholder Verification Terminal Action Analysis Card Action Analysis Online / Offline Online Decision Offline Online Processing & Issuer Authentication Completion Script Processing Figure 6: Transaction Flow Example Page 84 June 2008 .2 Book 3 Application Specification Initiate Application Read Application Data Data Authentication In this example.

EMV 4. June 2008 Page 85 . including those not implementing the proprietary functions.3 Additional Functions Provision has been made in this specification for additional functions beyond those described here. are not precluded.3 Additional Functions 8. Proprietary functions may be added to the terminal and the ICC application as long as they do not interfere with processing of terminals and ICCs not implementing the function. When a new function is added. Such additional functions may be:   future additions to this specification proprietary functions implemented by local or national agreement or by the individual payment systems The Application Interchange Profile indicates the functions supported in the ICC according to this specification. and this specification will be updated to specify the new function and where it fits into the transaction flow. For example. Most of the bits in this data object are reserved for future use (RFU). as long as the functions specified herein continue to be supported for all ICCs. a bit in the Application Interchange Profile will be allocated to indicate support for the new function. while not described in this specification. Such proprietary functions. offline dynamic data authentication based on symmetric keys may be added at local option.2 Book 3 Application Specification 8 Transaction Flow 8.

3 Additional Functions EMV 4.2 Book 3 Application Specification Page 86 June 2008 .8 Transaction Flow 8.

2 Book 3 Application Specification 9 GENERATE AC Command Coding The GENERATE AC command format and response codes are described fully in section 6.EMV 4.5.5. in which case processing continues with ‘Terminal requests AAC’ Card responds with TC Card responds with AAC No Completed online? Yes TAC/IAC default Reject Approve Reject Authorisation response code Approve Terminal requests AAC Terminal requests TC Card responds with AAC Card responds with TC or AAC June 2008 Page 87 . Earlier processing Reject offline Terminal decision Online Approve offline Terminal requests AAC Terminal requests ARQC Terminal requests TC Card responds with AAC Reject Card decision Online Card decision Offline approve Offline reject Online Card responds with ARQC Online-only terminals may optionally skip TAC/IAC Default processing. This section describes how the various options and data elements are used in transaction processing.

in which case processing continues with ‘Terminal requests AAC’ Card responds with TC Card responds with AAC No Completed online? Yes TAC/IAC default Reject Approve Reject Authorisation response code Approve Terminal requests AAC Terminal requests TC Card responds with AAC Card responds with TC or AAC Figure 7: Use of GENERATE AC Options Page 88 June 2008 . The complete transaction flow is not shown in these charts. and associated decisions. responses. ICC decisions.2 Book 3 Application Specification Figure 7 depicts the interaction between the terminal decisions. the GENERATE AC command. issuer approval. Earlier processing Reject offline Terminal decision Online Approve offline Terminal requests AAC Terminal requests ARQC Terminal requests TC Card responds with AAC Reject Card decision Online Card decision Offline approve Offline reject Online Card responds with ARQC Online-only terminals may optionally skip TAC/IAC Default processing. and the possible ICC responses.9 GENERATE AC Command Coding EMV 4. only the GENERATE AC commands.

There shall be two CDOLs in the ICC. To this end.4 to build the appropriate data field for the command. The terminal uses the appropriate CDOL and the rules specified in section 5. CDOL1 is used with the first GENERATE AC command.2 Book 3 Application Specification 9 GENERATE AC Command Coding 9. referred to as CDOL1 (tag '8C') and CDOL2 (tag '8D'). so it is imperative that the ICC knows the format of this data when the command is received. and CDOL2 is used with the second GENERATE AC command (if used).EMV 4.1 Card Risk Management Data The CDOL is a data object in the ICC that provides to the terminal a list of data objects that must be passed from the terminal to the ICC in the GENERATE AC command.2. 9. This is achieved by allowing the ICC to specify the format of the data to be included in the GENERATE AC command using a Card Risk Management Data Object List (CDOL).2 Command Data The data field of the GENERATE AC command is not TLV encoded.1 Command Parameters 9.1 Command Parameters The GENERATE AC command parameters provide three different options to the terminal:    Request for the generation of a TC Request for the generation of an ARQC Request for the generation of an AAC 9. the command data should be built immediately prior to issuing the GENERATE AC command. June 2008 Page 89 . It is the responsibility of the terminal to ensure that current data is used in building the GENERATE AC command.

3 Command Use EMV 4. If this event occurs.9 GENERATE AC Command Coding 9. The ICC shall respond to the first GENERATE AC command with any of the following:    TC ARQC AAC The ICC shall respond to a second GENERATE AC command with either a TC or an AAC. the transaction shall be terminated.2 Transaction Certificate Data A CDOL may request a TC Hash Value to be included in the command data of a GENERATE AC command.3 Command Use Either one or two GENERATE AC commands are issued during the processing of a transaction according to this specification. with a TC being the highest and an AAC being the lowest. all processing for the transaction has been completed. and the cryptogram returned shall be treated as an AAC. the terminal shall not set the ‗Default TDOL Used‘ bit in the TVR to 1.6. an ARQC. The TDOL is a data object that provides to the terminal a list of data objects to be used in generating the TC Hash Value.4. If the ICC response is an approval (TC) or online authorisation request (ARQC) and the ‗CDA signature requested‘ bit in the GENERATE AC command is 1. the terminal shall use the TDOL (if present) or the default TDOL to create the appropriate value for input to the hash algorithm. If the ICC responds with a cryptogram at a higher level or with a cryptogram of an undefined type.2. a default TDOL with no data objects in the list shall be assumed. for use in case the TDOL is not present in the ICC. If a default TDOL is required but is not present in the terminal. but there may be a default TDOL in the terminal. the ICC shall return the GENERATE AC response in a public key signature as specified in Book 2 section 6. If it occurs after the second GENERATE AC command. since the default TDOL was not used. The terminal may request a TC. 9. Page 90 June 2008 . the terminal shall set the ‗Default TDOL used‘ bit in the TVR to 1. The ICC may contain the TDOL. If the terminal issues a second GENERATE AC command during the processing of a transaction.2 Book 3 Application Specification 9. To create the hash value. or an AAC. The possible responses listed above are in hierarchical order. applying the rules specified in section 5. If this occurs after the first GENERATE AC command in a transaction. specified by the payment system. If the default TDOL is used. the terminal shall ensure that the data provided in the TC Hash Value is current at the time the command is issued. this indicates a logic error in the ICC.

The ICC shall reply with an AAC. the third and all succeeding GENERATE AC commands shall end with SW1 SW2 = '6985'. If an AAC was requested. it requests an AAC from the ICC.2 Book 3 Application Specification 9 GENERATE AC Command Coding 9. the ICC shall reply with either a TC or an AAC.5. or an AAC. The ICC shall reply with a TC. the terminal attempts to go online.   If the ICC responds with a TC or an AAC. If the terminal decides the transaction should go online. The form of the command depends upon the decision made by the terminal:  If the terminal decides the transaction might be completed offline.3. depending upon its own analysis of the transaction.1 GENERATE AC (First Issuance) The terminal completes its online/offline decision process with a GENERATE AC command (see section 6. The ICC shall permit at most two GENERATE AC commands in a transaction. If the terminal issues more than two. it completes the transaction by requesting either a TC (in the case an approval was obtained) or an AAC (in case the issuer‘s instruction is to reject the transaction) from the ICC.3. If a TC was requested. 9. June 2008 Page 91 . If the ICC responds with an ARQC. If the terminal decides to reject the transaction.2 GENERATE AC (Second Issuance) Whether the terminal receives an authorisation response message as a result of online processing or an approval or rejection by using the Issuer Action Code Default. it requests a TC from the ICC. The ICC shall reply with an ARQC.EMV 4. sending an authorisation request message to the issuer. and no cryptogram shall be returned. the card shall reply with an AAC. it requests an ARQC from the ICC. the terminal completes the transaction offline.5). an ARQC.3 Command Use 9. or an AAC. Included in the authorisation request message is the ARQC for online card authentication.

.

these bits could be set to 0 at the completion of the previous transaction or prior to application selection of this transaction. Only data elements having the terminal as the source of the data may be referenced in the PDOL. Sequence of Execution: This is the first function performed after Application Selection. Part II. the GET PROCESSING OPTIONS command uses a command data field of '8300'.1 Initiate Application Processing Purpose: The Initiate Application Processing function:     informs the ICC that the processing of a new transaction is beginning provides to the ICC the terminal-related information about the transaction obtains from the ICC the Application Interchange Profile and a list of files that contain the ICC data to be used in processing the transaction determines whether the transaction is allowed Conditions of Execution: The terminal shall always execute this function.EMV 4.8 The PDOL is a list of tags and lengths of terminal-resident data elements needed by the ICC in processing the GET PROCESSING OPTIONS command. indicating that the length of the value field in the command data is zero. 10. If the PDOL does not exist. For example. There may be some exceptions in the timing for this. 8 June 2008 Page 93 . which may contain additional terminal-specific requirements. The intent here is that the processing steps as described in the Application Specification presume the bits have been initialised to 0. Description: The terminal shall set all bits in the Transaction Status Information (TSI) and the Terminal Verification Results (TVR) to 0.2 Book 3 Application Specification 10 Functions Used in Transaction Processing The following sections shall be read in conjunction with Book 4.

the terminal extracts the PDOL from the FCI of the ADF and uses it to create a concatenated list of data elements without tags or lengths. Page 94 June 2008 . Other) is referenced in the PDOL and the terminal is unable to provide the amount at this point in transaction processing. the terminal shall eliminate the current application from consideration and return to the Application Selection function to select another application.5.2 Book 3 Application Specification If the PDOL exists. Authorised or Amount. The rules specified in section 5.1 Initiate Application Processing EMV 4.  The format of the response message is given in section 6.4 apply to processing of the PDOL.8. indicating that the transaction cannot be performed with this application. the amount field in the data element list shall be filled with hexadecimal zeroes. The terminal issues the GET PROCESSING OPTIONS command using either the command data field of '8300' (if there was no PDOL in the ICC) or a data object constructed with a tag of '83' and the appropriate length according to BER-TLV encoding rules and a value field that is the concatenated list of data elements resulting from processing the PDOL.10 Functions Used in Transaction Processing 10. If the status words '6985' are returned. and status SW1 SW2 = '9000'. The card returns either:  The Application Interchange Profilethe Application File Locator (identifying the files and records containing the data to be used for the transaction). If an amount field (either Amount. or Status SW1 SW2 = '6985' (‗Conditions of use not satisfied‘).

The second byte indicates the first (or only) record number to be read for that SFI. When the third byte is greater than the second byte.2 Book 3 Application Specification 10 Functions Used in Transaction Processing 10.2 Read Application Data 10. Description: The terminal shall read the files and records indicated in the AFL using the READ RECORD command identifying the file by its SFI. The third byte indicates the last record number to be read for that SFI. Its value is either greater than or equal to the second byte. The fourth byte may range from zero to the value of the third byte less the value of the second byte plus 1.  June 2008 Page 95 .2 Read Application Data Purpose: Data contained in files in the ICC are required by the terminal to perform the various functions used in transaction processing as described in this section. The AFL is a list identifying the files and records to be used in the processing of a transaction. The terminal must read this data from the ICC. If an error prevents the terminal from reading data from the ICC. When the third byte is equal to the second byte. only the record number coded in the second byte shall be read for that SFI.1). Each element of the list corresponds to a file to be read and is structured as follows:    The five most significant bits of the first byte indicate the SFI. The second byte shall never be set to zero.EMV 4. The three least significant bits of the first byte shall be set to zero. Sequence of Execution: The Read Application Data function is performed immediately following the Initiate Application Processing function. The terminal is to read only the records named in the AFL. the transaction shall be terminated (see section 8. all the records ranging from the record number in the second byte to and including the record number in the third byte shall be read for that SFI. The fourth byte indicates the number of records involved in offline data authentication starting with the record number coded in the second byte. Conditions of Execution: The terminal shall always execute this function.

whether mandatory or optional. to satisfy business requirements such as proprietary domestic processing.10 Functions Used in Transaction Processing 10. If any mandatory data objects are not present. inclusively. If the terminal encounters more than one occurrence of a single primitive data object while reading data from the ICC. Otherwise.3. the reading and processing of proprietary files is beyond the scope of this specification.9 All mandatory data objects shall be present in the card. but records containing such data objects may still participate in their entirety in offline data authentication. Payment system-specific tags are interpreted within the context of the application RID. multiple issuers may agree on the definition of a private class tag. Redundant primitive data objects are not permitted. Data objects that are not recognised by the terminal (that is. Records specified in the AFL to be included in offline data authentication shall be processed as described in section 10. the terminal shall terminate the transaction. their tags are unknown by the terminal) shall not be stored.2 Read Application Data EMV 4. Proprietary data files may or may not conform to this specification. Records in proprietary files may be represented in the AFL and may participate in offline data authentication if they are readable without conditions by the READ RECORD command coded according to this specification.5. Issuer-specific tags are interpreted within the context of the Issuer Identification Number (as defined in ISO/IEC 7812-1).2 Book 3 Application Specification The terminal shall process each entry in the AFL from left to right. depending upon the coding of the AFL. Additionally. the transaction shall be terminated. The terminal shall store all recognised data objects read. for later use in the transaction processing. Such tags may be interpreted in the context of other data such as Issuer Country Code. Any SW1 SW2 other than '9000' passed to the application layer as a result of reading any record shall cause the transaction to be terminated. 9 Page 96 June 2008 . A READ RECORD command as described in section 6.11 shall be issued for each record between the starting record number and the ending record number.

June 2008 Page 97 . the terminal shall perform CDA as specified in Book 2:   The Application Interchange Profile indicates that the card supports CDA. Either the card or the terminal (or both) does not support DDA. the terminal shall set the ‗Offline data authentication was not performed‘ bit in the TVR to 1. This specification describes how it is determined whether offline data authentication will be performed. If both of the following are true. its presence is indicated in the Application Interchange Profile.3 Offline Data Authentication 10. the terminal shall perform SDA as specified in this specification:     The Application Interchange Profile indicates that the card supports SDA. Either the card or terminal (or both) does not support CDA. If both the terminal and the ICC support offline data authentication. If neither SDA nor DDA nor CDA is performed. If all of the following are true. The terminal supports CDA.3 Offline Data Authentication Purpose: Offline data authentication is performed as specified in Book 2. The terminal supports SDA. Sequence of Execution: The terminal shall perform offline data authentication in any order after Read Application Data but before completion of the terminal action analysis. what kind of authentication will be performed. and how the success or failure of authentication affects the transaction flow and data recorded in the TVR and TSI. the terminal shall perform DDA as specified in Book 2:    The Application Interchange Profile indicates that the card supports DDA. Conditions of Execution: Availability of data in the ICC to support offline data authentication is optional. The terminal supports DDA.2 Book 3 Application Specification 10 Functions Used in Transaction Processing 10.EMV 4. SDA or DDA or CDA is performed. Depending on the capabilities of the card and the terminal. the terminal shall perform this function. If all of the following are true. Either the card or terminal (or both) does not support CDA.

The tag must represent the AIP available in the current application. Input to the authentication process is formed from the records identified by the AFL. Records are processed in the same sequence in which they appear within AFL entries. it shall contain only the tag for the Application Interchange Profile. and the card itself. For files with SFI in the range 11 to 30. All other data in the data field of the response to the READ RECORD command (excluding SW1 SW2) is included. (This is a necessary consequence of the design of CDA. The records read for offline data authentication shall be TLV-coded with tag equal to '70'. the terminal shall set the ‗Offline data authentication was performed‘ bit in the TSI to 1. DDA and CDA authenticate ICC-resident data.  For files with SFI in the range 1 to 10.3 Offline Data Authentication EMV 4. If the Static Data Authentication Tag List exists. and shall set the appropriate ‗SDA failed‘ or ‗DDA failed‘ or ‗CDA failed‘ bit in the TVR. The bytes of the record are included in the concatenation in the order in which they appear in the command response. The data from each record to be included in the offline data authentication input depends upon the SFI of the file from which the record was read. and each succeeding record is concatenated at the end of the previous record. The first record begins the input for the authentication process. the terminal will not normally finish performing CDA until after it has received the response to the GENERATE AC command. the record tag ('70') and the record length are not excluded from the offline data authentication process. followed by the data elements identified by the optional Static Data Authentication Tag List (tag '9F4A'). The value field of the AIP is to be concatenated to the current end of the input string. the Static Data Authentication Tag List is processed. if it exists. Page 98 June 2008 .  If the records read for offline data authentication are not TLV-coded with tag equal to '70' then offline data authentication shall be considered to have been performed and to have failed. After all records identified by the AFL have been processed.2 Book 3 Application Specification Note: Although the terminal shall commence performing CDA before completion of Terminal Action Analysis. data from the terminal. The records identified by a single AFL entry are to be processed in record number sequence. Only those records identified in the AFL as participating in offline data authentication are to be processed. the record tag ('70') and the record length are excluded from the offline data authentication process. Thus all data in the data field of the response to the READ RECORD command (excluding SW1 SW2) is included.) Description: SDA authenticates static data put into the card by the issuer. that is.10 Functions Used in Transaction Processing 10. The tag and length of the AIP are not included in the concatenation.

EMV 4.2 Book 3 Application Specification

10 Functions Used in Transaction Processing 10.3 Offline Data Authentication

Building of the input list for offline data authentication is considered the first step in the offline data authentication process. If the input cannot be built because of a violation of one of the above rules but offline data authentication should be performed according to the ‗Conditions of Execution‘ above, offline data authentication shall be considered to have been performed and to have failed; that is, the terminal shall set the ‗Offline data authentication was performed‘ bit in the TSI to 1 and shall set the appropriate ‗SDA failed‘ or ‗DDA failed‘ or ‗CDA failed‘ bit in the TVR. See Book 2 for additional steps to be performed for offline data authentication. If SDA is performed but is unsuccessful, the ‗SDA failed‘ bit in the TVR shall be set to 1; otherwise it shall be set to 0. If DDA is performed but is unsuccessful, the ‗DDA failed‘ bit in the TVR shall be set to 1; otherwise it shall be set to 0. If CDA is performed but is unsuccessful, the ‗CDA failed‘ bit in the TVR shall be set to 1; otherwise it shall be set to 0. Upon completion of the offline data authentication function, the terminal shall set the ‗Offline data authentication was performed‘ bit in the TSI to 1.

June 2008

Page 99

10 Functions Used in Transaction Processing 10.4 Processing Restrictions

EMV 4.2 Book 3 Application Specification

10.4

Processing Restrictions

Purpose: The purpose of the Processing Restrictions function is to determine the degree of compatibility of the application in the terminal with the application in the ICC and to make any necessary adjustments, including possible rejection of the transaction. Conditions of Execution: The terminal shall always execute this function. Sequence of Execution: Functions described here may be performed at any time after Read Application Data and prior to completion of the terminal action analysis. Description: The Processing Restrictions function comprises the following compatibility checks:    Application Version Number Application Usage Control Application Effective/Expiration Dates Checking

10.4.1

Application Version Number

The application within both the terminal and the ICC shall maintain an Application Version Number assigned by the payment system. The terminal shall use the version number in the ICC to ensure compatibility. If the Application Version Number is not present in the ICC, the terminal shall presume the terminal and ICC application versions are compatible, and transaction processing shall continue. If the Application Version Number is present in the ICC, it shall be compared to the Application Version Number maintained in the terminal. If they are different, the terminal shall set the ‗ICC and terminal have different application versions‘ bit in the TVR to 1.

Page 100

June 2008

EMV 4.2 Book 3 Application Specification

10 Functions Used in Transaction Processing 10.4 Processing Restrictions

10.4.2

Application Usage Control

The Application Usage Control indicates restrictions limiting the application geographically or to certain types of transactions. If this data object is present, the terminal shall make the following checks:   If the transaction is being conducted at an ATM, the ‗Valid at ATMs‘ bit must be on in Application Usage Control. If the transaction is not being conducted at an ATM, the ‗Valid at terminals other than ATMs‘ bit must be on in Application Usage Control.

If the Application Usage Control and Issuer Country Code are both present in the ICC, the terminal shall make the checks described in Table 32. then the following bit must be set to 1 in Application Usage Control: ‗Valid for domestic cash transactions‘ ‗Valid for international cash transactions‘ ‗Valid for domestic goods‘ and/or ‗Valid for domestic services‘ ‗Valid for international goods‘ and/or ‗Valid for international services‘ ‗Domestic cashback allowed‘ ‗International cashback allowed‘

If: Transaction Type indicates cash transaction Transaction Type indicates purchase (of goods/services) transaction has a cashback amount

and if Issuer Country Code: matches Terminal Country Code does not match Terminal Country Code matches Terminal Country Code does not match Terminal Country Code matches Terminal Country Code does not match Terminal Country Code

Table 32: Terminal Action Regarding Application Usage Control If any of the above tests fail, the terminal shall set the ‗Requested service not allowed for card product‘ bit in the TVR to 1.

June 2008

Page 101

10 Functions Used in Transaction Processing 10.4 Processing Restrictions

EMV 4.2 Book 3 Application Specification

10.4.3

Application Effective/Expiration Dates Checking

If the Application Effective Date is present in the ICC, the terminal shall check that the current date is greater than or equal to the Application Effective Date. If it is not, the terminal shall set the ‗Application not yet effective‘ bit in the TVR to 1. The terminal shall check that the current date is less than or equal to the Application Expiration Date. If it is not, the terminal shall set the ‗Expired application‘ bit in the TVR to 1.

Page 102

June 2008

A second amount field (4 bytes. Each CV Rule describes a CVM and the conditions under which that CVM should be applied (see Annex C3). the terminal shall process each rule in the order in which it appears in the list according to the following specifications. binary format). the terminal shall terminate cardholder verification without setting the ‗Cardholder verification was performed‘ bit in the TSI. binary format). ‗Y‘ is expressed in Application Currency Code with implicit decimal point. ‗X‘ is expressed in the Application Currency Code with implicit decimal point. Conditions of Execution: Ability of the ICC to support at least one cardholder verification method is indicated in the Application Interchange Profile. If the CVM List is present in the ICC.23 when the currency code is '826'. 123 (hexadecimal '7B') represents £1. referred to as ‗Y‘ in Table 40. If the CVM List is not present in the ICC. as shown in Annex C1. 123 (hexadecimal '7B') represents £1. 2.5 Cardholder Verification 10. Sequence of Execution: This function may be performed any time after Read Application Data and before completion of the terminal action analysis. June 2008 Page 103 . A variable-length list of two-byte data elements called Cardholder Verification Rules (CV Rules). Description: The CVM List (tag '8E') is a composite data object consisting of the following: 1. Cardholder verification is completed when any one CVM is successfully performed or when the list is exhausted. An amount field (4 bytes. Note: A CVM List with no Cardholder Verification Rules is considered to be the same as a CVM List not being present.5 Cardholder Verification Purpose: Cardholder verification is performed to ensure that the person presenting the ICC is the person to whom the application in the card was issued. For example. This process is described below. referred to as ‗X‘ in Table 40: CVM Condition Codes.23 when the currency code is '826'. For example. 3. If this bit is set to 1.EMV 4.2 Book 3 Application Specification 10 Functions Used in Transaction Processing 10. the terminal shall use the cardholder verification related data in the ICC to determine whether one of the issuer-specified cardholder verification methods (CVMs) shall be executed.

the terminal next checks to determine whether it supports the CVM. In case the CVM was PIN-related. If there are no more CV Rules in the list. the Application Currency Code or Amount. processing continues at step 2. then in addition the terminal shall set the ‗PIN entry required and PIN pad not present or not working‘ bit (b5 of byte 3) of the TVR to 1. If any of the following is true:    the conditions expressed in the second byte of a CV Rule are not satisfied. or failed). If the CVM is recognised. processing continues at step 2. o  If the CVM is not supported. cardholder verification is complete and successful. was not supported. the CVM was not recognised.2 Book 3 Application Specification If the terminal encounters formatting errors in the CVM List such as a list with an odd number of bytes (that is. the terminal examines b7 of byte 1 of the CV Rule. If the CVM just processed was ‗Fail CVM Processing‘. Authorised) is not present. If a card CVM List contains an entry for 'Fail CVM Processing.' it is strongly recommended that byte 1 bit 7 be set to 0 for this entry. If cardholder verification was not completed in step 1 (that is.  If the CVM is supported.5 Cardholder Verification EMV 4. the terminal next checks whether it recognises the CVM coded in the first byte of the CV Rule and proceeds according to the following steps: 1.10 If the CVM is not performed successfully. If the conditions expressed in the second byte of the CV Rule are satisfied. the terminal shall set the ‗Cardholder verification was not successful‘ bit in the TVR (b8 of byte 3) to 1 and no further CVMs shall be processed regardless of the setting of b7 of byte 1 in the first byte of the CV Rule. with an incomplete CVM Rule). o If the CVM is performed successfully. 10 Page 104 June 2008 . and the terminal shall set the ‗Cardholder verification was not successful‘ bit in the TVR to 1.5. or data required by the condition (for example. cardholder verification has not been successful. the terminal shall terminate the transaction as specified in Book 3 section 7. or the CVM Condition Code is outside the range of codes understood by the terminal (which might occur if the terminal application program is at a different version level than the ICC application). If the CVM is not recognised. the terminal shall set the ‗Unrecognised CVM‘ bit in the TVR (b7 of byte 3) to 1 and processing continues at step 2. then the terminal shall bypass the rule and proceed to the next. 2. the terminal shall attempt to perform it.10 Functions Used in Transaction Processing 10.

5 set the ‗Cardholder verification was performed‘ bit in the TSI to 1.EMV 4. the terminal shall:   set the CVM Results according to Book 4 section 6. cardholder verification is complete and unsuccessful.3. When cardholder verification is completed. or there are no more CV Rules in the list.4. if one is present. If b7 is set to 0.5 Cardholder Verification   If b7 is set to 1. June 2008 Page 105 . The terminal shall set the ‗Cardholder verification was not successful‘ bit in the TVR (b8 of byte 3) to 1.2 Book 3 Application Specification 10 Functions Used in Transaction Processing 10. processing continues with the next CV Rule.

12 Page 106 June 2008 . the terminal shall set the ‗PIN Try Limit exceeded‘ bit in the TVR to 1. If the terminal supports at least one of these functions. If the transaction goes online. If an offline PIN is the selected CVM as determined by the above process. In this case. In this case. This means that the terminal does not support either offline plaintext PIN verification or offline enciphered PIN verification. it is considered to support offline PIN for the purposes of setting the TVR bits. The PIN is blocked upon initial use of the VERIFY command or if recovery of the enciphered PIN Block has failed (the ICC returns SW1 SW2 = '6983' or '6984' in response to the VERIFY command). The terminal bypassed PIN entry at the direction of either the merchant or the cardholder. the issuer can decide whether to accept the transaction without the PIN. offline PIN processing may not be successfully performed for any one of the following reasons:  The terminal does not support offline PIN. In this case. the terminal shall set the ‗PIN Try Limit exceeded‘ bit in the TVR to 1. the terminal shall set the ‗PIN entry required and PIN pad not present or not working‘ bit in the TVR to 1. but PIN was not entered‘ bit in the TVR to 1.11 In this case. The terminal shall consider this CVM unsuccessful and shall continue cardholder verification processing in accordance with the card‘s CVM List.     The only case in which offline PIN processing is considered successful is when the ICC returns an SW1 SW2 of '9000' in response to the VERIFY command.5 Cardholder Verification EMV 4. 11 Especially for a new cardholder or during conversion to PINs.10 Functions Used in Transaction Processing 10.5.2 Book 3 Application Specification 10. The number of remaining PIN tries is reduced to zero (indicated by an SW1 SW2 of '63C0' in the response to the VERIFY command). The terminal supports offline PIN. the terminal shall set the ‗PIN entry required.1 Offline PIN Processing This section applies to the verification by the ICC of a plaintext or enciphered PIN presented by the terminal. but the PIN pad is malfunctioning. it is likely that a cardholder will realize that he or she does not know the PIN.12 In this case. PIN pad present. In this case. it is better to bypass PIN processing with an indication to the issuer of the circumstances than it is to either terminate the transaction or try numbers until the PIN try count is exhausted. the terminal shall set the ‗PIN entry required and PIN pad not present or not working‘ bit in the TVR to 1.

10.2 Book 3 Application Specification 10 Functions Used in Transaction Processing 10. The terminal bypassed PIN entry at the direction of either the merchant or the cardholder. The terminal supports online PIN. the terminal shall set the ‗PIN entry required. the terminal shall set the ‗Online PIN entered‘ bit in the TVR to 1.EMV 4.3 Signature Processing If a (paper) signature is a required CVM as determined by the above process. If the terminal is able to support signature. In this case.5 CVM Processing Logic The flows on the following pages illustrate the CVM processing logic but do not contain all the details of the execution of the selected CVM.4 Combination CVMs Some CVMs require multiple verification methods (for example. June 2008 Page 107 . all methods in the CVM must be successful for cardholder verification to be considered successful. In this case. 10. the terminal shall set the ‗PIN entry required and PIN pad not present or not working‘ bit in the TVR to 1.5.5. offline PIN plus signature). In this case. cardholder verification is considered successful and complete. the processing may not be successfully performed for any one of the following reasons:  The terminal does not support online PIN.5. For these CVMs. the terminal shall set the ‗PIN entry required and PIN pad not present or not working‘ bit in the TVR to 1. the process is considered successful. In this case. but the PIN pad is malfunctioning. 10.5.5 Cardholder Verification 10.   If the online PIN is successfully entered. the terminal shall determine success based upon the terminal‘s capability to support the signature process (see complementary payment systems documentation for additional information).2 Online PIN Processing If online PIN processing is a required CVM as determined by the above process. and cardholder verification is complete. PIN pad present. but PIN was not entered‘ bit in the TVR to 1.

.2 Book 3 Application Specification CVM List Processing CVM = Fail CVM YES C NO AIP supports CVM processing YES NO CVM List present with CV rules? YES D NO Terminal recognises CVM? NO Set 'Unrecognised CVM' in TVR Is CVM Code Supported? * YES Set TVR 'ICC Data Missing' NO Set CVM Results to ‘3F0000’ . For non-EMV defined codes. For Combination CVMs.10 Functions Used in Transaction Processing 10. support is indicated in Terminal Capabilities. Perform CVM (See U in Part 3 .'No CVM performed' Terminal selects first or next CV Rule in CVM List Perform 'Selected CVM Code is not Supported' Logic (See T in Part 2 of flow) YES A CVM Condition = 'Always'? YES B * Note: For EMV defined codes.Apply next CVM CVM Failed CV Rule Byte 1 bit 7 = . support is known implicitly. CVM) NO CVM Condition = 'If terminal supports CVM'? NO CVM Condition rules satisfied? (See S in Part 2 of flow) NO '1' .Online PIN V in Part 3 – Signature W in Part 3 – No CVM Req’d X in Part 4 – Offline PIN Z in Part 5 – Combo. both CVMs must be supported. Is CVM Code supported? * NO Set CVM Results to ‘Failed’ (See Y in Part 5 of flow) A YES YES B D Any more CVM entries? NO C Set 'Cardholder verification not successful' in TVR. YES CVM Failed? NO YES YES C '0' Fail CVM processing Set Cardholder Verification was Performed in TSI. CVM List Processing Complete Figure 8: CVM Processing (Part 1 of 5) Page 108 June 2008 ..5 Cardholder Verification EMV 4.

5 Cardholder Verification 'CVM Condition Rules Satisfied?' Logic S (From Part 1 of flow) 'Selected CVM Code Is Not Supported' Logic T (From Part 1 of flow) Terminal understands CVM Condition? NO CVM = Online PIN? NO YES YES CVM Condition data available? YES CVM = Offline PIN? NO YES Any form of Offline PIN supported? NO NO NO Set 'PIN entry req'd but PIN pad not present or not working' in TVR.EMV 4. YES CVM Condition rules satisfied.2 Book 3 Application Specification 10 Functions Used in Transaction Processing 10. CVM Condition satisfied? YES CVM Condition rules not satisfied. Continue with Part 1 of flow Continue with Part 1 of flow Figure 9: CVM Processing (Part 2 of 5) June 2008 Page 109 .

10 Functions Used in Transaction Processing 10. Set CVM Results to 'Unknown' NO Either bypassed for the current CVM or (optionally) bypassed during processing of a previous PIN-related CVM.2 Book 3 Application Specification U (From Part 1 of flow) V (From Part 1 of flow) W (From Part 1 of flow) Request PIN entry Set terminal to print signature line on receipt.5 Cardholder Verification EMV 4. Continue with Part 1 of flow Continue with Part 1 of flow Set ‘Online PIN Entered’ in TVR to ‘1’ Consider that Online PIN CVM is successful Consider that Online PIN CVM is not successful Continue with Part 1 of flow Figure 10: CVM Processing (Part 3 of 5) Page 110 June 2008 . Set CVM Results to 'Successful' PIN pad is malfunctioning? YES Terminal sets 'PIN entry req'd but PIN pad not present or not working' in TVR. PIN entry bypassed? YES Consider that CVM is successful Consider that CVM is successful NO Set CVM Results to 'Unknown' Terminal sets 'PIN entry req'd but PIN was not entered' in TVR.

5 Cardholder Verification Offline PIN X (From Part 1 of flow) Ask for PIN entry PIN pad is malfunctioning? Terminal issues GET DATA for PIN Try Counter? NO NO YES Terminal sets 'PIN entry req'd but PIN pad not present or not working' in TVR. YES Recover the public key to be used for PIN encipherment . YES PIN Try Counter = 0? Recovery OK? YES NO YES E YES Get unpred.EMV 4. Continue with Part 1 of flow Figure 11: CVM Processing (Part 4 of 5) June 2008 Page 111 . 6983. number from ICC with GET CHALLENGE SW1SW2 = 63Cx with x > 0? NO GET CHALLENGE OK? YES Encipher PIN using recovered ICC key E Set PIN Try Limit exceeded in TVR Consider that Offline PIN CVM is not successful NO Set CVM Results to 'Successful' YES SW1SW2 = 9000? NO Consider that Offline PIN CVM is successful SW1SW2 = 63C0. 6984? NO Terminate transaction YES Continue with Part 1 of flow * Either bypassed for the current CVM or (optionally) bypassed during processing of a previous PIN-related CVM.2 Book 3 Application Specification 10 Functions Used in Transaction Processing 10. PIN entry bypassed? * YES NO PIN Try Counter retrieved? NO Offline Enciphered PIN? NO NO Send enciphered or plaintext PIN to ICC in VERIFY command YES Terminal sets 'PIN entry req'd but PIN was not entered' in TVR.

) YES NO Both CVMs are successful? YES NO CVM for satisfied CVM Condition was recognised and supported? NO Consider that Combination CVM is successful Consider that Combination CVM is unsuccessful Set CVM Results to ‘Failed’ with the Method Code and CVM Condition reflecting the last CVM performed.10 Functions Used in Transaction Processing 10.2 Book 3 Application Specification Setting CVM Results to Failed Y (From Part 1 of flow) Combination CVMs Z (From Part 1 of flow) Was any CVM Condition satisfied? Perform CVM 1 and CVM 2 (See parts 3 and 4 of flow.5 Cardholder Verification EMV 4. Set CVM Results to ‘3F 00 01‘ YES Result of either CVM is ‘unknown’? NO Set CVM Results to 'Unknown' Set CVM Results to 'Successful' Continue with Part 1 of flow Continue with Part 1 of flow Figure 12: CVM Processing (Part 5 of 5) Page 112 June 2008 .

The result of terminal risk management is the setting of appropriate bits in the TVR.2 Book 3 Application Specification 10 Functions Used in Transaction Processing 10. and system from fraud. sections 10. It provides positive issuer authorisation for high-value transactions and ensures that transactions initiated from ICCs go online periodically to protect against threats that might be undetectable in an offline environment. If terminal risk management is not performed. Description: Terminal risk management consists of:    Floor limit checking Random transaction selection Velocity checking Upon completion of terminal risk management. Note: To better control local risk management. Sequence of Execution: Terminal risk management may be performed at any time after Read Application Data but before issuing the first GENERATE AC command. Conditions of Execution: Terminal risk management shall be performed if the ‗Terminal risk management is to be performed ‘ bit in the Application Interchange Profile is set to 1.6 Terminal Risk Management 10.6.6.EMV 4. the terminal shall set the ‗Terminal risk management was performed‘ bit in the TSI to 1. Random transaction selection need not be performed by a terminal with no online capability.1 through 10. terminals may perform terminal risk management even when the ‗Terminal risk management is to be performed‘ bit in the Application Interchange Profile is set to 0. issuer.6 Terminal Risk Management Purpose: Terminal risk management is that portion of risk management performed by the terminal to protect the acquirer. June 2008 Page 113 .3 do not apply.

10 Functions Used in Transaction Processing 10. The number of transactions to be stored and maintenance of the log are outside the scope of this specification. This is the desired percentage of transactions ‗just below‘ the floor limit that will be selected by this algorithm. Authorised for the current transaction to the amount stored in the log for that PAN to determine if the sum exceeds the Terminal Floor Limit.1 Floor Limits To prevent split sales. During terminal risk management floor limit checking. the terminal sets the ‗Transaction exceeds floor limit‘ bit to 1 in the TVR.2 Book 3 Application Specification 10.6 Terminal Risk Management EMV 4. Page 114 June 2008 . If the terminal does not have a transaction log available or if there is no log entry with the same PAN. the terminal checks the transaction log (if available) to determine if there is a log entry with the same Application PAN. The terminal shall generate a random number in the range of 1 to 99. If the amount authorised is equal to or greater than the floor limit. 10. although to prevent split sales the number of transactions stored may be quite small. optionally. the transaction shall be selected. If the sum is greater than or equal to the Terminal Floor Limit. Authorised is compared to the appropriate floor limit. The terminal adds the Amount. the terminal shall set the ‗Transaction exceeds floor limit‘ bit in the TVR to 1. the same Application PAN Sequence Number.6. and. If there are several log entries with the same PAN. the terminal selects the most recent entry.6.2 Random Transaction Selection For each application the relevant payment system specifies. If this random number is less than or equal to the ‗Target Percentage to be used for Random Selection‘. in addition to the floor limit:    ‗Target Percentage to be Used for Random Selection‘ (in the range of 0 to 99) Threshold Value for Biased Random Selection (which must be zero or a positive number less than the floor limit) ‗Maximum Target Percentage to be Used for Biased Random Selection‘ (also in the range of 0 to 99 but at least as high as the previous ‗Target Percentage to be Used for Random Selection‘). the Amount. Any transaction with a transaction amount less than the Threshold Value for Biased Random Selection will be subject to selection at random without further regard for the value of the transaction. the terminal may have a transaction log of approved transactions stored in the terminal consisting of at least the Application PAN and transaction amount and possibly the Application PAN Sequence Number and Transaction Date.

the terminal shall set the ‗Transaction selected randomly for online processing‘ bit in the TVR to 1.EMV 4. which is a linear interpolation of the target percentages provided by the payment system (‗Target Percentage to be used for Random Selection‘ and ‗Maximum Target Percentage to be used for Biased Random Selection‘).2 Book 3 Application Specification 10 Functions Used in Transaction Processing 10.Target Percent   Int erpola t ion fact or  June 2008 Page 115 . Aut horised  Threshold Va lue Floor Limit  Threshold Va lue Transact ion Target P ercent = Maximum Ta rget  Target Percent Percent . the terminal shall compare its generated random number against a Transaction Target Percent. 13 The Transaction Target Percent is calculated as follows: Int erpola t ion fa ct or  Amount . Figure 13 illustrates the probability of selection as a function of the transaction amount: 1 Probability of Selection 0 Biased Selection Threshold Floor Limit Figure 13: Random Transaction Selection Example If the transaction is selected through the process described in this section. 13 If the random number is less than or equal to the Transaction Target Percent. the transaction shall be selected. For these transactions.6 Terminal Risk Management Any transaction with a transaction amount equal to or greater than the Threshold Value for Biased Random Selection but less than the floor limit will be subject to selection with bias toward sending higher value transactions online more frequently (biased random selection).

if the terminal is incapable of going online. If either of the required data objects is not returned by the ICC in response to the GET DATA command. If the difference is equal to the Lower Consecutive Offline Limit. the terminal shall set the ‗New card‘ bit in the TVR to 1.2 Book 3 Application Specification 10. the recommendation of the issuer might be to reject any transaction that cannot be completed online. After the upper limit is reached. or if the value of the ATC is less than or equal to the value in the Last Online ATC Register. so that transactions may be processed offline until the lower limit is again reached. The terminal shall also check the Last Online ATC Register for a zero value. The ATC and Last Online ATC Register shall be read from the ICC using GET DATA commands. after a certain number of consecutive offline transactions (the Lower Consecutive Offline Limit). End velocity checking for this transaction. the terminal shall compare the difference between the ATC and the Last Online ATC Register with the Lower Consecutive Offline Limit to see if the limit has been exceeded. the terminal shall perform velocity checking as described in this section.6 Terminal Risk Management EMV 4. the terminal shall skip this section. this means that the limit has not yet been exceeded.6. the terminal shall set the ‗Lower consecutive offline limit exceeded‘ bit in the TVR to 1 and also compare the difference with the Upper Consecutive Offline Limit to see if the upper limit has been exceeded. Once a transaction has been completed online with successful issuer authentication. 14 If either of these data objects is not present in the ICC application. If it has. transactions may still be completed offline until a second (Upper Consecutive Offline Limit) limit is reached.10 Functions Used in Transaction Processing 10. the terminal shall set the ‗Upper consecutive offline limit exceeded‘ bit in the TVR to 1. If the required data objects are available. Not set the ‗New card‘ indicator in the TVR unless the Last Online ATC Register is returned and equals zero. the count begins anew. If it is zero. However. the terminal shall:    Set both the ‗Lower consecutive offline limit exceeded‘ and the ‗Upper consecutive offline limit exceeded‘ bits in the TVR to 1. 14 Page 116 June 2008 .3 Velocity Checking If both the Lower Consecutive Offline Limit (tag '9F14') and Upper Consecutive Offline Limit (tag '9F23') exist. transactions should be completed online. The purpose of velocity checking is to allow an issuer to request that. If the limit has been exceeded.

it may be desirable to perform this function immediately to determine whether the transaction should be rejected offline based upon the issuer‘s parameters in the ICC or the acquirer‘s parameters in the terminal. Sequence of Execution: The terminal action analysis function is performed after terminal risk management and cardholder and/or merchant transaction data entry has been completed. Conditions of Execution: The terminal action analysis function is always performed.   If the outcome of this decision process is to proceed offline. If the decision is to reject the transaction. If any processing results in the setting of a bit in the TVR (for example. If the outcome of the decision is to go online. the ICC. June 2008 Page 117 .2 Book 3 Application Specification 10 Functions Used in Transaction Processing 10.Default and Terminal Action Code . may return an ARQC or AAC. the terminal makes the first decision as to whether the transaction should be approved offline. The Issuer Action Code . Multiple execution of this decision process is optional on the part of the terminal.7 Terminal Action Analysis 10.Default processing described below shall also be performed after online processing is attempted in the case where the terminal was unable to process the transaction online. the terminal issues a GENERATE AC command to ask the ICC to return a TC.EMV 4. declined offline. the terminal issues a GENERATE AC to ask for an Application Authentication Cryptogram (AAC). failure of cardholder verification). If the terminal asks for a TC from the ICC. The terminal action analysis function may be executed at several places during a transaction to eliminate the need for unnecessary processing. the terminal issues a GENERATE AC command to ask the ICC for an Authorisation Request Cryptogram (ARQC). as a result of card risk management.7 Terminal Action Analysis Purpose: Once terminal risk management and application functions related to a normal offline transaction have been completed.  An offline decision made here is not final. or transmitted online. Recognition of such a decision early in processing may allow the terminal to avoid prolonging a transaction that will ultimately be rejected. It shall be performed prior to the first use of the GENERATE AC command.

Denial Terminal Action Code . Each has one bit corresponding to each bit in the TVR. The purpose of each is described in this section. the Terminal Action Code . The ICC contains (optionally) three data elements to reflect the issuer‘s selected action to be taken based upon the content of the TVR. and acquirer action preferences according to the method described in this section. complete it online. The purpose of each is described in this section. these three data objects are termed the Terminal Action Codes. or complete it offline based upon the TVR. Without this protection.Default should be included with the bits corresponding to ‗Offline data authentication was not performed‘.Online and Terminal Action Code . These data elements are:    Terminal Action Code . The three data elements are:    Issuer Action Code . Each has one bit corresponding to each bit in the TVR. these three data objects are termed the Issuer Action Codes. The format of each is identical and mirrors the TVR. the terminal may contain three data elements to reflect the acquirer‘s selected action to be taken based upon the content of the TVR. a default value consisting of all bits set to 0 is to be used in its place.2 Book 3 Application Specification Description: The terminal shall make a preliminary decision to reject the transaction. Thus.15 This protects against a fraudulent card with all the bits in the Issuer Action Code set to 0. However. or ‗DDA failed‘ or ‗CDA failed‘ set to 1. issuer action preferences. The existence of each of the Terminal Action Codes is optional.Default Collectively. and either ‗SDA failed‘. The format of each is identical and mirrors the TVR. In the absence of any Terminal Action Code. it is strongly recommended that as a minimum.Denial Issuer Action Code . Similarly. and the Terminal Action Code (TAC) bit specifies an action to be taken if the corresponding bit in the TVR is set to 1. Each of the three data elements has defaults specified here in case any of these data elements are absent from the ICC.7 Terminal Action Analysis EMV 4.Default Collectively.Online Issuer Action Code . All transactions would be approved offline. 15 Page 118 June 2008 . the size and format of each of the Issuer Action Codes is identical to the TVR. such a card could be created with no possibility of going online or declining transactions.10 Functions Used in Transaction Processing 10.Online Terminal Action Code . Thus. the size and format of each of the Terminal Action Codes is identical to the TVR and to the Issuer Action Codes. and the Issuer Action Code (IAC) bit specifies an action to be taken if the corresponding bit in the TVR is set to 1.

Offline-only terminals may skip this test and proceed to checking the Issuer Action Code .Default is processed together with the Terminal Action Code . the terminal shall inspect each bit in the TVR. June 2008 Page 119 . a default value with all bits set to 0 is to be used. the Issuer Action Code . the Issuer Action Code . the terminal shall inspect each bit in the TVR.Online is processed together with the Terminal Action Code Online.Online and the Terminal Action Code . This AAC may be presented to the issuer to prove card presence during this transaction. it indicates that the issuer or the acquirer wishes the transaction to be rejected offline. Processing of the action codes shall be performed in the order specified here. These data objects are meaningful only for terminals capable of online processing.Denial.Default and Terminal Action Code Default.Online is not present. If the Issuer Action Code .2 Book 3 Application Specification 10 Functions Used in Transaction Processing 10.Denial. it shall continue transaction processing online. For an online-only terminal. the terminal shall complete transaction processing online and shall issue a GENERATE AC command requesting an ARQC from the ICC. If the bit in either of the action codes is set to 1.Online. the terminal shall check the corresponding bits in both the Issuer Action Code Online and the Terminal Action Code . if the terminal has not already decided to reject the transaction as described above.Online specify the conditions that cause a transaction to be completed online. and shall issue a GENERATE AC command requesting an ARQC from the card.7 Terminal Action Analysis Processing of the action codes is done in pairs.EMV 4. Otherwise. If either data object exists.Denial and the Terminal Action Code . a default value with all bits set to 1 shall be used in its place.Default. described below. the terminal shall issue a GENERATE AC command requesting a TC from the ICC. Together. the terminal shall issue a GENERATE AC command to request an AAC from the ICC. Together. In this case. the Issuer Action Code Denial is processed together with the Terminal Action Code . but details of handling a rejected transaction are outside the scope of this specification. that is. the Issuer Action Code .Denial does not exist. For each bit in the TVR that has a value of 1. For a terminal capable of online processing. if it has not already decided to reject the transaction as described above. and the Issuer Action Code . For each bit in the TVR that has a value of 1. If the Issuer Action Code .Denial and the Terminal Action Code . If the corresponding bit in either of the action codes is set to 1.Denial specify the conditions that cause denial of a transaction without attempting to go online. the terminal shall check the corresponding bits in the Issuer Action Code .

3 of this book and section 6.Default or the Terminal Action Code . this could result in a TC being requested with the second GENERATE AC command (depending upon the TAC/IAC Default settings). The Issuer Action Code .Default are used only if the Issuer Action Code Online and the Terminal Action Code . In the event that an online-only terminal was unable to successfully go online.Default specify the conditions that cause the transaction to be rejected if it might have been approved online but the terminal is for any reason unable to process the transaction online. Together. and a GENERATE AC command shall be issued to the ICC requesting a TC. the transaction may be approved offline. Note that if an online-only terminal is unable to successfully go online and TAC/IAC Default processing is optionally performed. it shall request an AAC with the second GENERATE AC command. If CDA is to be performed (as described in section 10. 16 Page 120 June 2008 .Default and the Terminal Action Code . If the terminal has not already rejected the transaction and the terminal is for any reason unable to process the transaction online. If no such condition appears. If any bit in Issuer Action Code . a default value with all bits set to 1 shall be used in its place. it may optionally skip TAC/IAC Default processing (shown in Figure 7 for a transaction that was not completed on-line)16. the Issuer Action Code . in case of an offline-only terminal) or indicated a desire on the part of the issuer or the acquirer to process the transaction online but the terminal was unable to go online. the terminal shall use this code to determine whether to approve or reject the transaction offline.7 Terminal Action Analysis EMV 4.Default and the corresponding bit in the TVR are both set to 1.2 Book 3 Application Specification If the Issuer Action Code .Default does not exist. the transaction shall be rejected and the terminal shall request an AAC to complete processing.6 of Book 2). the terminal shall set the bit for ‗CDA Signature Requested‘ in the GENERATE AC command to 1.10 Functions Used in Transaction Processing 10. If an online-only terminal does skip TAC/IAC Default processing.Online were not used (for example.Default and the Terminal Action Code .

The ICC may also decide that an advice message should be sent to the issuer to inform the issuer of an exceptional condition. or an AAC to the terminal in response to a GENERATE AC command. the terminal shall set the ‗Card risk management was performed‘ bit in the TSI to 1. an ARQC.5. this section applies to all transactions. but as a result of the risk management process.7. June 2008 Page 121 .2 Book 3 Application Specification 10 Functions Used in Transaction Processing 10. Therefore. Details of card risk management algorithms within the ICC are specific to the issuer and are outside the scope of this specification.5. an ICC may decide to complete a transaction online or offline or reject the transaction.   The decision by the ICC is made known to the terminal by returning a TC. as described in section 6. Description: The result of risk management performed by the ICC is a decision for one of the following actions to be taken by the terminal:  Approve the transaction offline. Conditions of Execution: The card online/offline decision is specified by its response to the GENERATE AC command.EMV 4. Upon the completion of the card action analysis function. Whether the ICC performs any risk management tests is transparent to the terminal and outside the scope of this specification. This option is available to the ICC only if the terminal has made a preliminary decision to complete the transaction offline. Sequence of Execution: The card action analysis process is performed when the terminal issues the GENERATE AC command for a given transaction. Complete the transaction online. Reject the transaction. as described in section 10.8 Card Action Analysis Purpose: An ICC may perform its own risk management to protect the issuer from fraud or excessive credit risk.8 Card Action Analysis 10.

but allowance has been made for the addition of other cases later. In both cases. the AAC was returned due to card restrictions. the card application may be restricted only to specific merchant categories).2.5.2 Book 3 Application Specification 10.1 Terminal Messages for an AAC An AAC returned by the card indicates either a rejection of the specific transaction or a restriction that disallows use of the card in the environment of the transaction (for example. If an AAC is returned with b3-b1 = '001' in the Cryptogram Information Data. Further information may be found in complementary payment system documentation. Page 122 June 2008 . see Table 14).10 Functions Used in Transaction Processing 10.7 and 12.8. separate from either an authorisation request or a clearing message. If b4 of the Cryptogram Information Data is 1.8. to be sent in certain exception cases.5). The card may optionally distinguish the cases by the use of the code returned in the Cryptogram Information Data (see the GENERATE AC command in section 6.5. the only identified such case is ‗PIN Try Limit exceeded‘.8 Card Action Analysis EMV 4. sections 6. the terminal shall process the transaction as shown in Book 4. 10.2 Advice Messages The issuer may wish for an advice message. (Currently.3. but the terminal may choose to display different messages in the two cases. the card disapproves the transaction.

as described in Part I. 18 June 2008 Page 123 . Description: In general. or the acquirer. The ARQC may be sent in the authorisation request message. If the Issuer Authentication Data is received in the authorisation response message and the Application Interchange Profile indicates that the ICC supports issuer authentication. Subsequent to card authentication. However.9 Online Processing Purpose: Online processing is performed to ensure that the issuer can review and authorise or reject transactions that are outside acceptable limits of risk defined by the issuer. The ICC may use the Issuer Authentication Data to authenticate that the response message originated from the issuer. an explanation of what is expected to take place at the issuer may be useful for clarity. the Issuer Authentication Data shall be sent to the ICC in the EXTERNAL AUTHENTICATE command. The terminal provides the Issuer Authentication Data to the ICC in the EXTERNAL AUTHENTICATE command or the second GENERATE AC command. the payment system. The issuer uses this key to authenticate the ARQC and thereby authenticate the card. Conditions of Execution: Online processing shall be performed if the ICC returns an ARQC in response to the first GENERATE AC command for the transaction. The ARQC is a cryptogram generated by the card from transaction data using an issuer key stored in the card and known at the issuer authorisation system. This process is termed ‗online card authentication‘ or simply ‗card authentication‘. This cryptogram is sent to the terminal in the authorisation response as part of the Issuer Authentication Data. Actions performed by the acquirer or issuer systems are outside the scope of this specification.9 Online Processing 10. If the ICC responds with SW1 SW2 other than '9000'. This section is limited to the additional online processing provided in an ICC environment that is not available in a magnetic stripe environment. online processing is the same as online processing of magnetic stripe transactions and is not described here.2 Book 3 Application Specification 10 Functions Used in Transaction Processing 10. the issuer may generate a cryptogram on selected data included in the authorisation response or already known to the card.EMV 4. Sequence of Execution: The online processing function is performed when the terminal receives an ARQC in response to the first GENERATE AC command. the terminal shall set the ‗Issuer authentication failed‘ bit in the TVR to 1.18 The authorisation response message from the issuer may contain the Issuer Authentication Data (tag '91').

2 Book 3 Application Specification If the Issuer Authentication Data is received but the Application Interchange Profile indicates that the ICC does not support issuer authentication. the second and all succeeding EXTERNAL AUTHENTICATE commands shall end with SW1 SW2 = '6985'. Upon completion of online processing. the terminal shall set the ‗Issuer authentication was performed‘ bit in the TSI to 1.10 Functions Used in Transaction Processing 10. or if no Issuer Authentication Data is received. the terminal shall not execute the EXTERNAL AUTHENTICATE command. Note: Annex F provides additional information about status words to be returned in response to an EXTERNAL AUTHENTICATE command. if the EXTERNAL AUTHENTICATE command was sent to the card by the terminal. this indicates that the ICC has combined the issuer authentication function with the GENERATE AC command. Page 124 June 2008 . If the terminal issues more than one.9 Online Processing EMV 4. In this case. The ICC shall permit at most one EXTERNAL AUTHENTICATE command in a transaction.

10 Issuer-to-Card Script Processing 10. Conditions of Execution: None. but the terminal shall deliver each command to the ICC individually according to this specification.19 A script may contain Issuer Script Commands not known to the terminal.EMV 4. which might be done differently by various issuers or payment systems. Sequence of Execution: Two separate script tags are available for use by the issuer. Script processing is provided to allow for functions that are outside the scope of this specification but are nonetheless necessary. An example might be unblocking of an offline PIN.10 Issuer-to-Card Script Processing Purpose: An issuer may provide command scripts to be delivered to the ICC by the terminal to perform functions that are not necessarily relevant to the current transaction but are important for the continued functioning of the application in the ICC. Multiple scripts may be provided with an authorisation response. Issuer scripts with tag '71' shall be processed prior to issuing the final GENERATE AC command. and each may contain any number of Issuer Script Commands. 19 June 2008 Page 125 .2 Book 3 Application Specification 10 Functions Used in Transaction Processing 10. Issuer scripts with tag '72' shall be processed after issuing the final GENERATE AC command.

T '71' or '72' L L(data. it is meaningful only to the issuer.10 Functions Used in Transaction Processing 10. The terminal shall examine only SW1 in the response APDU and perform one of the following actions:  If SW1 indicates either normal processing or a ‗warning‘ according to the conventions described in this specification. The terminal shall process each Issuer Script in the sequence in which it appears in the authorisation response according to the following rules:    Issuer Script Commands shall be separated using the BER-TLV coding of the data objects defining the commands (tag '86'). and lengths) T '9F18' L '04' Script ID Identifier (4 bytes) Commands (see Figure 15) Figure 14: Issuer Script Format T1 '86' L1 L(V1) V1 Command T2 '86' L2 L(V2) V2 Command T3 '86' L3 L(V3) V3 Command Figure 15: Issuer Script Command Format (Shown with Three Commands) It is possible for multiple Issuer Scripts to be delivered with a single authorisation response. including Script ID. Note: Annex E discusses TVR and TSI bit settings following script processing. Page 126 June 2008 . Each command shall be delivered to the ICC as a command APDU in the sequence in which it appeared in the Issuer Script. the terminal shall set the ‗Script processing was performed‘ bit in the TSI to 1. the terminal shall continue with the next command from the Issuer Script (if any). the processing of the Issuer Script shall be terminated. The Script Identifier is optional and is not interpreted by the terminal.10 Issuer-to-Card Script Processing EMV 4. tags.  If an Issuer Script is processed. If an error occurred in processing a script. If SW1 indicates an ‗error‘ condition.2 Book 3 Application Specification Description: An Issuer Script is a constructed data object (tag '71' or '72') containing (optionally) a Script Identifier and a sequence of Issuer Script Command APDUs to be delivered serially to the ICC. Figure 14 and Figure 15 illustrate an Issuer Script containing a Script Identifier and three commands. the terminal shall set to 1 either the ‗Script processing failed before final GENERATE AC‘ in the TVR if the identifying tag of the failing script was '71' or the ‗Script processing failed after final GENERATE AC‘ in the TVR if the tag was '72'.

Sequence of Execution: The completion function is always the last function in the transaction processing. (Script processing may be performed after the completion function. If the terminal decides to go online. the terminal shall set the ‗CDA signature requested‘ bit in the GENERATE AC command to 1.EMV 4.11 Completion Purpose: The completion function closes processing of a transaction. Conditions of Execution: The terminal always performs this function unless the transaction is terminated prematurely by error processing. June 2008 Page 127 .2 Book 3 Application Specification 10 Functions Used in Transaction Processing 10.11 Completion 10.3). If the terminal is to perform CDA (as described in section 10.) Description: The ICC indicates willingness to complete transaction processing by returning either a TC or an AAC to either the first or second GENERATE AC command issued by the terminal. See section 9 for additional information on the use of the GENERATE AC command. completion shall be done when the second GENERATE AC command is issued.

.

2 Book 3 Application Specification Part IV Annexes June 2008 Page 129 .EMV 4.

EMV 4.2 Book 3 Application Specification Page 130 June 2008 .

coded as specified in Annex G Uniquely identifies the acquirer within each payment system Indicates the data input and output capabilities of the terminal Authorised amount of the transaction (excluding adjustments) Source Terminal Terminal Terminal Format n2 n 6-11 b Template — — — Tag ‗5F57‘ '9F01' '9F40' Length 1 6 5 Terminal b — '81' 4 Table 33: Data Elements Dictionary June 2008 Page 131 .3. The characters used in the ―Format‖ column are described in section 4. A1 Data Elements by Name Name Account Type Acquirer Identifier Additional Terminal Capabilities Amount.EMV 4. Data Element Format Convention. Authorised (Binary) Description Indicates the type of account selected on the terminal. Table 34 lists the data elements in tag sequence.2 Book 3 Application Specification Annex A Data Elements Dictionary Table 33 defines those data elements that may be used for financial transaction interchange and their mapping onto data objects and files.

Other (Numeric) Amount. Reference Currency Application Cryptogram Application Currency Code Application Currency Exponent Application Discretionary Data Application Effective Date Description Authorised amount of the transaction (excluding adjustments) Secondary amount associated with the transaction representing a cashback amount Secondary amount associated with the transaction representing a cashback amount Authorised amount expressed in the reference currency Cryptogram returned by the ICC in response of the GENERATE AC command Indicates the currency in which the account is managed according to ISO 4217 Indicates the implied position of the decimal point from the right of the amount represented according to ISO 4217 Issuer or payment system specified data relating to the application Date from which the application may be used Source Terminal Format n 12 Template — Tag '9F02' Length 6 Terminal Terminal Terminal b n 12 b — — — '9F04' '9F03' '9F3A' 4 6 4 ICC ICC ICC b n3 n1 '77' or '80' '70' or '77' '70' or '77' '9F26' '9F42' '9F44' 8 2 1 ICC b '70' or '77' '9F05' 1-32 ICC n6 YYMMDD '70' or '77' '5F25' 3 Table 33: Data Elements Dictionary.2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name Amount.EMV 4. Other (Binary) Amount. Authorised (Numeric) Amount. continued June 2008 Page 132 .

up to 10 Table 33: Data Elements Dictionary.2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name Application Expiration Date Application File Locator (AFL) Application Identifier (AID) – card Application Identifier (AID) – terminal Application Interchange Profile Application Label Description Date after which application expires Indicates the location (SFI.3) cn var. b Template '70' or '77' '77' or '80' '61' Tag '5F24' '94' '4F' Length 3 var. range of records) of the AEFs related to a given application Identifies the application as described in ISO/IEC 7816-5 Identifies the application as described in ISO/IEC 7816-5 Indicates the capabilities of the card to support specific functions in the application Mnemonic associated with the AID according to ISO/IEC 7816-5 Source ICC ICC ICC Format n6 YYMMDD var.EMV 4. up to 252 5-16 Terminal b — '9F06' 5-16 ICC b '77' or '80' '82' 2 ICC ans with the special character limited to space ans (see section 4. continued June 2008 Page 133 . up to 19 '61' or 'A5' '50' 1-16 Application Preferred Name Application Primary Account Number (PAN) Preferred mnemonic associated with the AID ICC '61' or 'A5' '9F12' 1-16 Valid cardholder account number ICC '70' or '77' '5A' var.

EMV 4. continued June 2008 Page 134 . for each of the 1-4 reference currencies represented according to ISO 4217 ICC b '61' or 'A5' '87' 1 ICC n3 '70' or '77' '9F3B' 2-8 Application Reference Currency Exponent ICC n1 '70' or '77' '9F43' 1-4 Table 33: Data Elements Dictionary.2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name Application Primary Account Number (PAN) Sequence Number Application Priority Indicator Application Reference Currency Description Identifies and differentiates cards with the same PAN Source ICC Format n2 Template '70' or '77' Tag '5F34' Length 1 Indicates the priority of a given application or group of applications in a directory 1-4 currency codes used between the terminal and the ICC when the Transaction Currency Code is different from the Application Currency Code. each code is 3 digits according to ISO 4217 Indicates the implied position of the decimal point from the right of the amount.

up to 252 2 ICC b '77' or '80' '9F36' ICC b '70' or '77' '9F07' 2 ICC Terminal b b '70' or '77' — '9F08' '9F09' 2 2 Table 33: Data Elements Dictionary. including the length of the AID. continued June 2008 Page 135 .2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name Application Selection Indicator Description For an application in the ICC to be supported by an application in the terminal. The data is not sent across the interface b Template — Tag — Length See format Application Template Application Transaction Counter (ATC) Application Usage Control Application Version Number Application Version Number Contains one or more data objects relevant to an application directory entry according to ISO/IEC 7816-5 Counter maintained by the application in the ICC (incrementing the ATC is managed by the ICC) Indicates issuer‘s specified restrictions on the geographic usage and services allowed for the application Version number assigned by the payment system for the application Version number assigned by the payment system for the application ICC '70' '61' var. 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 Source Terminal Format At the discretion of the terminal. the Application Selection Indicator indicates whether the associated AID in the terminal must match the AID in the card exactly.EMV 4.

EMV 4. List of data objects (tag and length) to be passed to the ICC in the first GENERATE AC command List of data objects (tag and length) to be passed to the ICC in the second GENERATE AC command Issuer/ Terminal Issuer — — '8A' — 2 4 or 8 ICC ICC var.2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name Authorisation Code Description Value generated by the authorisation authority for an approved transaction Source Issuer Format As defined by the Payment Systems an 2 b Template — Tag '89' Length 6 Authorisation Response Code Authorisation Response Cryptogram (ARPC) Bank Identifier Code (BIC) Card Risk Management Data Object List 1 (CDOL1) Card Risk Management Data Object List 2 (CDOL2) Code that defines the disposition of a message Cryptogram generated by the issuer and used by the card to verify that the response came from the issuer. b 'BF0C' or '73' '70' or '77' '5F54' '8C' 8 or 11 var. up to 252 Table 33: Data Elements Dictionary. continued June 2008 Page 136 . Uniquely identifies a bank as defined in ISO 9362. up to 252 ICC b '70' or '77' '8D' var.

Indicates cardholder name according to ISO 7813 Indicates the whole cardholder name when greater than 26 characters using the same coding convention as in ISO 7813 Identifies a method of verification of the cardholder supported by the application Source Issuer Format b Template — Tag — Length 4 Cardholder Name Cardholder Name Extended Cardholder Verification Method (CVM) List Cardholder Verification Method (CVM) Results Certification Authority Public Key Check Sum ICC ICC ans 2-26 ans 27-45 '70' or '77' '70' or '77' '5F20' '9F0B' 2-26 27-45 ICC b '70' or '77' '8E' var. up to 252 Indicates the results of the last CVM performed Terminal b — '9F34' 3 A check value calculated on the concatenation of all parts of the Certification Authority Public Key (RID. Certification Authority Public Key Exponent) using SHA-1 Terminal b — — 20 Table 33: Data Elements Dictionary. Certification Authority Public Key Index.EMV 4.2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name Card Status Update (CSU) Description Contains data sent to the ICC to indicate whether the issuer approves or declines the transaction. Certification Authority Public Key Modulus. Transmitted to the card in Issuer Authentication Data. and to initiate actions specified by the issuer. continued June 2008 Page 137 .

1 Terminal ICC b b — '77' or '80' '83' '9F27' ICC b — '9F45' 2 ICC b '6F' '84' 5-16 Table 33: Data Elements Dictionary.EMV 4. continued June 2008 Page 138 .2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name Certification Authority Public Key Exponent Certification Authority Public Key Index Certification Authority Public Key Index Certification Authority Public Key Modulus Command Template Cryptogram Information Data Data Authentication Code Dedicated File (DF) Name Description Value of the exponent part of the Certification Authority Public Key Identifies the certification authority‘s public key in conjunction with the RID Identifies the certification authority‘s public key in conjunction with the RID Value of the modulus part of the Certification Authority Public Key Identifies the data field of a command message Indicates the type of cryptogram and the actions to be performed by the terminal An issuer assigned value that is retained by the terminal during the verification process of the Signed Static Application Data Identifies the name of the DF as described in ISO/IEC 7816-4 Source Terminal Format b Template — Tag — Length 1 or 3 ICC b '70' or '77' '8F' 1 Terminal b — '9F22' 1 Terminal b — — NCA (up to 248) var.

EMV 4. continued June 2008 Page 139 . TDOL to be used for generating the TC Hash Value if the TDOL in the card is not present Terminal b — — var.2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name Default Dynamic Data Authentication Data Object List (DDOL) Default Transaction Certificate Data Object List (TDOL) Directory Definition File (DDF) Name Directory Discretionary Template Dynamic Data Authentication Data Object List (DDOL) Enciphered Personal Identification Number (PIN) Data Description DDOL to be used for constructing the INTERNAL AUTHENTICATE command if the DDOL in the card is not present Source Terminal Format b Template — Tag — Length var. Identifies the name of a DF associated with a directory Issuer discretionary part of the directory according to ISO/IEC 7816-5 List of data objects (tag and length) to be passed to the ICC in the INTERNAL AUTHENTICATE command Transaction PIN enciphered at the PIN pad for online verification or for offline verification if the PIN pad and IFD are not a single integrated device ICC b '61' '9D' 5-16 ICC var. '61' '73' var. up to 252 up to 252 ICC b '70' or '77' '9F49' Terminal b — — 8 Table 33: Data Elements Dictionary.

up to 252 2-8 NI ICC ICC b b — '70' or '77' '9F4C' '9F2D' Table 33: Data Elements Dictionary. Identifies the FCI template according to ISO/IEC 7816-4 Time-variant number generated by the ICC.2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name File Control Information (FCI) Issuer Discretionary Data File Control Information (FCI) Proprietary Template File Control Information (FCI) Template ICC Dynamic Number Integrated Circuit Card (ICC) PIN Encipherment Public Key Certificate Description Issuer discretionary part of the FCI Source ICC Format var. — '6F' var. up to 222 Identifies the data object proprietary to this specification in the FCI template according to ISO/IEC 7816-4 ICC var. continued June 2008 Page 140 . to be captured by the terminal ICC PIN Encipherment Public Key certified by the issuer ICC var.EMV 4. Template 'A5' Tag 'BF0C' Length var. '6F' 'A5' var.

EMV 4. continued June 2008 Page 141 .2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name Integrated Circuit Card (ICC) PIN Encipherment Public Key Exponent Integrated Circuit Card (ICC) PIN Encipherment Public Key Remainder Integrated Circuit Card (ICC) Public Key Certificate Integrated Circuit Card (ICC) Public Key Exponent Integrated Circuit Card (ICC) Public Key Remainder Description ICC PIN Encipherment Public Key Exponent used for PIN encipherment Source ICC Format b Template '70' or '77' Tag '9F2E' Length 1 or 3 Remaining digits of the ICC PIN Encipherment Public Key Modulus ICC b '70' or '77' '9F2F' NPE  NI + 42 ICC Public Key certified by the issuer ICC b '70' or '77' '9F46' NI ICC Public Key Exponent used for the verification of the Signed Dynamic Application Data Remaining digits of the ICC Public Key Modulus ICC b '70' or '77' '9F47' 1 to 3 ICC b '70' or '77' '9F48' NIC  NI + 42 Table 33: Data Elements Dictionary.

Specifies the issuer‘s conditions that cause a transaction to be rejected if it might have been approved online. Annex C. 'BF0C' or '73' '70' or '77' '5F53' Var. up to 32 Table 33: Data Elements Dictionary.Denial Issuer Action Code .2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name Interface Device (IFD) Serial Number International Bank Account Number (IBAN) Issuer Action Code . To avoid potential conflicts with CCD-compliant applications. continued June 2008 Page 142 .EMV 4. it is strongly recommended that the IAD data element in an application that is not CCD-compliant should not use the coding for a CCD-compliant application Source Terminal Format an 8 Template — Tag '9F1E' Length 8 ICC var. section C7 defines the specific coding of the Issuer Application Data (IAD). up to 34 5 ICC b '9F0D' Issuer Action Code . but the terminal is unable to process the transaction online Specifies the issuer‘s conditions that cause the denial of a transaction without attempt to go online Specifies the issuer‘s conditions that cause a transaction to be transmitted online Contains proprietary application data for transmission to the issuer in an online transaction.Online Issuer Application Data ICC b '70' or '77' '9F0E' 5 ICC ICC b b '70' or '77' '77' or '80' '9F0F' '9F10' 5 var. Note: For CCD-compliant applications.Default Description Unique and permanent serial number assigned to the IFD by the manufacturer Uniquely identifies the account of a customer at a financial institution as defined in ISO 13616.

2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name Issuer Authentication Data Issuer Code Table Index Issuer Country Code Issuer Country Code (alpha2 format) Issuer Country Code (alpha3 format) Issuer Identification Number (IIN) Issuer Public Key Certificate Issuer Public Key Exponent Description Data sent to the ICC for online issuer authentication Indicates the code table according to ISO/IEC 8859 for displaying the Application Preferred Name Indicates the country of the issuer according to ISO 3166 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) Issuer public key certified by a certification authority Issuer public key exponent used for the verification of the Signed Static Application Data and the ICC Public Key Certificate Source Issuer Format b Template — Tag '91' Length 8-16 ICC n2 'A5' '9F11' 1 ICC ICC n3 a2 '70' or '77' 'BF0C' or '73' 'BF0C' or '73' 'BF0C' or '73' '70' or '77' '70' or '77' '5F28' '5F55' 2 2 ICC a3 '5F56' 3 ICC n6 '42' 3 ICC ICC b b '90' '9F32' NCA 1 to 3 Table 33: Data Elements Dictionary. continued June 2008 Page 143 .EMV 4.

but that terminals accept the data element whether it is coded in upper or lower case. 2-8 Table 33: Data Elements Dictionary. Issuer Issuer Terminal Issuer b b b b '71' or '72' '71' or '72' — — '86' '9F18' — '71' Issuer b — '72' var. ICC ICC ans an 2 'BF0C' or '73' 'A5' '5F50' '5F2D' var. 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.EMV 4. var. continued June 2008 Page 144 . up to 261 4 var. 1-4 languages stored in order of preference.2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name Issuer Public Key Remainder Issuer Script Command Issuer Script Identifier Issuer Script Results Issuer Script Template 1 Issuer Script Template 2 Issuer URL Language Preference Description Remaining digits of the Issuer Public Key Modulus Contains a command for transmission to the ICC Identification of the Issuer Script Indicates the result of the terminal script processing Contains proprietary issuer data for transmission to the ICC before the second GENERATE AC command Contains proprietary issuer data for transmission to the ICC after the second GENERATE AC command The URL provides the location of the Issuer‘s Library Server on the Internet. Source ICC Format b Template '70' or '77' Tag '92' Length NI  NCA + 36 var.

represented according to ISO 8583:1993 for Card Acceptor Business Code Terminal n4 — '9F15' 2 Table 33: Data Elements Dictionary. continued June 2008 Page 145 .2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name Last Online Application Transaction Counter (ATC) Register Log Entry Log Format Description ATC value of the last transaction that went online Source ICC Format b Template — Tag '9F13' Length 2 Provides the SFI of the Transaction Log file and its number of records List (in tag and length format) of data objects representing the logged data elements that are passed to the terminal when a transaction log record is read Issuer-specified preference for the maximum number of consecutive offline transactions for this ICC application allowed in a terminal with online capability Value used in terminal risk management for random transaction selection ICC ICC b b 'BF0C' or '73' — '9F4D' '9F4F' 2 var.EMV 4. Lower Consecutive Offline Limit Maximum Target Percentage to be used for Biased Random Selection Merchant Category Code ICC b '70' or '77' '9F14' 1 Terminal — — — — Classifies the type of business being done by the merchant.

continued June 2008 Page 146 . up to 8 Table 33: Data Elements Dictionary. according to the first two digits of the ISO 8583:1987 POS Entry Mode Contains a list of terminal resident data objects (tags and lengths) needed by the ICC in processing the GET PROCESSING OPTIONS command Contains issuer data for transmission to the card in the Issuer Authentication Data of an online transaction. 1 — ICC b — '9F17' 1 Indicates the method by which the PAN was entered.EMV 4. uniquely identifies a given merchant Indicates the name and location of the merchant Indicates whether the batch data capture record is a financial record or advice Secret key of a symmetric algorithm used by the PIN pad to encipher the PIN and by the card reader to decipher the PIN if the PIN pad and card reader are not integrated Number of PIN tries remaining Source Terminal Terminal Terminal Terminal Format ans 15 ans n2 — Template — — — — Tag '9F16' '9F4E' — — Length 15 var. Terminal n2 — '9F39' 1 ICC b 'A5' '9F38' var.2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name Merchant Identifier Merchant Name and Location Message Type Personal Identification Number (PIN) Pad Secret Key Personal Identification Number (PIN) Try Counter Point-of-Service (POS) Entry Mode Processing Options Data Object List (PDOL) Proprietary Authentication Data Description When concatenated with the Acquirer Identifier. Issuer b — — var.

up to 252 ICC var. Template — Tag '70' Length var. — '77' var. (Mandatory for SFIs 1-10. but may use template '70') Contains the data objects (without tags and lengths) returned by the ICC in response to a command Contains the data objects (with tags and lengths) returned by the ICC in response to a command Service code as defined in ISO/IEC 7813 for track 1 and track 2 Identifies the AEF referenced in commands related to a given ADF or DDF. Response messages for SFIs 11-30 are outside the scope of EMV. Digital signature on critical application parameters for DDA or CDA Digital signature on critical application parameters for SDA Source ICC Format var. — '80' var. continued June 2008 Page 147 . ICC ICC n3 b '70' or '77' 'A5' '5F30' '88' 2 1 Signed Dynamic Application Data Signed Static Application Data ICC ICC b b — '70' or '77' '9F4B' '93' NIC NI Table 33: Data Elements Dictionary.2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name READ RECORD Response Message Template Response Message Template Format 1 Response Message Template Format 2 Service Code Short File Identifier (SFI) Description Contains the contents of the record read. It is a binary data object having a value in the range 1 to 30 and with the three high order bits set to zero. ICC var.EMV 4.

but the terminal is unable to process the transaction online Specifies the acquirer‘s conditions that cause the denial of a transaction without attempt to go online Specifies the acquirer‘s conditions that cause a transaction to be transmitted online Indicates the card data input. continued June 2008 Page 148 .Default Description List of tags of primitive data objects defined in this specification whose value fields are to be included in the Signed Static or Dynamic Application Data Value used in terminal risk management for random transaction selection Source ICC Format — Template '70' or '77' Tag '9F4A' Length var.2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name Static Data Authentication Tag List Target Percentage to be Used for Random Selection Terminal Action Code .EMV 4. represented according to ISO 3166 Indicates the floor limit in the terminal in conjunction with the AID Terminal b — — 5 Terminal Action Code . CVM. Terminal — — — — Specifies the acquirer‘s conditions that cause a transaction to be rejected if it might have been approved online. and security capabilities of the terminal Indicates the country of the terminal.Denial Terminal Action Code .Online Terminal Capabilities Terminal Country Code Terminal Floor Limit Terminal b — — 5 Terminal Terminal Terminal Terminal b b n3 b — — — — — '9F33' '9F1A' '9F1B' 5 3 2 4 Table 33: Data Elements Dictionary.

and its operational control Status of the different functions as seen from the terminal Value used in terminal risk management for random transaction selection Source Terminal Terminal Format an 8 b Template — — Tag '9F1C' '9F1D' Length 8 1-8 Terminal n2 — '9F35' 1 Terminal Verification Results Threshold Value for Biased Random Selection Track 1 Discretionary Data Track 2 Discretionary Data Terminal b — '95' 5 Terminal — — — — Discretionary part of track 1 according to ISO/IEC 7813 Discretionary part of track 2 according to ISO/IEC 7813 ICC ans '70' or '77' '9F1F' var.2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name Terminal Identification Terminal Risk Management Data Terminal Type Description Designates the unique location of a terminal at a merchant Application-specific value used by the card for risk management purposes Indicates the environment of the terminal. continued June 2008 Page 149 . ICC cn '70' or '77' '9F20' var.EMV 4. its communications capability. Table 33: Data Elements Dictionary.

b Terminal ICC n 12 b — '70' or '77' — '97' 6 var.1 Terminal b — '98' 20 Table 33: Data Elements Dictionary. var. as follows: Primary Account Number Field Separator (Hex 'D') Expiration Date (YYMM) Service Code Discretionary Data (defined by individual payment systems) Pad with one Hex 'F' if needed to ensure whole bytes Source ICC Format b Template '70' or '77' Tag '57' Length var. and Longitudinal Redundancy Check (LRC). continued June 2008 Page 150 . Annex B3. end sentinel. up to 19 n. including tips and other adjustments List of data objects (tag and length) to be used by the terminal in generating the TC Hash Value Result of a hash function specified in Book 2. excluding start sentinel.2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name Track 2 Equivalent Data Description Contains the data elements of track 2 according to ISO/IEC 7813.EMV 4. var. up to 252 Transaction Amount Transaction Certificate Data Object List (TDOL) Transaction Certificate (TC) Hash Value Clearing amount of the transaction. up to 19 b n4 n3 n.

continued June 2008 Page 151 .EMV 4. Code defining the common currency used by the terminal in case the Transaction Currency Code is different from the Application Currency Code Factor used in the conversion from the Transaction Currency Code to the Transaction Reference Currency Code Indicates the implied position of the decimal point from the right of the transaction amount. with the Transaction Reference Currency Code represented according to ISO 4217 Terminal n3 — '9F3C' 2 Terminal n8 — — 4 Terminal n1 — '9F3D' 1 Table 33: Data Elements Dictionary.2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name Transaction Currency Code Transaction Currency Exponent Transaction Date Transaction Personal Identification Number (PIN) Data Transaction Reference Currency Code Transaction Reference Currency Conversion Transaction Reference Currency Exponent Description Indicates the currency code of the transaction according to ISO 4217 Indicates the implied position of the decimal point from the right of the transaction amount represented according to ISO 4217 Local date that the transaction was authorised Data entered by the cardholder for the purpose of the PIN verification Source Terminal Terminal Format n3 n1 Template — — Tag '5F2A' '5F36' Length 2 1 Terminal Terminal n6 YYMMDD b — — '9A' '99' 3 var.

represented by the first two digits of the ISO 8583:1987 Processing Code.EMV 4.2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name Name Transaction Sequence Counter Transaction Status Information Transaction Time Transaction Type Description Counter maintained by the terminal that is incremented by one for each transaction Indicates the functions performed in a transaction Local time that the transaction was authorised Indicates the type of financial transaction. continued June 2008 Page 152 . The actual values to be used for the Transaction Type data element are defined by the relevant payment system Value to provide variability and uniqueness to the generation of a cryptogram Issuer-specified preference for the maximum number of consecutive offline transactions for this ICC application allowed in a terminal without online capability Source Terminal Format n 4-8 Template — Tag '9F41' Length 2-4 Terminal b — '9B' 2 Terminal Terminal n6 HHMMSS n2 — — '9F21' '9C' 3 1 Unpredictable Number Upper Consecutive Offline Limit Terminal ICC b b — '70' or '77' '9F37' '9F23' 4 1 Table 33: Data Elements Dictionary.

it shall always be passed in order from high order to low order. June 2008 Page 153 . The same rule applies when concatenating data. A data element in format cn is left justified and padded with trailing hexadecimal 'F's. card to terminal). regardless of how it is internally stored. When data is moved from one entity to another (for example. A data element in format a. an.2 Book 3 Application Specification Annex A Data Elements Dictionary A1 Data Elements by Name When the length defined for the data object is greater than the length of the actual data. Note: Data that can occur in template '70' or '77' can never occur in both.EMV 4. the following rules apply:    A data element in format n is right justified and padded with leading hexadecimal zeroes. or ans is left justified and padded with trailing hexadecimal zeroes.

2 Book 3 Application Specification A2 Data Elements by Tag Name Issuer Identification Number (IIN) Application Identifier (AID) .card Application Label Track 2 Equivalent Data Application Primary Account Number (PAN) Cardholder Name Application Expiration Date Application Effective Date Issuer Country Code Transaction Currency Code Language Preference Service Code Application Primary Account Number (PAN) Sequence Number Transaction Currency Exponent 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 Table 34: Data Elements Tags Template 'BF0C' or '73' '61' '61' or 'A5' '70' or '77' '70' or '77' '70' or '77' '70' or '77' '70' or '77' '70' or '77' — 'A5' '70' or '77' '70' or '77' — 'BF0C' or '73' 'BF0C' or '73' 'BF0C' or '73' 'BF0C' or '73' 'BF0C' or '73' '70' or '77' — Tag '42' '4F' '50' '57' '5A' '5F20' '5F24' '5F25' '5F28' '5F2A' '5F2D' '5F30' '5F34' '5F36' '5F50' '5F53' '5F54' '5F55' '5F56' '61' '6F' Page 154 June 2008 .Annex A Data Elements Dictionary A2 Data Elements by Tag EMV 4.

2 Book 3 Application Specification Annex A Data Elements Dictionary A2 Data Elements by Tag Name READ RECORD Response Message Template Issuer Script Template 1 Issuer Script Template 2 Directory Discretionary Template Response Message Template Format 2 Response Message Template Format 1 Amount. continued June 2008 Page 155 .EMV 4. Authorised (Binary) Application Interchange Profile Command Template Dedicated File (DF) Name Issuer Script Command Application Priority Indicator Short File Identifier (SFI) Authorisation Code Authorisation Response Code Card Risk Management Data Object List 1 (CDOL1) Card Risk Management Data Object List 2 (CDOL2) Cardholder Verification Method (CVM) List Certification Authority Public Key Index Issuer Public Key Certificate Issuer Authentication Data Issuer Public Key Remainder Signed Static Application Data Application File Locator (AFL) Terminal Verification Results Transaction Certificate Data Object List (TDOL) Transaction Certificate (TC) Hash Value Transaction Personal Identification Number (PIN) Data Template — — — '61' — — — '77' or '80' — '6F' '71' or '72' '61' or 'A5' 'A5' — — '70' or '77' '70' or '77' '70' or '77' '70' or '77' '70' or '77' — '70' or '77' '70' or '77' '77' or '80' — '70' or '77' — — Tag '70' '71' '72' '73' '77' '80' '81' '82' '83' '84' '86' '87' '88' '89' '8A' '8C' '8D' '8E' '8F' '90' '91' '92' '93' '94' '95' '97' '98' '99' Table 34: Data Elements Tags.

Other (Binary) Application Discretionary Data Application Identifier (AID) .Default Issuer Action Code . Other (Numeric) Amount. continued Page 156 June 2008 .Online Issuer Application Data Issuer Code Table Index Application Preferred Name Last Online Application Transaction Counter (ATC) Register Lower Consecutive Offline Limit Merchant Category Code Merchant Identifier Personal Identification Number (PIN) Try Counter Issuer Script Identifier Template — — — '61' — — — — '70' or '77' — '70' or '77' '70' or '77' — '70' or '77' '70' or '77' '70' or '77' '70' or '77' '77' or '80' 'A5' '61' or 'A5' — '70' or '77' — — — '71' or '72' Tag '9A' '9B' '9C' '9D' '9F01' '9F02' '9F03' '9F04' '9F05' '9F06' '9F07' '9F08' '9F09' '9F0B' '9F0D' '9F0E' '9F0F' '9F10' '9F11' '9F12' '9F13' '9F14' '9F15' '9F16' '9F17' '9F18' Table 34: Data Elements Tags.Annex A Data Elements Dictionary A2 Data Elements by Tag EMV 4. Authorised (Numeric) Amount.terminal Application Usage Control Application Version Number Application Version Number Cardholder Name Extended Issuer Action Code .Denial Issuer Action Code .2 Book 3 Application Specification Name Transaction Date Transaction Status Information Transaction Type Directory Definition File (DDF) Name Acquirer Identifier Amount.

EMV 4.2 Book 3 Application Specification Annex A Data Elements Dictionary A2 Data Elements by Tag Name Terminal Country Code Terminal Floor Limit Terminal Identification Terminal Risk Management Data Interface Device (IFD) Serial Number Track 1 Discretionary Data Track 2 Discretionary Data Transaction Time Certification Authority Public Key Index Upper Consecutive Offline Limit Application Cryptogram Cryptogram Information Data ICC PIN Encipherment Public Key Certificate ICC PIN Encipherment Public Key Exponent ICC PIN Encipherment Public Key Remainder Issuer Public Key Exponent Terminal Capabilities Cardholder Verification Method (CVM) Results Terminal Type Application Transaction Counter (ATC) Unpredictable Number Processing Options Data Object List (PDOL) Point-of-Service (POS) Entry Mode Amount. continued June 2008 Page 157 . Reference Currency Application Reference Currency Transaction Reference Currency Code Transaction Reference Currency Exponent Additional Terminal Capabilities Transaction Sequence Counter Template — — — — — '70' or '77' '70' or '77' — — '70' or '77' '77' or '80' '77' or '80' '70' or '77' '70' or '77' '70' or '77' '70' or '77' — — — '77' or '80' — 'A5' — — '70' or '77' — — — — Tag '9F1A' '9F1B' '9F1C' '9F1D' '9F1E' '9F1F' '9F20' '9F21' '9F22' '9F23' '9F26' '9F27' '9F2D' '9F2E' '9F2F' '9F32' '9F33' '9F34' '9F35' '9F36' '9F37' '9F38' '9F39' '9F3A' '9F3B' '9F3C' '9F3D' '9F40' '9F41' Table 34: Data Elements Tags.

2 Book 3 Application Specification Name Application Currency Code Application Reference Currency Exponent Application Currency Exponent Data Authentication Code ICC Public Key Certificate ICC Public Key Exponent ICC Public Key Remainder Dynamic Data Authentication Data Object List (DDOL) Static Data Authentication Tag List Signed Dynamic Application Data ICC Dynamic Number Log Entry Merchant Name and Location Log Format File Control Information (FCI) Proprietary Template File Control Information (FCI) Issuer Discretionary Data Template '70' or '77' '70' or '77' '70' or '77' — '70' or '77' '70' or '77' '70' or '77' '70' or '77' '70' or '77' — — 'BF0C' or '73' — — '6F' 'A5' Tag '9F42' '9F43' '9F44' '9F45' '9F46' '9F47' '9F48' '9F49' '9F4A' '9F4B' '9F4C' '9F4D' '9F4E' '9F4F' 'A5' 'BF0C' Table 34: Data Elements Tags. continued Page 158 June 2008 .Annex A Data Elements Dictionary A2 Data Elements by Tag EMV 4.

2 Book 3 Application Specification Annex A Data Elements Dictionary A2 Data Elements by Tag June 2008 Page 159 .EMV 4.

.

The length field of the data objects described in this specification which are transmitted over the card-terminal interface is coded on one or two bytes. a type. Note: Three length bytes may be used if needed for templates '71' and '72' and tag '86' (to express length greater than 255 bytes). a BER-TLV data object consists of 2-3 consecutive fields:  The tag field (T) consists of one or more consecutive bytes. It indicates a class.EMV 4.2 Book 3 Application Specification Annex B Rules for BER-TLV Data Objects As defined in ISO/IEC 8825. A primitive data object where the value field contains a data element for financial transaction interchange. If L = '00'. A BER-TLV data object belongs to one of the following two categories:   The coding of BER-TLV data objects is defined as follows. A constructed data object where the value field contains one or more primitive or constructed data objects. It indicates the length of the following field. as they are not transmitted over the card-terminal interface. The tag field of the data objects described in this specification is coded on one or two bytes. June 2008 Page 161 . The value field of a constructed data object is called a template. and a number (see Table 35). the value field is not present.   The value field (V) indicates the value of the data object. The length field (L) consists of one or more consecutive bytes.

between. due to erased or modified TLV-coded data objects). or after TLV-coded data objects.2 Book 3 Application Specification B1 Coding of the Tag Field of BER-TLV Data Objects Table 35 describes the first byte of the tag field of a BER-TLV data object: b8 0 0 1 1 b7 0 1 0 1 0 1 1 1 1 1 1 Any other value <31 b6 b5 b4 b3 b2 b1 Meaning Universal class Application class Context-specific class Private class Primitive data object Constructed data object See subsequent bytes Tag number Table 35: Tag Field Structure (First Byte) BER-TLV According to ISO/IEC 8825.Annex B Rules for BER-TLV Data Objects B1 Coding of the Tag Field of BER-TLV Data Objects EMV 4. Table 36 defines the coding rules of the subsequent bytes of a BER-TLV tag when tag numbers  31 are used (that is. b8 1 0 Any value > 0 b7 b6 b5 b4 b3 b2 b1 Last tag byte (Part of) tag number Meaning Another byte follows Table 36: Tag Field Structure (Subsequent Bytes) BER-TLV Before. '00' or 'FF' bytes without any meaning may occur (for example. bits b5 . Page 162 June 2008 .b1 of the first byte equal '11111').

the subsequent bits b7 to b1 of the most significant byte code the number of subsequent bytes in the length field. the length field consists of only one byte.2 Book 3 Application Specification Annex B Rules for BER-TLV Data Objects B2 Coding of the Length Field of BER-TLV Data Objects The tag field of a BER-TLV data object is coded according to the following rules:   The following application class templates defined in ISO/IEC 7816 apply: '61' and '6F'. Two bytes are necessary to express up to 255 bytes in the value field. June 2008 Page 163 . The coding of primitive and constructed private class data objects is left to the discretion of the issuer. and '7E' are defined in ISO/IEC 7816-6 and are not used in this specification. The application class data objects defined in ISO/IEC 7816 and described in Part II are used according to the ISO/IEC 7816 definition. The meaning is then specific to the context of an application according to this specification. The following range of application class templates is defined in Part II: '70' to '7F'. The subsequent bytes code an integer representing the number of bytes in the value field. When bit b8 of the most significant byte of the length field is set to 1. '7D'. Context-specific class data objects are defined in the context of this specification or in the context of the template in which they appear. Tags '78'. Bits b7 to b1 code the number of bytes of the value field. The coding of primitive context-specific class data objects in the ranges '80' to '9E' and '9F00' to '9F4F' is reserved for this specification.      B2 Coding of the Length Field of BER-TLV Data Objects When bit b8 of the most significant byte of the length field is set to 0. '79'.EMV 4. The length field is within the range 1 to 127. The coding of primitive context-specific class data objects in the range '9F50' to '9F7F' is reserved for the payment systems.

.. Primitive or constructed BER-TLV data object number n Figure 17: Constructed BER-TLV Data Object Page 164 June 2008 . A primitive data object is structured as illustrated in Figure 16: Tag (T) Length (L) Value (V) Figure 16: Primitive BER-TLV Data Object (Data Element) A constructed BER-TLV data object consists of a tag. a length. A data element is the smallest data field that receives an identifier (a tag).2 Book 3 Application Specification B3 Coding of the Value Field of Data Objects A data element is the value field (V) of a primitive BER-TLV data object. A constructed data object is structured as illustrated in Figure 17: Tag (T) Length (L) Primitive or constructed BER-TLV data object number 1 . A record in an AEF governed by this specification is a constructed BER-TLV data object.Annex B Rules for BER-TLV Data Objects B3 Coding of the Value Field of Data Objects EMV 4. and a value field composed of one or more BER-TLV data objects.

2 Book 3 Application Specification Annex C Coding of Data Elements Used in Transaction Processing This annex provides the coding for dynamic card data elements and specific data elements used to control the transaction flow in the terminal or to record the status of processing for the transaction. An ‗x‘ means that the bit does not apply. the corresponding ‗Meaning‘ applies.EMV 4. Data (bytes or bits) indicated as RFU shall be set to 0. In the tables:   A ‗1‘ means that if that bit has the value 1. June 2008 Page 165 .

Annex C Coding Data Elements Used in Trans Processing C1 Application Interchange Profile EMV 4.2 Book 3 Application Specification C1 Application Interchange Profile AIP Byte 1 (Leftmost) b8 0 x x x x x x x b7 x 1 x x x x x x b6 x x 1 x x x x x b5 x x x 1 x x x x b4 x x x x 1 x x x b3 x x x x x 1 x x b2 x x x x x x 0 x b1 x x x x x x x 1 RFU SDA supported DDA supported Cardholder verification is supported Terminal risk management is to be performed Issuer authentication is supported 20 RFU CDA supported Meaning AIP Byte 2 (Rightmost) b8 0 x x x x x x x b7 x 0 x x x x x x b6 x x 0 x x x x x b5 x x x 0 x x x x b4 x x x x 0 x x x b3 x x x x x 0 x x b2 x x x x x x 0 x b1 x x x x x x x 0 RFU RFU RFU RFU RFU RFU RFU RFU Meaning Table 37: Application Interchange Profile When this bit is set to 1. Issuer Authentication using the EXTERNAL AUTHENTICATE command is supported 20 Page 166 June 2008 .

EMV 4.2 Book 3 Application Specification Annex C Coding Data Elements Used in Trans Processing C2 Application Usage Control C2 Application Usage Control Application Usage Control Byte 1 (Leftmost) b8 1 x x x x x x x b7 x 1 x x x x x x b6 x x 1 x x x x x b5 x x x 1 x x x x b4 x x x x 1 x x x b3 x x x x x 1 x x b2 x x x x x x 1 x b1 x x x x x x x 1 Meaning Valid for domestic cash transactions Valid for international cash transactions Valid for domestic goods Valid for international goods Valid for domestic services Valid for international services Valid at ATMs Valid at terminals other than ATMs Application Usage Control Byte 2 (Rightmost) b8 1 x x x x x x x b7 x 1 x x x x x x b6 x x 0 x x x x x b5 x x x 0 x x x x b4 x x x x 0 x x x b3 x x x x x 0 x x b2 x x x x x x 0 x b1 x x x x x x x 0 Meaning Domestic cashback allowed International cashback allowed RFU RFU RFU RFU RFU RFU Table 38: Application Usage Control June 2008 Page 167 .

Annex C Coding Data Elements Used in Trans Processing C3 Cardholder Verification Rule Format EMV 4.2 Book 3 Application Specification C3 Cardholder Verification Rule Format CV Rule Byte 1 (Leftmost): Cardholder Verification Method (CVM) Codes b8 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 0 1 b7 b6 b5 b4 b3 b2 b1 RFU Fail cardholder verification if this CVM is unsuccessful Apply succeeding CV Rule if this CVM is unsuccessful Fail CVM processing Plaintext PIN verification performed by ICC Enciphered PIN verified online Plaintext PIN verification performed by ICC and signature (paper) Enciphered PIN verification performed by ICC Enciphered PIN verification performed by ICC and signature (paper) Values in the range 000110-011101 reserved for future use by this specification Signature (paper) No CVM required Values in the range 100000-101111 reserved for use by the individual payment systems Values in the range 110000-111110 reserved for use by the issuer This value is not available for use Meaning 0 0 0 0 0 0 1 1 0 0 0 1 0 x x x x x 0 0 1 1 1 0 1 1 x 1 1 x 1 1 x 0 1 x 1 1 1 1 x 1 x 1 x 1 x 1 Table 39: CVM Codes Page 168 June 2008 .

Meaning 21 22 Support for a CVM is described in EMV Book 4. please refer to EMVCo General Bulletin No.'FF' Always If unattended cash If not unattended cash and not manual cash and not purchase with cashback If terminal supports the CVM 21 If manual cash If purchase with cashback If transaction is in the application currency 22 and is under X value (see section 10..3. That is. and '05'.5 for a discussion of ―X‖) If transaction is in the application currency and is over X value If transaction is in the application currency and is under Y value (see section 10.4 first paragraph.2 Book 3 Application Specification Annex C Coding Data Elements Used in Trans Processing C3 Cardholder Verification Rule Format CV Rule Byte 2 (Rightmost): Cardholder Verification Method (CVM) Condition Codes Value '00' '01' '02' '03' '04' '05' '06' '07' '08' '09' '0A' . Transaction Currency Code = Application Currency Code.5 for a discussion of ―Y‖) If transaction is in the application currency and is over Y value RFU Reserved for use by individual payment systems Table 40: CVM Condition Codes Note: For Condition Codes '01'.'7F' '80' . 14 . '04'.EMV 4.Migration Schedule for New CVM Condition Codes. Section 6. June 2008 Page 169 .

Annex C Coding Data Elements Used in Trans Processing C4 Issuer Code Table Index EMV 4.2 Book 3 Application Specification C4 Issuer Code Table Index Value '01' '02' '03' '04' '05' '06' '07' '08' '09' '10' Refers to Part 1 of ISO/IEC 8859 Part 2 of ISO/IEC 8859 Part 3 of ISO/IEC 8859 Part 4 of ISO/IEC 8859 Part 5 of ISO/IEC 8859 Part 6 of ISO/IEC 8859 Part 7 of ISO/IEC 8859 Part 8 of ISO/IEC 8859 Part 9 of ISO/IEC 8859 Part 10 of ISO/IEC 8859 Table 41: Issuer Code Table Index Page 170 June 2008 .

2 Book 3 Application Specification Annex C Coding Data Elements Used in Trans Processing C5 Terminal Verification Results C5 b8 1 x x x x x x x Terminal Verification Results b7 x 1 x x x x x x b6 x x 1 x x x x x b5 x x x 1 x x x x b4 x x x x 1 x x x b3 x x x x x 1 x x b2 x x x x x x 0 x b1 x x x x x x x 0 Meaning Offline data authentication was not performed SDA failed ICC data missing Card appears on terminal exception file 23 DDA failed CDA failed RFU RFU TVR Byte 1: (Leftmost) TVR Byte 2: b8 1 x x x x x x x b7 x 1 x x x x x x b6 x x 1 x x x x x b5 x x x 1 x x x x b4 x x x x 1 x x x b3 x x x x x 0 x x b2 x x x x x x 0 x b1 x x x x x x x 0 Meaning ICC and terminal have different application versions Expired application Application not yet effective Requested service not allowed for card product New card RFU RFU RFU Table 42: Terminal Verification Results There is no requirement in this specification for an exception file. but it is recognised that some terminals may have this capability. 23 June 2008 Page 171 .EMV 4.

PIN pad present. but PIN was not entered Online PIN entered RFU RFU TVR Byte 4: b8 1 x x x x x x x b7 x 1 x x x x x x b6 x x 1 x x x x x b5 x x x 1 x x x x b4 x x x x 1 x x x b3 x x x x x 0 x x b2 x x x x x x 0 x b1 x x x x x x x 0 Meaning Transaction exceeds floor limit Lower consecutive offline limit exceeded Upper consecutive offline limit exceeded Transaction selected randomly for online processing Merchant forced transaction online RFU RFU RFU Table 42: Terminal Verification Results. continued Page 172 June 2008 .Annex C Coding Data Elements Used in Trans Processing C5 Terminal Verification Results EMV 4.2 Book 3 Application Specification TVR Byte 3: b8 1 x x x x x x x b7 x 1 x x x x x x b6 x x 1 x x x x x b5 x x x 1 x x x x b4 x x x x 1 x x x b3 x x x x x 1 x x b2 x x x x x x 0 x b1 x x x x x x x 0 Meaning Cardholder verification was not successful Unrecognised CVM PIN Try Limit exceeded PIN entry required and PIN pad not present or not working PIN entry required.

2 Book 3 Application Specification Annex C Coding Data Elements Used in Trans Processing C5 Terminal Verification Results TVR Byte 5 (Rightmost): b8 1 x x x x x x x b7 x 1 x x x x x x b6 x x 1 x x x x x b5 x x x 1 x x x x b4 x x x x 0 x x x b3 x x x x x 0 x x b2 x x x x x x 0 x b1 x x x x x x x 0 Meaning Default TDOL used Issuer authentication failed Script processing failed before final GENERATE AC Script processing failed after final GENERATE AC RFU RFU RFU RFU Table 42: Terminal Verification Results.EMV 4. continued June 2008 Page 173 .

Annex C Coding Data Elements Used in Trans Processing C6 Transaction Status Information EMV 4.2 Book 3 Application Specification C6 Transaction Status Information TSI Byte 1 (Leftmost): b8 1 x x x x x x x b7 x 1 x x x x x x b6 x x 1 x x x x x b5 x x x 1 x x x x b4 x x x x 1 x x x b3 x x x x x 1 x x b2 x x x x x x 0 x b1 x x x x x x x 0 Meaning Offline data authentication was performed Cardholder verification was performed Card risk management was performed Issuer authentication was performed Terminal risk management was performed Script processing was performed RFU RFU TSI Byte 2 (Rightmost): b8 0 x x x x x x x b7 x 0 x x x x x x b6 x x 0 x x x x x b5 x x x 0 x x x x b4 x x x x 0 x x x b3 x x x x x 0 x x b2 x x x x x x 0 x b1 x x x x x x x 0 RFU RFU RFU RFU RFU RFU RFU RFU Meaning Table 43: Transaction Status Information Page 174 June 2008 .

D3 Sequence of Execution This function may be executed after Application Selection. D2 Conditions of Execution This optional function is intended to be executed by special devices.2 Book 3 Application Specification Annex D Transaction Log Information D1 Purpose Provide support for accessing a transaction log file by special devices.EMV 4. June 2008 Page 175 .

Annex D Transaction Log Information D4 Description EMV 4.11. The file is a cyclic file as defined in ISO/IEC 7816-4.5. the two following data elements are used: Log Entry and Log Format. If the Log Entry data element is not present. The SFI shall be in the range 11 to 30. Record #1 is the most recent transaction. The Transaction Log records shall be accessible using the READ RECORD command as specified in section 6.   Page 176 June 2008 . Each record is a concatenation of the values identified in the Log Format data element. the special device uses the following steps:  Perform Application Selection and retrieve the Log Entry data element located in the FCI Issuer Discretionary Data. The Log Format and the Transaction Log records shall remain accessible when the application is blocked.2 Book 3 Application Specification D4 Description To get the Transaction Log information. The Transaction Log records shall not be designated in the Application File Locator. Issue READ RECORD commands to read the Transaction Log records. Issue a GET DATA command to retrieve the Log Format data element. the application does not support the Transaction Log function. Table 44 describes the format of the Log Entry data element (tag '9F4D'): Byte 1 2 Format b b Length 1 1 Value SFI containing the cyclic transaction log file Maximum number of records in the transaction log file Table 44: Log Entry Devices that read the transaction log use the Log Entry data element to determine the location (SFI) and the maximum number of transaction log records. The records in the file shall not contain the Application Elementary File (AEF) Data Template (tag '70'). Record #2 is the next prior transaction. To read the transaction log information. etc.

EMV 4.2 Book 3 Application Specification

Annex D Transaction Log Information D5 Example

D5

Example

Note that the following data elements are shown for example purposes only. A Log Entry data element equal to '0F14' indicates that the transaction log file is located in SFI 15 ('0F') and contains a maximum of 20 records ('14'). A Log Format data element equal to '9A039F21035F2A029F02069F4E149F3602' indicates that the transaction log records have the following content: Data Content Transaction Date Transaction Time Transaction Currency Code Amount, Authorised Merchant Name and Location Application Transaction Counter Tag '9A' '9F21' '5F2A' '9F02' '9F4E' '9F36' Length 3 3 2 6 20 2

Table 45: Example of Log Format In Table 45, lengths and tags are shown for clarity. They do not appear in the log record which is the concatenation of values (no TLV coding). Data elements listed in the Log Format may come from the terminal and the card. Terminal data elements such as Merchant Name and Location might have been passed to the card in the PDOL or CDOL data.

June 2008

Page 177

Annex D Transaction Log Information D5 Example

EMV 4.2 Book 3 Application Specification

Page 178

June 2008

EMV 4.2 Book 3 Application Specification

Annex E TVR and TSI Bit Settings Following Script Processing
Four possible scenarios can occur when processing a script. These scenarios are described below, together with the expected results in terms of the setting of the appropriate TVR bits, the TSI bit, and the Issuer Script Results. In the following descriptions:   ―TVR bits‖ refers to TVR byte 5 bit 6 and bit 5 (depending on whether it is a tag '71' and/or tag '72' script) as defined in Table 42. ―TSI bit‖ refers to TSI byte 1 bit 3 as defined in Table 43.

The Issuer Script Results are defined in Book 4, Annex A5.

E1

Scenarios

Scenario 1 A script is received, it parses correctly, the commands are sent to the card, and the card returns '9000', '62xx', or '63xx' to all commands received. In this scenario the terminal:    shall set the TSI bit shall not set the TVR bits shall set the first byte of the Issuer Script Results to '2x', ‗Script processing successful‘.

June 2008

Page 179

Annex E TVR and TSI Bit Settings Following Script Processing EMV 4.2 Book 3 E1 Scenarios Application Specification

Scenario 2 A script is received, it parses correctly, the commands are sent to the card, but the card does not return '9000', '62xx', or '63xx' to one of the commands received. In this scenario the terminal:     shall set the TSI bit shall set the appropriate TVR bit(s) shall set the first byte of the Issuer Script Results to '1x', ‗Script processing failed‘ shall send no further commands from that script to the card, even if they exist.

Scenario 3 A script is received, it does not parse correctly, and so no commands are sent to the card. In this scenario the terminal:    shall set the TSI bit shall set the appropriate TVR bit(s) shall set the first byte of the Issuer Script Results to '00', ‗Script not performed‘.

Scenario 4 No script is received. In this scenario the terminal shall set neither the TSI bit nor the TVR bit(s). In this event there will be no Issuer Script Results.

Page 180

June 2008

shall set the TSI bit shall set the TVR bit(s) (as described in Scenarios 2 and 3) if any error occurs shall set the Issuer Script Results as described in Scenarios 1 through 3 for each script on a script-by-script basis shall process all Issuer scripts  If more than one script is received. and shall set the appropriate TVR bits and the TSI bit. If a parsing error occurs after any command has been sent to the card. the terminal shall set the first byte of the Issuer Script Results to '00' and shall set the appropriate TVR bits and the TSI bit.2 Book 3 Annex E TVR and TSI Bit Settings Following Script Processing Application Specification E2 Additional Information E2 Additional Information It is possible. the terminal:     June 2008 Page 181 . that commands may be sent to the card ‗on the fly‘ as a script is parsed. In this event:  If a parsing error occurs before any commands are sent to the card. the terminal shall set the first byte of the Issuer Script Results to '1x'. but not recommended.EMV 4.

2 Book 3 E2 Additional Information Application Specification Page 182 June 2008 .Annex E TVR and TSI Bit Settings Following Script Processing EMV 4.

Table 46: Terminal Action after (First) EXTERNAL AUTHENTICATE Response June 2008 Page 183 . Status '9000' '6300' or any other status except '6985' and '9000' '6985' Explanation Issuer authentication was successful. but in the status returned that it does not). the behaviour of the terminal is indeterminate and it shall either terminate the transaction OR set the ‗Issuer authentication failed‘ bit in the TVR to 1.2 Book 3 Application Specification Annex F Status Words Returned in EXTERNAL AUTHENTICATE The terminal shall issue an EXTERNAL AUTHENTICATE command to the card only if the card indicates in byte 1 bit 3 of the AIP that it supports issuer authentication using the EXTERNAL AUTHENTICATE command. in the event that it does. This condition should never occur. Table 46 explains various status values the terminal may receive in response to the (first) EXTERNAL AUTHENTICATE command issued to the card. and continue with the transaction. ‗Command Not Supported‘. there is a complementary card requirement to this which states that the card shall return status '6985'. The terminal shall set the ‗Issuer authentication failed‘ bit in the TVR to 1.EMV 4. and the action the terminal shall take as a result. Issuer authentication failed and the card is in an error state (it has indicated in the AIP that it supports EXTERNAL AUTHENTICATE.9. and continue with the transaction. As stated in section 10. Terminal Action The terminal shall continue with the transaction. The terminal shall issue only one EXTERNAL AUTHENTICATE command to the card during a transaction. Issuer authentication failed. to the second and any subsequent EXTERNAL AUTHENTICATE commands received during the transaction.

2 Book 3 Application Specification Page 184 June 2008 .Annex F Status Words Returned in EXTERNAL AUTHENTICATE EMV 4.

EMV 4.2 Book 3 Application Specification Annex G Account Type Value 00 10 20 30 All other values RFU Table 47: Account Type Savings Cheque/debit Credit Account Type Default .unspecified June 2008 Page 185 .

Annex G Account Type EMV 4.2 Book 3 Application Specification Page 186 June 2008 .

EMV 4.2 Book 3 Application Specification Part V Common Core Definitions June 2008 Page 187 .

2 Book 3 Application Specification Page 188 June 2008 .EMV 4.

to be used when implementing the Common Core Definitions (CCD). without change. These Common Core Definitions specify a minimum common set of card application implementation options. and data element definitions sufficient to accomplish an EMV transaction. since the Common Core Definitions are supported within the existing EMV requirements. Changed and Added Sections Each section heading below refers to the section in this Book to which the additional requirements apply. June 2008 Page 189 . The text defines requirements for a common core implementation. Terminals certified to be compliant with the existing EMV Specifications will. To be compliant with the Common Core Definitions. card application behaviours.2 Book 3 Application Specification Introduction This Part describes an optional extension to this Book. accept cards implemented according to the Common Core Definitions.EMV 4. or introduces new sections where required. in addition to the requirements already specified in the referenced section of EMV. an implementation shall implement all the additional requirements in the Common Core Definitions Parts of all affected Books.

4.5. the body of the response APDU is a constructed data object with tag equal to '77' of which the value field may contain one or more BER-TLV coded data objects. 6.5. Page 190 June 2008 .5 GENERATE APPLICATION CRYPTOGRAM Command-Response APDUs 6.5. The CCD-compliant application shall indicate that the EXTERNAL AUTHENTICATE command is not supported in EMV applications by setting bit 3 in byte 1 of the AIP to 0.5 Commands 6.2 Book 3 Application Specification Part II .Data Elements and Commands 6 Commands for Financial Transaction 6.4 EXTERNAL AUTHENTICATE Command-Response APDUs 6.5.1 Definition and Scope The CCD-compliant application shall support issuer authentication using the second GENERATE AC command.    GENERATE AC GET PROCESSING OPTIONS INTERNAL AUTHENTICATE Tag '77' Value Response Message Template Format 2 Table CCD 1: Body of Response APDU Structure 6.1 Definition and Scope The CCD-compliant application shall support issuer authentication using the second GENERATE AC command.5.2 Response APDU Format For the following commands used during transaction processing.Common Core Definitions EMV 4.

EMV 4.2 Book 3 Application Specification

Common Core Definitions

6.5.5.3 Data Field Sent in the Command Message CDOL2 shall include tag '8A' (Authorisation Response Code) and tag '91' (Issuer Authentication Data). 6.5.5.4 Data Field Returned in the Response Message The response message shall be a BER-TLV coded constructed data object introduced by tag '77' and contains only the data shown in Table CCD 2. Tag '9F27' '9F36' '9F26' '9F10' Value Cryptogram Information Data Application Transaction Counter Application Cryptogram Issuer Application Data

Table CCD 2: Format 2 GENERATE AC Response Message Data Field The required data elements for the response returned in an envelope as specified for the CDA feature (described in section 6.6 of Book 2) are shown in Book 2 Table CCD 1 and Table CCD 2. The Cryptogram Information Data returned in the GENERATE AC response message is coded according to Table CCD 3: b8 b7 b6 b5 b4 b3 b2 b1 0 0 1 1 0 1 0 1 0 0 0 0 0 0 AAC TC ARQC RFU Payment System-specific cryptogram No advice required No information given Meaning

Table CCD 3: Coding of Cryptogram Information Data

6.5.8 GET PROCESSING OPTIONS Command-Response APDUs
6.5.8.2 Command Message The CCD-compliant application shall not preclude support for PDOL.

June 2008

Page 191

Common Core Definitions

EMV 4.2 Book 3 Application Specification

6.5.8.4 Data Field Returned in the Response Message The response message shall be a BER-TLV coded constructed data object introduced by tag '77' and contains only the data shown in Table CCD 4. Tag '82' '94' Value Application Interchange Profile Application File Locator

Table CCD 4: Format 2 GET PROCESSING OPTIONS Response Message Data Field

6.5.9 INTERNAL AUTHENTICATE Command-Response APDUs
6.5.9.4 Data Field Returned in the Response Message The response message shall be a BER-TLV coded constructed data object introduced by tag '77' and contains only the data shown in Table CCD 5. Tag '9F4B' Value Signed Dynamic Application Data

Table CCD 5: Format 2 Internal Authenticate Response Message Data Field 6.5.12.2 Command Message To allow an issuer to use offline plaintext PIN verification as a possible CVM, a CCD-compliant card shall support the VERIFY command with parameter P2 = ‗80‘ as defined in Book 3, Table 23.

Page 192

June 2008

EMV 4.2 Book 3 Application Specification

Common Core Definitions

Part III - Debit and Credit Application Specification
7 Files for Financial Transaction Interchange
7.3 Data Retrievable by GET DATA Command
The ICC shall support the GET DATA command for retrieval of the primitive data object with tag '9F17' (PIN Try Counter).

June 2008

Page 193

Common Core Definitions

EMV 4.2 Book 3 Application Specification

9 GENERATE AC Command Coding
9.2 Command Data
9.2.2 Transaction Certificate Data
The CCD-compliant application shall not contain a TDOL. The CCD-compliant application shall not request the terminal to generate a TC Hash Value (that is, tag '98' shall not be included in CDOL1 or CDOL2). The following Section 9.2.3 applies to a CCD-compliant application.

9.2.3 Common Core Definitions Card Verification Results
In response to the GENERATE AC command and as part of the Issuer Application Data, the CCD-compliant application shall return the Card Verification Results (CVR). The CVR includes information for the issuer regarding the results of Card Risk Management processing and application processing. The format of the CVR for a CCD-compliant application is specified in CCD Annex C7.3. 9.2.3.1 Options Related to Setting/Resetting of Counters and Indicators The issuer shall have the option of specifying whether a new card is required to set the ‗Go Online on Next Transaction Was Set‘ bit. The issuer shall have the option of specifying whether the CCD-compliant application requires issuer authentication to be performed for the application to approve (TC) an online transaction. The issuer shall have the option of specifying whether the CCD-compliant application requires issuer authentication to pass when performed for the application to approve (TC) an online transaction. If the CCD-compliant application does not require issuer authentication to be performed for the application to approve (TC) an online transaction, the issuer shall have the option of specifying whether the CCD-compliant application requires issuer authentication to pass for resetting all the following non-velocity-checking indicators:     Issuer Authentication Failed Last Online Transaction Not Completed Issuer Script Processing Failed Go Online on Next Transaction Was Set

Page 194

June 2008

If the ‗CSU Created by Proxy for the Issuer‘ bit is set to 1 in the CSU. these bits shall be set to Second GENERATE AC Not Requested. and if the issuer specifies that ‗Update Counters‘ shall not be used. if the ‗CSU Created by Proxy for the Issuer‘ bit in the CSU is set to 1.2. The issuer shall have the option of indicating whether the application shall use the ‗Update Counters‘ bits in the CSU to update the velocity-checking count(s) and cumulative amount(s) associated with the offline transaction limits referred to in bits b8 . Application Cryptogram Type Returned in Second GENERATE AC In the first GENERATE AC response.2 Setting and Resetting of Bits in the CVR The following describes the conditions under which each bit in the CVR of a Common Core Definitions card is set or reset. June 2008 Page 195 . In the second GENERATE AC response. these bits shall be set to the value of bits b8 – b7 of the Cryptogram Information Data returned in the response to the second GENERATE AC command of the current transaction (AAC or TC).2 Book 3 Application Specification Common Core Definitions If the CCD-compliant application does not require issuer authentication to pass when performed for the application to approve (TC) an online transaction.3.b5 of byte 3 of the CVR. then the issuer shall have the option of indicating whether the application:     shall not update the offline counters shall set the offline counters to zero shall set the offline counters to the upper offline limits shall add the transaction to the offline counter(s) 9. the issuer shall have the option of specifying whether the CCD-compliant application requires issuer authentication to pass for resetting all the following non-velocity checking indicators:    Last Online Transaction Not Completed Issuer Script Processing Failed Go Online on Next Transaction Was Set If the CCD-compliant application does not require issuer authentication to be performed or does not require issuer authentication to pass when performed for the application to approve (TC) an online transaction.EMV 4. the issuer shall have the option of specifying whether the CCD-compliant application requires issuer authentication to pass for resetting the velocity-checking offline transaction count(s) and cumulative amount(s).

In the first GENERATE AC response. this bit shall be set if and only if the CCD-compliant application did not receive Issuer Authentication Data. this bit shall be set if and only if Signed Dynamic Data is returned in the response to the first GENERATE AC command of the current transaction. CDA Performed In the first GENERATE AC response. this bit shall be set to the value it had in the most recent second GENERATE AC response sent by the CCD-compliant application. these bits shall be set to the value of bits b8 – b7 of the Cryptogram Information Data returned in the response to the first GENERATE AC command of the current transaction (AAC. This may be the case either if the transaction was unable to go online or if the issuer did not provide Issuer Authentication Data in the response message. or ARQC). In the second GENERATE AC response.Common Core Definitions EMV 4. Issuer Authentication Not Performed In the second GENERATE AC response.2 Book 3 Application Specification Application Cryptogram Type Returned in First GENERATE AC In both the first and second GENERATE AC response. TC. this bit shall be set if and only if Signed Dynamic Application Data is returned in the response to the INTERNAL AUTHENTICATE command of the current transaction. Offline DDA Performed In both the first and second GENERATE AC response. this bit shall be set if and only if Signed Dynamic Data is returned in the response to the first or second GENERATE AC command (or both) of the current transaction. Page 196 June 2008 .

2 Book 3 Application Specification Common Core Definitions Issuer Authentication Failed This bit shall be set in the GENERATE AC response if and only if issuer authentication was performed and failed. or all of the following conditions are true:  the transaction successfully went online (that is. this bit shall remain set until either:   issuer authentication is successful.    Low Order Nibble of PIN Try Counter In both the first and second GENERATE AC response. Offline PIN Verification Performed In both the first and second GENERATE AC response. the Authorisation Response Code does not indicate that the terminal was unable to go online). PIN Try Limit Exceeded In both the first and second GENERATE AC response. it indicates either that issuer authentication failed in the current transaction.EMV 4. these bits shall be set to the value of the low-order nibble (bits b4-b1) of the PIN Try Counter. and the CCD-compliant application does not require issuer authentication to pass for resetting of non-velocity-checking indicators. In the first GENERATE AC response. this bit shall be set if and only if Offline PIN Verification has been performed on the current transaction and the PIN was not successfully verified during processing of the current transaction. the CCD-compliant application does not require issuer authentication to be performed for the application to approve (TC) an online transaction. June 2008 Page 197 . or that issuer authentication failed in a previous transaction and the bit was not reset. In the second GENERATE AC response. Offline PIN Verification Performed and PIN Not Successfully Verified In both the first and second GENERATE AC response. Once set. it indicates issuer authentication failed in a previous online transaction. issuer authentication was not performed. this bit shall be set if and only if Offline PIN Verification has been performed (successfully or unsuccessfully) on the current transaction. this bit shall be set if and only if the PIN Try Counter is zero.

Page 198 June 2008 . the CCD-compliant application requested to go online and the transaction was not completed (that is. and the CCD-compliant application does not require issuer authentication to pass for resetting of non-velocity-checking indicators. the CCD-compliant application does not require issuer authentication to pass when performed for the application to approve (TC) an online transaction. this bit shall remain set until either:   issuer authentication is successful.Common Core Definitions EMV 4. and the CCD-compliant application does not require issuer authentication to pass for resetting of non-velocity-checking indicators.2 Book 3 Application Specification Last Online Transaction Not Completed This bit shall be set in the first GENERATE AC response if and only if in the previous transaction. This bit may also be set under additional conditions specified by the issuer. At the least. Once set. or all of the following conditions are true:  the transaction successfully went online (that is. this bit shall be set if the CCD-compliant application has exceeded an issuer-specified lower limit for the number of transactions approved offline. This bit may represent the condition of multiple counters. the second GENERATE AC command was not received). issuer authentication was not performed. the Authorisation Response Code does not indicate that the terminal was unable to go online).     or all of the following conditions are true:     Lower Offline Transaction Count Limit Exceeded In both the first and second GENERATE AC response. the CCD-compliant application does not require issuer authentication to be performed for the application to approve (TC) an online transaction. all transactions approved offline whose amounts were not cumulated shall be included in at least one transaction count. the Authorisation Response Code does not indicate that the terminal was unable to go online). issuer authentication was performed and failed. the transaction successfully went online (that is.

This bit may represent the condition of multiple counters. Number of Successfully Processed Issuer Script Commands Containing Secure Messaging In the first and second GENERATE AC response. Upper Cumulative Offline Amount Limit Exceeded In both the first and second GENERATE AC response. Issuer-discretionary bit 1 – Issuer-discretionary bit 4: These bits are set in the first and second GENERATE AC response at the discretion of the issuer.2 Book 3 Application Specification Common Core Definitions Upper Offline Transaction Count Limit Exceeded In both the first and second GENERATE AC response. The meaning of these bits is defined by the issuer and is outside the scope of this specification. all domestic transactions approved offline shall be included in at least one cumulative amount. This bit may also be set under additional conditions specified by the issuer. June 2008 Page 199 . this bit shall be set if the CCD-compliant application has exceeded an issuer-specified upper limit for the number of transactions approved offline. this bit shall be set if the CCD-compliant application has exceeded an issuer-specified upper limit for cumulative amounts approved offline. At the least. At the least. This bit may represent the condition of multiple counters.EMV 4. At the least. all transactions approved offline whose amounts were not cumulated shall be included in at least one transaction count. this bit shall be set if the CCD-compliant application has exceeded an issuer-specified lower limit for cumulative amounts approved offline. This bit may also be set under additional conditions specified by the issuer. all domestic transactions approved offline shall be included in at least one cumulative amount. Lower Cumulative Offline Amount Limit Exceeded In both the first and second GENERATE AC response. these bits shall be set to the number of commands successfully processed with secure messaging. This bit may represent the condition of multiple counters. This bit may also be set under additional conditions specified by the issuer.

this bit shall be set if and only if processing of a command with secure messaging failed. issuer authentication was not performed the CCD-compliant application does not require issuer authentication to be performed for the application to approve (TC) an online transaction. this bit shall be set if and only if. the Authorisation Response Code does not indicate that the terminal was unable to go online). issuer authentication was performed and failed. this bit shall remain set until a subsequent GENERATE AC command where either:   issuer authentication is successful.Common Core Definitions EMV 4. Once set.     or all of the following conditions are true:     Offline Data Authentication Failed on Previous Transaction In both the first and second GENERATE AC response. the Authorisation Response Code does not indicate that the terminal was unable to go online). any of the following bits was set:    SDA Failed DDA Failed CDA Failed Once set. and the CCD-compliant application does not require issuer authentication to pass for resetting of non-velocity-checking indicators. in the TVR returned during the previous transaction. the CCD-compliant application does not require issuer authentication to pass when performed for the application to approve (TC) an online transaction. or all of the following conditions are true:  the transaction successfully went online (that is. and the CCD-compliant application does not require issuer authentication to pass for resetting of non-velocity-checking indicators. the transaction successfully went online (that is.2 Book 3 Application Specification Issuer Script Processing Failed In both the first and second GENERATE AC response. this bit shall remain set until a subsequent transaction is performed that meets either of the following conditions:   the previous transaction successfully went online. or the previous transaction was approved offline. June 2008 Page 200 .

and the Set Go Online on Next Transaction bit of the CSU is not set.EMV 4. this bit shall remain set until a subsequent GENERATE AC command where either:  all of the following conditions are true:     issuer authentication is successful. issuer authentication was not performed. the Authorisation Response Code does not indicate that the terminal was unable to go online). the Authorisation Response Code does not indicate that the terminal was unable to go online). Once set. or it is a new card and the issuer has specified that a new card is required to set the ‗Go Online on Next Transaction Was Set‘ bit. or or all of the following conditions are true:     or all of the following conditions are true:     Unable to go Online This bit shall be set in the second GENERATE AC response if and only if the Authorization Response Code. the transaction successfully went online (that is. issuer authentication was performed and failed. Go Online on Next Transaction Was Set In both the first and second GENERATE AC response. and the CCD-compliant application does not require issuer authentication for resetting of non-velocity-checking indicatorss. tag '8A'. the CCD-compliant application does not require issuer authentication to pass when performed for the application to approve (TC) an online transaction.2 Book 3 Application Specification Common Core Definitions If either condition is met the bit is reset in the first GENERATE AC response. the CCD-compliant application does not require issuer authentication to be performed for the application to approve (TC) an online transaction. this bit shall be set if and only if the ‗Set Go Online on Next Transaction‘ bit of the last successfully recovered CSU was set. the transaction successfully went online (that is. June 2008 Page 201 . returned from the terminal indicates the terminal was unable to go online (set to 'Y3' or 'Z3'). and the CCD-compliant application does not require issuer authentication to pass for resetting of non-velocity-checking indicators.

and either the transaction occurs at an offline-only terminal or the terminal is unable to go online.3. whether the CCD-compliant application shall:   be allowed to approve (TC) the transaction. the CCD-compliant application shall decline the transaction offline. whether the CCD-compliant application shall:   force transactions at online-capable terminals to go online. or decline the transaction. The issuer shall have the option of specifying that if this bit is set. or allow the transaction to remain offline. or allow the transaction to remain offline. whether the CCD-compliant application shall:   be allowed to approve (TC) the transaction. and issuer-configurable options that shall be supported by the CCD-compliant application. Issuer Authentication Not Performed The issuer shall have the option of specifying that if this bit is set.2.Common Core Definitions EMV 4. PIN Try Limit Exceeded The issuer shall have the option of specifying that if this bit is set. whether the CCD-compliant application shall:   force transactions at online-capable terminals to go online. The issuer shall have the option of specifying that if this bit is set. or decline the transaction. The issuer shall have the option of specifying that if this bit is set.2 Book 3 Application Specification 9. Page 202 June 2008 . or allow the transaction to remain offline. and either the transaction occurs at an offline-only terminal or the terminal is unable to go online. Issuer Authentication Failed The issuer shall have the option of specifying that if this bit is set.3 Mandatory Actions Due to CVR Bit Settings This section provides a list of mandatory actions that shall be taken by the CCD-compliant application. whether the CCD-compliant application shall:   force transactions at online-capable terminals to go online.

the CCD-compliant application shall force the transaction at online-capable terminals to go online. The issuer shall have the option of specifying that if this bit is set. Lower Cumulative Offline Amount Limit Exceeded If this bit is set in the first GENERATE AC response. and either the transaction occurs at an offline-only terminal or the terminal is unable to go online. whether the CCD-compliant application shall:   be allowed to approve (TC) the transaction. Upper Cumulative Offline Amount Limit Exceeded If this bit is set and either the transaction occurs at an offline-only terminal or the terminal is unable to go online. or decline the transaction. However. The ICC shall not block the application or the card due to this bit being set. the CCD-compliant application shall force the transaction at online-capable terminals to go online. the issuer shall have the option of allowing the CCD-compliant application to override this decline for a transaction at Terminal Type 26. or decline the transaction. the CCD-compliant application shall force the transaction at online-capable terminals to go online. whether the CCD-compliant application shall:   be allowed to approve (TC) the transaction. June 2008 Page 203 . Upper Offline Transaction Count Limit Exceeded If this bit is set and either the transaction occurs at an offline-only terminal or the terminal is unable to go online. and either the transaction occurs at an offline-only terminal or the terminal is unable to go online. Last Online Transaction Not Completed If this bit is set. the CCD-compliant application shall decline the transaction. the issuer shall have the option of allowing the CCD-compliant application to override this decline for a transaction at Terminal Type 26. Lower Offline Transaction Count Limit Exceeded If this bit is set in the first GENERATE AC response.EMV 4. However.2 Book 3 Application Specification Common Core Definitions The issuer shall have the option of specifying that if this bit is set. the CCD-compliant application shall decline the transaction.

whether the CCD-compliant application shall:   be allowed to approve (TC) the transaction. 9. or decline the transaction. and either the transaction occurs at an offline-only terminal or the terminal is unable to go online. or allow the transaction to remain offline.Common Core Definitions EMV 4. Go Online on Next Transaction Was Set The issuer shall have the option of specifying that if this bit is set.3 Command Use The CCD-compliant application shall respond to the first GENERATE AC with any of the following cryptogram types:    TC ARQC AAC The CCD-compliant application shall respond to the second GENERATE AC (if applicable) with either of the following cryptogram types:   TC AAC Page 204 June 2008 . whether the CCD-compliant application shall:   force transactions at online-capable terminals to go online.2 Book 3 Application Specification Issuer Script Processing Failed The issuer shall have the option of specifying that if this bit is set.

1 Terminal Messages for an AAC The CCD-compliant application shall set bits b3-b1 of the CID to '000' in the GENERATE AC command response. bit 5 to 1. It shall indicate this by setting the Application Interchange Profile byte 1.2 Advice Messages The CCD-compliant application shall not request the terminal to send an advice message.1 Offline PIN Processing The CCD-compliant application shall be capable of supporting offline plaintext PIN verification.8. It is the Issuer‘s option whether or not to use offline plaintext PIN as a cardholder verification method.8. Bit b4 of the Cryptogram Information Data shall be set to 0. 10. 10.2 Book 3 Application Specification Common Core Definitions 10 Functions Used in Transaction Processing 10.5. June 2008 Page 205 .10 Issuer-to-Card Script Processing An issuer shall send no more than one issuer script template in an authorization response message. 10.8 Card Action Analysis The CCD-compliant application shall not request that the terminal send an advice message to the issuer.EMV 4. 10. The script template may be tag '71' or tag '72'.5 Cardholder Verification The CCD-compliant application shall support Cardholder Verification. 10. The script template may contain multiple commands.

1. 10. If the issuer specifies that the application shall set the offline counters to the upper offline limits. Page 206 June 2008 .. all applications in the ICC shall be permanently disabled. If ‗Issuer Approves Online Transaction‘ is not set. the application will reset all the offline counters and cumulative amounts to zero.1 Actions Taken by CCD-compliant Application After Issuer Authentication is Successful After issuer authentication is successful. the transaction will be included in the offline counters or cumulative amounts as if it were an offline transaction. Issuer Approves Online Transaction If ‗Issuer Approves Online Transaction‘ is set and the terminal requests a TC. the application shall approve the transaction by returning a TC. the offline counters and cumulative amounts will be set to their respective upper limits.11. the issuer allows the application to accept offline transactions.Common Core Definitions EMV 4. By doing so. If the issuer specifies that the application shall add the transaction to the offline counter(s). including applications that may be selected implicitly. then the following shall govern the behaviour of velocity-checking counters and cumulative amounts associated with the offline transaction limits referred to in bits b8-b5 of byte 3 of the CVR:   If the issuer specifies that the application shall not update the offline counters.11. For all subsequent SELECT commands the card shall return the status bytes ‗Function not supported‘ (SW1-SW2 = '6A81') and perform no other action. up to the offline limits.11 Completion The following Section 10.1 Additional Completion Actions for a CCD-Compliant Application 10.1 applies to a CCD-compliant application. Card Block If ‗Card Block‘ is set.2 Book 3 Application Specification 10. the application shall decline the transaction by returning an AAC.11. If the issuer specifies that the application shall set the offline counters to zero. and if the issuer specifies that ‗Update Counters‘ shall not be used. no offline counter or cumulative amount is modified.   This section describes the actions to be taken by the CCD-compliant application due to the setting of each bit in the CSU after issuer authentication is successful. if the ‗CSU Created by Proxy for the Issuer‘ bit in the CSU is set to 1.

An invalidated application shall return the status bytes ‗Selected file invalidated‘ (SW1-SW2 = '6283') in response to a SELECT command and return only an AAC in response to the GENERATE AC command. the CCD-compliant application shall return an ARQC in response to the first GENERATE AC command if a TC or an ARQC is requested). no update of the PTC shall be performed by the application. If the PIN is blocked. Update PIN Try Counter If ‗Update PIN Try Counter‘ is set. the Authorisation Response Code does not indicate that the terminal was unable to go online). The value contained in bits b4-b1 of byte 1 of the CSU shall never be interpreted by the application. the application shall update the PIN Try Counter (PTC) with the value contained in bits b4-b1 of byte 1 of the CSU. the currently selected application shall be invalidated. issuer authentication was not performed. and the Set Go Online on Next Transaction bit of the CSU is not set. the transaction successfully went online (that is. updating the value of the PTC with a non-zero value unblocks the PIN.2 Book 3 Application Specification Common Core Definitions Application Block If ‗Application Block‘ is set.‖ the transaction successfully went online (that is. the Authorisation Response Code does not indicate that the terminal was unable to go online). the application shall force subsequent transactions at online-capable terminals to go online (that is. Set Go Online on Next Transaction If ‗Set Go Online on Next Transaction‘ is set. and the CCD-compliant application does not require issuer authentication to pass for resetting of non-velocity-checking indicators. If ‗Update PIN Try Counter‘ is not set. the CCD-compliant application does not require issuer authentication to be performed for the application to approve (TC) an online transaction. Updating the value of the PTC with a zero value blocks the PIN. Page 207 or all of the following conditions are true:     or all of the following conditions are true:  June 2008 . The application shall continue to try to go online at online-cable terminals until a subsequent GENERATE AC command where either:  all of the following conditions are true:     issuer authentication is successful.EMV 4.

the application shall set the offline counters and cumulative amounts to their respective upper limits.11. issuer authentication was not performed. the application shall reset all the offline counters and cumulative amounts to zero. no offline counter or cumulative amount shall be modified. and the CCD-compliant application does not require issuer authentication to pass for resetting of non-velocity-checking indicators. the CCD-compliant application does not require issuer authentication to pass when performed for the application to approve (TC) an online transaction. If ‗Update Counters‘ is set to ‗Reset Offline Counters to Zero‘. the application shall include the transaction in the offline counters or cumulative amounts as if it were an offline transaction.Common Core Definitions EMV 4.  Update Counters ‗Update Counters‘ (bits b2-b1 of byte 2 of the CSU) govern the behaviour of velocity-checking counters and cumulative amounts associated with the offline transaction limits referred to in bits b8-b5 of byte 3 of the CVR if either of the following is true:   the ‗CSU Created by Proxy for the Issuer‘ bit in the CSU is set to 0 the issuer specifies that the application shall use the ‗Update Counters‘ bits in the CSU to update the velocity-checking count(s) and cumulative amount(s) regardless of the bit setting for ‗CSU Created by Proxy for the Issuer‘ If ‗Update Counters‘ is set to ‗Do Not Update Offline Counters‘. the CCD-compliant application shall reset to zero the velocity-checking offline transaction count(s) and cumulative offline amount(s) if either of the following are true:  all of the following conditions are true:   the terminal requested a TC. up to the offline limits. the Authorisation Response Code does not indicate that the terminal was unable to go online). Page 208 June 2008 .2 Book 3 Application Specification   issuer authentication was performed and failed.1. 10. By doing so.2 Other Completion Actions After the transaction successfully went online (that is. the issuer allows the application to accept offline transactions. If ‗Update Counters‘ is set to ‗Add Transaction to Offline Counters‘. If ‗Update Counters‘ is set to ‗Set Offline Counters to Upper Offline Limits‘.

the CCD-compliant application shall approve the transaction if all of the following conditions are true:   the terminal requested a TC.  After the transaction successfully went online (that is. the terminal requested a TC. issuer authentication was performed and failed. or issuer authentication was performed and failed and the CCD-compliant application does not require issuer authentication to pass when performed for the application to approve (TC) an online transaction.EMV 4. the CCD-compliant application does not require issuer authentication to pass when performed for the application to approve (TC) an online transaction. and one of the following is true:   issuer authentication is successful and the ‗Issuer Approves Online Transaction bit‘ of the recovered CSU is set to 1. and the CCD-compliant application does not require issuer authentication to pass for resetting of velocity-checking counters. the Authorisation Response Code does not indicate that the terminal was unable to go online). issuer authentication was performed and failed.   or all of the following conditions are true:     After the transaction successfully went online (that is. the Authorisation Response Code does not indicate that the terminal was unable to go online).2 Book 3 Application Specification Common Core Definitions  the CCD-compliant application does not require issuer authentication to be performed for the application to approve (TC) an online transaction. and or both of the following are true:  June 2008 Page 209 . and the CCD-compliant application requires issuer authentication to be performed for the application to approve (TC) an online transaction. and the CCD-compliant application does not require issuer authentication to pass for resetting of velocity-checking counters. or issuer authentication was not performed and the CCD-compliant application does not require issuer authentication to be performed for the application to approve (TC) an online transaction. the CCD-compliant application shall decline the transaction in the second GENERATE AC response if either of the following conditions are true:  both of the following are true:    issuer authentication was not performed.

After the transaction did not successfully complete online (that is the Authorisation Response Code indicates that the terminal was unable to go online).Annexes Annex A Data Elements Dictionary For the data elements shown in Table CCD 6:   If the source is ‗Terminal‘. Page 210 June 2008 . Data Element Name Amount.2 Book 3 Application Specification  the CCD-compliant application requires issuer authentication to pass when performed for the application to approve (TC) an online transactionl. If the source is ‗ICC‘. Reference Currency Application Reference Currency Application Reference Currency Exponent Default Dynamic Data Authentication Data Object List (DDOL) Transaction Certificate (TC) Hash Value Tag '9F3A' '9F3B' '9F43' — '98' Source Terminal ICC ICC Terminal Terminal Table CCD 6: Data Elements Not Used by a CCD-Compliant Application Table CCD 7 lists data elements (in addition to those defined in Annex A) that are defined within the context of the Common Core Definitions. Part IV . the CCD-compliant application shall decide whether to approve or decline the transaction. the data element shall not be identified in the AFL of a CCD-compliant application.Common Core Definitions EMV 4. the data element shall not be included in any DOL used by a CCD-compliant application.

Data sent to the issuer identifying the format of the Issuer Application Data and the method for calculating the Application Cryptogram. Transmitted to the terminal in Issuer Application Data as specified in Table CCD 9. ICC b — — 1 Issuer Discretionary Data ICC b — — 15 Table CCD 7: Additional Data Elements Defined for CCD June 2008 Page 211 . Contains the following: Format Code (FC) Cryptogram Version (CV) ICC b — — 5 Common Core Identifier (CCI) ICC b — — 1 Derivation Key Index (DKI) Data sent to the issuer identifying the issuer‘s derivation key for deriving the card‘s ICC Master Keys. Transmitted to the terminal in Issuer Application Data as specified in Table CCD 9.EMV 4. Transmitted to the terminal in Issuer Application Data as specified in Table CCD 9.2 Book 3 Application Specification Common Core Definitions Name Description Source Format Templat e T a g Leng th Card Verification Results (CVR) Contains data sent to the issuer indicating exception conditions that occurred during the current and previous transactions. Contains issuer proprietary application data for transmission to the issuer in an online transaction. Transmitted to the terminal in Issuer Application Data as specified in Table CCD 9.

Byte 2 shall be the Common Core Identifier (CCI). and the Cryptogram Version (CV). Byte 17 shall be set to '0F'.1 IAD Format (= ‗A‘) Common Core Cryptogram Version (CV) CCD Version 4. C7. Values in the range '00' to '9F' are reserved to avoid conflict with legacy Cryptogram Version Numbers. The CCD-compliant application shall support the selection of different Issuer Application Data if:   the card requests the Terminal Type and the Additional Terminal Capabilities in PDOL.1 Common Core Identifier The CCI shall identify the format of the IAD. 32 bytes long. b8 x 1 b7 x 0 b6 x 1 b5 x 0 x 0 x 1 x 0 x 1 b4 b3 b2 b1 Meaning Common Core IAD Format Code (FC). and the values provided by the terminal in the PDOL related data for the Terminal Type and the first two bytes of the Additional Terminal Capabilities are '34‘ and '0000' respectively. Values in the range 'A' .'F' shall indicate a CCD-specified IAD format (all values RFU by EMVCo for CCD).Common Core Definitions EMV 4. CCD Version 4.1 Cryptogram Version (= ‗5‘) Table CCD 8: Common Core Identifier Bits b8 .2 Book 3 Application Specification Annex C Coding of Data Elements Used in Transaction Processing Please add the following sections after Annex C.6.b5 of the CCI shall indicate the Format Code (FC). Page 212 June 2008 . C7 Issuer Application Data for a Common Core DefinitionsCompliant Application The CCD-compliant application shall have an Issuer Application Data (IAD) field of fixed length. with the following attributes:    Byte 1 shall be set to '0F'.

Values in the range '4' . and ARPC method the CCD-compliant application expects the issuer to use when generating the Authorisation Response Cryptogram. The cryptogram input data (including CSU coding). Length of Issuer Discretionary Data field in IAD. When using the CV range '0' . C7. Contents are at the discretion of the issuer.'3' shall indicate a proprietary cryptogram algorithm.EMV 4.'3'.b1 of the CCI shall indicate the Cryptogram Version (CV) for the Application Cryptogram. Common Core Identifier Derivation Key Index Card Verification Results (see section C7.2 Issuer Application Data for Format Code ‘A’ The format and coding of the IAD with a Format Code of ‗A‘ shall be as shown in Table CCD 9: Byte(s) 1 2 3 4-8 9-16 17 18-32 Contents Length Indicator CCI DKI CVR Counters Length Indicator Issuer Discretionary Data Description Length of EMVCo-defined data in IAD. Values in the range '0' . key derivation method. The CV indicates:   The cryptogram input data and key derivation method the CCD-compliant application uses to generate the Application Cryptogram. applications are not CCD-compliant. Set to '0F'.2 Book 3 Application Specification Common Core Definitions Bits b4 . Table CCD 9: Issuer Application Data for Format Code ‘A’ June 2008 Page 213 .3) Contents are at the discretion of the Payment System. Set to '0F'.'F' shall indicate a CCD-specified cryptogram algorithm and data set (all values RFU by EMVCo for CCD).

Common Core Definitions EMV 4.2 Book 3 Application Specification C7. CVR Byte 1 b8 x 0 0 1 1 b7 x 0 1 0 1 x 0 0 1 1 x 0 1 0 1 1 1 1 1 CVR Byte 2 b8 x b7 x b6 x b5 x 1 1 1 1 b4 b3 b2 b1 Meaning Low Order Nibble of PIN Try Counter Offline PIN Verification Performed Offline PIN Verification Performed and PIN Not Successfully Verified PIN Try Limit Exceeded Last Online Transaction Not Completed b6 b5 b4 b3 b2 b1 Meaning Application Cryptogram Type Returned in Second GENERATE AC AAC TC Second GENERATE AC Not Requested RFU Application Cryptogram Type Returned in First GENERATE AC AAC TC ARQC RFU CDA Performed Offline DDA Performed Issuer Authentication Not Performed Issuer Authentication Failed Table CCD 10: Card Verification Results for Format Code ‘A’ Page 214 June 2008 .3 Card Verification Results The coding of the CVR for a Common Core IAD Format Code of value ‗A‘ shall be as shown in Table CCD 10.

continued June 2008 Page 215 .2 Book 3 Application Specification Common Core Definitions CVR Byte 3 b8 1 1 1 1 1 1 1 1 CVR Byte 4 b8 x b7 x b6 x b5 x 1 1 1 1 CVR Byte 5 b8 0 b7 0 b6 0 b5 0 b4 0 b3 0 b2 0 b1 0 RFU Meaning b4 b3 b2 b1 Meaning Number of Successfully Processed Issuer Script Commands Containing Secure Messaging Issuer Script Processing Failed Offline Data Authentication Failed on Previous Transaction Go Online on Next Transaction Was Set Unable to go Online b7 b6 b5 b4 b3 b2 b1 Meaning Lower Offline Transaction Count Limit Exceeded Upper Offline Transaction Count Limit Exceeded Lower Cumulative Offline Amount Limit Exceeded Upper Cumulative Offline Amount Limit Exceeded Issuer-discretionary bit 1 Issuer-discretionary bit 2 Issuer-discretionary bit 3 Issuer-discretionary bit 4 Table CCD 10: Card Verification Results for Format Code ‘A’.EMV 4.

The coding of the CSU is shown in Table CCD 11.2 Book 3 Application Specification C8 Card Status Update for a Common Core DefinitionsCompliant Application The Issuer Authentication Data shall include a Card Status Update (CSU) of fixed length. 4 bytes long. Table CCD 11: Card Status Update for Cryptogram Version ‘5’ Page 216 June 2008 .Common Core Definitions EMV 4. CSU Byte 1 b8 1 0 0 0 x CSU Byte 2 b8 1 1 1 1 1 1 x 0 0 1 1 x 0 1 0 1 b7 b6 b5 b4 b3 b2 b1 Card Block Application Block Update PIN Try Counter Set Go Online on Next Transaction CSU Created by Proxy for the Issuer Update Counters Do Not Update Offline Counters Set Offline Counters to Upper Offline Limits Reset Offline Counters to Zero Add Transaction to Offline Counter Meaning Issuer Approves Online Transaction x x x b7 b6 b5 b4 b3 b2 b1 RFU PIN Try Counter Meaning Proprietary Authentication Data Included Note: The ‗CSU Created by Proxy for the Issuer‘ bit shall be set in the CSU if and only if the CSU is generated by a proxy for the Issuer.

it shall be supported using the method specified in Annex D.EMV 4. Annex D Transaction Log Information If the CCD-compliant application supports transaction logging.2 Book 3 Application Specification Common Core Definitions CSU Byte 3 b8 0 b7 0 b6 0 b5 0 b4 0 b3 0 b2 0 b1 0 RFU Meaning CSU Byte 4 b8 x b7 x b6 x b5 x b4 x b3 x b2 x b1 x Meaning Issuer-Discretionary Table CCD 11: Card Status Update for Cryptogram Version ‘5’. continued The default value for issuer-discretionary data in the CSU is zero. June 2008 Page 217 .

.

212 Completion . 122............................. 193 EXTERNAL AUTHENTICATE ..................................... 133 Application Preferred Name .............................................................. 101............. 212....... 135...... 100..... 166 Amount ................... 98.............. 143 Application Primary Account Number (PAN) .............. 63.................................EMV 4................. 81............................................ 38...... 146 Additional Terminal Capabilities .............................................. 138 Class Byte ........ See Common Core Definitions CDA..................... 133.... 132 Application Elementary File ............................................ 101.... 136 CDOL2 ......... 65 PIN CHANGE/UNBLOCK ......................................... 131............... 131................... 133......................................... 123....................................... 136 BER-TLV Data Objects ............................. 80.............. 169 Application Currency Exponent............................................... 82....................... 56. 52 EXTERNAL AUTHENTICATE ............ 147...... 61......................................... 214 Cardholder Verification ............................................................... 37........... 167 Application Version Number .......................... 49 Application Cryptogram ................. 205 Offline PIN Processing .... 82................. 71 Common Core Definitions................ 58................................................... 132 Application Effective Date ..... 192 Issuer Application Data ............. 96.... 37.................... 63........... 85............................... 48 APPLICATION BLOCK .......... 206 Data Elements ... 136 C Card Action Analysis ..................................................... 161 BIC ......... 42 Coding Conventions............................ 133 Application File Locator ..................................... 135 ATC ....... 100..... 98................... 67 READ RECORD................. 104..... 134 Application Template ............................. 121 CARD BLOCK ... 150 Amount..... 69 VERIFY .......... 127 B Bank Identifier Code ............................. 148 AIP..................... Authorised .......... 102................................................. 144 Command APDU Structure . 122 AFL ............ 213 Issuer-to-Card Script Processing ...................... 205 Response APDU Format....... 41 Commands ................................ 131 Advice Messages ......................... 103............................. 134 APPLICATION BLOCK ......................... See AFL Application Identifier ................................ 51 CARD BLOCK ... See CVM CCD ........ See Application Cryptogram Account Type .... 52 Card Risk Management Data Object List 1 .....See AID Application Interchange Profile ................................ 132 Application Discretionary Data .......................... 93........................................................... 81................... 133 Application Priority Indicator ...................................... 83..... 135 Coding .............. 135 Application Transaction Counter .......... 63 INTERNAL AUTHENTICATE............... 100........... 116........................ 58............... 41............................ 49.... 190 Completion .............. 61 GET PROCESSING OPTIONS ............................... 185 Acquirer Identifier ........ 134............................... 190 GENERATE AC Command Use................. 210 Data Retrievable by GET DATA Command ................................ 42 Command ............ 56....... 19 AC ........................ 166 CDOL1 ........................................................................................ 194 GENERATE AC . 59.................... 97........................................ 80.... See CVM Cardholder Verification Method ....................... 64. 132 Application Currency Code 103........................................................ 133 Coding ............................ 87 GET CHALLENGE .................. 151...........See Bank Identifier Code June 2008 Page 219 .................. 145 AUC .......................................................... 135......................... 113............... 190 Functions Used in Transaction Processing .......... 123............2 Book 3 Application Specification Index A Abbreviations ............ 205 CID Coding. 58..... 54 GENERATE AC ........ 204 GET PROCESSING OPTIONS .......... See CDOL1 Card Risk Management Data Object List 2 .... 191 INTERNAL AUTHENTICATE.......................... See ATC APPLICATION UNBLOCK ......... 80.................... 191 Common Core Identifier ...... 98.. 60 GET DATA ................ 189 Card Status Update ................... 167 Authorisation Code ........................................ 135................... 136 Authorisation Response Code ......................... 104 API................ 138.............. 102....... 136 CID ....... 78..................... 64........... 137 Cardholder Verification....... See CDOL2 Cardholder Name ......... 95.............. 51 Application Usage Control .................... 94.. 89........................................... 164 Application Expiration Date ............... 38............ See AIP Application Label ... 78.......... 78..... 132.......... 133 AID .. 49 APPLICATION UNBLOCK ......... 206 GENERATE AC Command Coding ........................................ 124.... 90....................... 38........................ 216 Card Verification Results.....

.......... 132 Cryptogram Information Data...... 61 GET PROCESSING OPTIONS ... See DDOL G GENERATE AC .............. 47 Lower Consecutive Offline Limit .......... 140 IFD.............. 93 Instruction Byte ... 57........... 169 Completion .. 56....................................................... 139............. 142 Issuer Application Data ...................................................... 169 Currency exponent ............................ 83 Exponent ............... 168......................... 97 Offline PIN Processing ..... See Issuer Action Code IAD .......... 142 Issuer Authentication Data ................ See CID Cryptogram Types ..................... 113 Transaction Log ........................ 151 CV Rule Coding .......... 134 Currency Code .......... 195.. 41.............. 58... 138 Data Element Format Conventions ..... 43 Interface Device ......... 145...................... 144 Cryptogram Types ......................... 151............... 107............ 134 EXTERNAL AUTHENTICATE ............ 145 Log Entry .. 103 L Language ........ 107 Terminal Action Analysis .... 140 File Control Information ........... 148............ 117 Terminal Risk Management ........ 142 Issuer Action Code...................................................................... 122.................................. 168 CVM ..... 139 Dynamic Data Authentication Data Object List ........... 148 Floor Limits................................................... 143 Issuer Identification Number ....... 147 Directory Discretionary Template ..... 38........ 35............................. 54 Status Words Returned ......................................................................... See DDF Directory Definition File (DDF) Name ........................................... 94.......................... See Issuer Identification Number Initiate Application Processing ..... 58.................... 139................... 127 Initiate Application Processing.. 177 Logical Channels ........... 106 Online PIN Processing.............. 137..... 56............. 138 Data Authentication Code .................... 58.......................................................... 65 International Bank Account Number ............... 143........... 145 LCOL ........................................................... 71..................... 144 Last Online Application Transaction Counter ............................. 175 D DAC ................................................................ 136.................................................................................................... 127............ 95 Signature Processing ............................................ 147 Format 2 ............................ 87................ 82.................. 38 Data Objects ... 143 Cryptogram ...... 176 Log Format ........... 37.................... 117... 60 GET DATA .................................... 44 Data Object List (DOL)............ 56 GET CHALLENGE ............................. 123................ 114 Format 1 ........ 119................... 117..............................................................................................................Index EMV 4................................................................................................... 113..................... 120........................................... 37 Financial Transaction .... 91........ 125 Offline Data Authentication ........ 142 IBAN ................................... 106.. 77 Floor Limit ........ 140 FCI Issuer Discretionary Data .... 107 Online Processing............................. 82................... See LCOL Page 220 June 2008 .................. 143 Issuer-to-Card Script Processing ..... 121 Cardholder Verification ............................. 142 IIN ...... 131 Data Field Bytes ......... 145......... 93 Issuer-to-Card Script Processing .............................................................................. 123 Processing Restrictions ............................................................................ 35 Data Elements Dictionary.. 121......................... 143 Issuer Code Table Index ..... 139 DDOL ....... 63 I IAC ........................................................................................... 125 E Erroneous Data .......... See International Bank Account Number ICC Dynamic Number ............................... 103.......... 54.. See FCI Files ...............2 Book 3 Application Specification Country Code . 124.............. 82................................................................................ 124............................................................. 36 DDF .................... 134... 138 Directory Definition File ................................................ 170 Issuer Country Code..................... See LATC LATC ...................................................... 9 DF Name .................................................. 123............ 183 F FCI ... 126........................... 125...................... 80.. 56 CSU ........... 117........ 139 Definitions.................. 147 Function Card Action Analysis .... 81 Exception Handling ................................. 29 Data Elements and Files .................................... 206......... 118............ 36 Classes ............................... 139 Directory Definition File Name .......... 35................................................................................................................ 116................. 65........... 208 Currency............................ 59................ 142 INTERNAL AUTHENTICATE ........ 79.................... 100 Read Application Data............................ 101.......................................................................................

........ 144 SDA Tag List............................... 150 Template 70............ 146...... 106............... 114....................... 107... 98... 146 Missing Data .............. 146 Personal Identification Number .......... 115..... 107 Signed Dynamic Application Data ... 153 DOL .......... 63............................... 141.......... 38........................................ 47 Rules for BER-TLV Data Objects........ 117................... 99............................. 65..... 123.................................................. 149 Terminal Type ................. 61................................... 77 MCC ............................ 125.................... 147 Service Code ............................. 79... 143 Public Key Exponent ............................ 169 PIN CHANGE/UNBLOCK ....... 138........................... 117.............. 48... 151 Transaction Sequence Counter.. 104............ 148 SDAD ... 95.... 140... 114 Read Application Data .... 138.................. 147...................... 27 O Offline Data Authentication ................................... 71.............. 82............................................................. 134 Parameter Bytes ................ 125..... 31 Track 1 ................ 151. See TDOL Transaction Date ................................ 149....................... 66............ 168...... 145 Merchant Identifier ....... 137 Public Key Certificate .. 143 Public Key Remainder ............................. 101............................................................. 127...........2 Book 3 Application Specification Index M Mandatory Data Objects.... 148 Terminal Country Code ....... 161 S Scope ..... 152 TRM ......... 149 Track 2 .... 151 Transaction Flow ..... 144..... 93. 97. 149 TSI93............. 113.................. 42 Response APDU Structure ...................................................... 146 Primary Account Number.......... 152 Transaction Type ......... 118..................................... 3 Script............... 67 Point-of-Service (POS) Entry Mode............................ 79. 78............. 151 References June 2008 Page 221 .................. 145 Merchant Category Code ........................... 131.. 81 Normative .. 124.... 183 SVC .................. 194 Normative References ............... 90........ 69.. 38..... 133............... 149 Terminal Verification Results ........................................... 98. 78................... See PDOL Processing Restrictions ........ 146 Processing Options Data Object List . 78........ 143................ 39 PAN ............................ 82. 67.......... 179 Coding ........... 106 Online PIN Processing ........ 126.................... 78............................ iii RFU Data . 95 READ RECORD ............................ 154 Terminal Action Analysis...................... 174 TVR 81.............. 117 Terminal Action Code .... 100 Public Key..... See TVR Terminology .... 147 Short File Identifier ..................... 37 Reference Currency ................. 114....... See PIN PIN 46............................... 147 Signature Processing ....... 114..... 42 Revision Log ...... 5 Response ................................................... 106............................ 105.. 93....... 150 N Non-velocity-checking indicators .... See SSAD SSAD .................. 133 PAN Sequence Number......................... 150 TDOL................................................................... 116.. 148 Terminal Identification ............................... 141..................................................................... 102........ 175 Transaction Personal Identification Number ................................. 149 Terminal Risk Management ........................ 105........................... 43 PDOL ... 147.......................... 78........... 79......................................... 152 Bit Settings Following Script Processing ... 82................................ 81.................................... 139...See TSI Transaction Time .................................. 147.................. 149 Transaction Certificate Data Object List ................................ 146 POS... 123 P Padding Data Elements .................................................. 126.. 139.................. 121.. 98................. 98... See SDAD Signed Static Application Data ...................... 107 Online Processing . 147 Status Bytes . 37............................ 82. 97 Offline PIN Processing........EMV 4........ 139.......... 150 SFI ....................................................... 5 Notations ... 141..................................................... 82...... 113....................... 38....... 78 Mapping Data Objects..... 140......... 100.............. 148 Terminal Capabilities ........... 144 T TC Hash value .................................................... 90. 79................... 44 Status Words EXTERNAL AUTHENTICATE ................ 103....................... 83 Transaction Log Information ............................................. 47........... 69 Record ..................................................................... 133..................................................................................... 79.................. 152 Transaction Status Information ...... 113.. 99.................... 183 R Random Transaction Selection .................................... 107........................................ 131................ 135................ 97.........................................................................

... See UCOL V Velocity Checking ................................................................ 152 UN ........................ 152 Upper Consecutive Offline Limit.............................................. 179 Coding ..... 171 URL ........................... 116.................... 80................. 152 Unpredictable Number ............................................................. 82...........Index EMV 4..............2 Book 3 Application Specification Bit Settings Following Script Processing .... 144 U UCOL ... 71 Page 222 June 2008 ........................................................................................... 116 VERIFY .........