Visa Integrated Circuit Card Terminal Specification

Welcome to
Visa Integrated
Circuit Card Terminal
Specification
The Visa Integrated Circuit Card (ICC) Terminal
Specification has been updated. Please see the Chapter 1,
Section 1.6, “Impact Summary” for information on what has
changed from Visa ICC Specification (VIS) version 1.3.2.
This document is the final copy of the Visa ICC Specification

version 1.4.0. It reflects changes from the copy published on
the Visa website in April 2001. These changes are noted in a
separate changes list available on the Visa website. It is
important that Visa staff, members, and vendors review the
changes list.
If you have any comments regarding this manual, please

contact your regional representative. Your opinion is
important to us.
Effective: 31 October 2001

Visa Integrated Circuit Card
Terminal Specification
Version 1.4.0
Effective: 31 October 2001
 Visa International 1998, 1999, 2001 5103-03
Visa Public
 1998, 1999, 2001 Visa International Service Association. All rights reserved. Permission to copy and implement the
material contained herein is granted subject to the conditions that (i) any copy or re-publication must bear this legend
in full, (ii) any derivative work must bear a notice that it is not the Visa Integrated Circuit Card Specification published
by Visa, and (iii) Visa shall have no responsibility or liability whatsoever to any other party arising from the use or
publication of the material contained herein.
Visa makes no representation or warranty regarding whether any particular physical implementation of any part of
this Specification does or does not violate, infringe, or otherwise use the patents, copyrights, trademarks, trade secrets,
know-how, and/or other intellectual property of third parties, and thus any person who implements any part of this
Specification should consult an intellectual property attorney before any such implementation. Any party seeking to
implement this Specification is solely responsible for determining whether their activities require a license to any
technology including, but not limited to, patents on public key encryption technology. Visa International Service
Association shall not be liable for any party’s infringement of any intellectual property right.
Printed on recycled paper.

Contents
Chapter 1 • About This Specification

1.1 Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2
1.2 VIS Update . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2
1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–3
1.3.1 Mandatory/Required/Recommended/Optional . . . . . . . . . . . 1–3
1.3.2 Card/Integrated Circuit . . . . . . . . . . . . . . . . . . . . 1–3
1.3.3 Terminated Transactions . . . . . . . . . . . . . . . . . . . . 1–3
1.4 Document Structure . . . . . . . . . . . . . . . . . . . . . . . . 1–4
1.4.1 Volume Overview . . . . . . . . . . . . . . . . . . . . . . 1–4
1.4.2 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . 1–4
1.4.3 Subheading Overview . . . . . . . . . . . . . . . . . . . . . 1–6
1.5 Revisions to This Specification . . . . . . . . . . . . . . . . . . . . 1–6
1.6 Impact Summary . . . . . . . . . . . . . . . . . . . . . . . . . 1–7
1.6.1 Terminal . . . . . . . . . . . . . . . . . . . . . . . . . . 1–7
1.6.1.1 Mandatory . . . . . . . . . . . . . . . . . . . . . . . 1–7
1.6.1.2 Optional . . . . . . . . . . . . . . . . . . . . . . . . 1–7
1.6.2 Card . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–8
1.6.2.1 Mandatory . . . . . . . . . . . . . . . . . . . . . . . 1–8
1.6.2.2 Optional . . . . . . . . . . . . . . . . . . . . . . . . 1–8
31 Oct 2001
Draft 12/18/00 Visa Public i
Contents Visa Integrated Circuit Card
Terminal Specification, Version 1.4.0
1.7 Reference Materials . . . . . . . . . . . . . . . . . . . . . . . 1–10
1.7.1 International Organisation for Standardisation (ISO) Documents . . . . 1–10
1.7.2 EMV Documents . . . . . . . . . . . . . . . . . . . . . . 1–11
1.7.3 Visa Documents . . . . . . . . . . . . . . . . . . . . . . 1–11
Chapter 2 • Processing Overview

2.1 Functional Overview . . . . . . . . . . . . . . . . . . . . . . . . 2–1
2.1.1 Application Selection (mandatory) . . . . . . . . . . . . . . . . . 2–1
2.1.2 Initiate Application Processing/Read Application Data (mandatory) . . . . 2–2
2.1.3 Offline Data Authentication . . . . . . . . . . . . . . . . . . . 2–2
2.1.4 Processing Restrictions (mandatory) . . . . . . . . . . . . . . . . 2–3
2.1.5 Cardholder Verification (mandatory) . . . . . . . . . . . . . . . . 2–3
2.1.6 Terminal Risk Management (mandatory) . . . . . . . . . . . . . . 2–3
2.1.7 Terminal Action Analysis (mandatory) . . . . . . . . . . . . . . . 2–4
2.1.8 Card Action Analysis (mandatory) . . . . . . . . . . . . . . . . . 2–4
2.1.9 Online Processing . . . . . . . . . . . . . . . . . . . . . . . 2–4
2.1.10 Issuer-to-Card Script Processing . . . . . . . . . . . . . . . . . 2–5
2.1.11 Completion (mandatory) . . . . . . . . . . . . . . . . . . . . 2–5
2.2 Terminal Mandatory and Optional Functionality . . . . . . . . . . . . . . 2–7
2.2.1 Command Support Requirements . . . . . . . . . . . . . . . . . 2–9
Chapter 3 • Application Selection

3.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2
3.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
3.3 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–5
3.4 Building the Candidate List . . . . . . . . . . . . . . . . . . . . . . 3–6
3.4.1 Directory Selection Method . . . . . . . . . . . . . . . . . . . 3–7
3.4.2 List of AIDs Method . . . . . . . . . . . . . . . . . . . . . . 3–9
ii
Draft 12/18/00 Visa Public 31 Oct 2001
Visa Integrated Circuit Card Contents
3.5 Identifying and Selecting the Application . . . . . . . . . . . . . . . . 3–10
3.5.1 Terminal Makes Application Selection Decision . . . . . . . . . . . 3–10
3.5.2 Cardholder Makes Account Selection Decision . . . . . . . . . . . 3–10
3.5.2.1 Terminal Supports Cardholder Confirmation . . . . . . . . . . 3–10
3.5.2.2 Terminal Supports Cardholder Selection . . . . . . . . . . . 3–11
3.6 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–12
3.7 Subsequent Related Processing . . . . . . . . . . . . . . . . . . . 3–15
Chapter 4 • Initiate Application Processing

4.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
4.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . 4–3
4.3 GET PROCESSING OPTIONS Command . . . . . . . . . . . . . . . 4–3
4.4 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4
4.5 Prior Related Processing . . . . . . . . . . . . . . . . . . . . . . 4–6
Chapter 5 • Read Application Data

5.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2
5.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2
5.3 READ RECORD Command . . . . . . . . . . . . . . . . . . . . . 5–3
5.4 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–3
Chapter 6 • Offline Data Authentication

6.1 Terminal Requirements . . . . . . . . . . . . . . . . . . . . . . . 6–3
6.1.1 Support for Offline Data Authentication . . . . . . . . . . . . . . 6–3
6.1.2 Visa Certificate Authority (CA) . . . . . . . . . . . . . . . . . 6–3
31 Oct 2001
Draft 12/18/00 Visa Public iii
6.1.3 RSA Key Pairs . . . . . . . . . . . . . . . . . . . . . . . . 6–3
6.1.4 Security Requirements . . . . . . . . . . . . . . . . . . . . . 6–4
6.2 Determining Whether to Perform SDA or DDA . . . . . . . . . . . . . . 6–4
6.2.1 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . 6–4
6.2.2 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . 6–5
6.2.3 Commands . . . . . . . . . . . . . . . . . . . . . . . . . 6–5
6.2.4 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–5
6.3 Static Data Authentication (SDA) . . . . . . . . . . . . . . . . . . . 6–7
6.3.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . 6–7
6.3.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . 6–8
6.3.3 Commands . . . . . . . . . . . . . . . . . . . . . . . . . 6–8
6.3.4 SDA Process . . . . . . . . . . . . . . . . . . . . . . . . . 6–9
6.4 Dynamic Data Authentication (DDA) . . . . . . . . . . . . . . . . . 6–12
6.4.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . 6–12
6.4.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . 6–13
6.4.3 Commands . . . . . . . . . . . . . . . . . . . . . . . . 6–14
6.4.3.1 INTERNAL AUTHENTICATE Command . . . . . . . . . . . 6–14
6.4.3.2 GENERATE APPLICATION CRYPTOGRAM (AC) Command . . . 6–14
6.4.4 Processing . . . . . . . . . . . . . . . . . . . . . . . . . 6–14
6.4.4.1 Standard DDA . . . . . . . . . . . . . . . . . . . . . 6–15
6.4.4.2 Combined DDA/AC Generation . . . . . . . . . . . . . . 6–18
6.5 Prior Related Processing . . . . . . . . . . . . . . . . . . . . . 6–23
Chapter 7 • Processing Restrictions

7.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–2
7.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–3
7.3 Application Version Number . . . . . . . . . . . . . . . . . . . . . 7–3
7.4 Application Usage Control . . . . . . . . . . . . . . . . . . . . . . 7–4
iv
7.5 Application Effective Date . . . . . . . . . . . . . . . . . . . . . . 7–6
7.6 Application Expiration Date . . . . . . . . . . . . . . . . . . . . . 7–6
Chapter 8 • Cardholder Verification

8.1 Terminal Requirements . . . . . . . . . . . . . . . . . . . . . . . 8–3
8.2 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–3
8.3 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . 8–7
8.4 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–8
8.5 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–9
8.5.1 CVM List Processing . . . . . . . . . . . . . . . . . . . . . 8–9
8.5.2 CVM Processing . . . . . . . . . . . . . . . . . . . . . . . 8–13
8.5.2.1 Offline Plaintext PIN . . . . . . . . . . . . . . . . . . . 8–13
8.5.2.2 Offline Enciphered PIN . . . . . . . . . . . . . . . . . . 8–19
8.5.2.3 Online PIN . . . . . . . . . . . . . . . . . . . . . . . 8–21
8.5.2.4 Signature . . . . . . . . . . . . . . . . . . . . . . . 8–21
8.5.2.5 Signature and Offline PIN . . . . . . . . . . . . . . . . . 8–22
8.5.2.6 Fail CVM . . . . . . . . . . . . . . . . . . . . . . . 8–22
8.5.2.7 No CVM Required . . . . . . . . . . . . . . . . . . . . 8–23
Chapter 9 • Terminal Risk Management

9.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–3
9.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . 9–4
9.3 GET DATA Command . . . . . . . . . . . . . . . . . . . . . . . 9–5
9.4 Terminal Exception File . . . . . . . . . . . . . . . . . . . . . . 9–5
9.5 Merchant Forced Transaction Online . . . . . . . . . . . . . . . . . 9–5
31 Oct 2001
Draft 12/18/00 Visa Public v
9.6 Floor Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–5
9.7 Random Transaction Selection . . . . . . . . . . . . . . . . . . . . 9–6
9.8 Terminal Velocity Checking . . . . . . . . . . . . . . . . . . . . . . 9–7
9.9 New Card Check . . . . . . . . . . . . . . . . . . . . . . . . . . 9–8
9.10 End Terminal Risk Management . . . . . . . . . . . . . . . . . . . 9–8
9.12 Subsequent Related Processing . . . . . . . . . . . . . . . . . . 9–11
Chapter 10 • Terminal Action Analysis

10.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–2
10.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . 10–3
10.3 GENERATE APPLICATION CRYPTOGRAM (AC) Command . . . . . . . 10–5
10.4 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 10–6
10.4.1 Review Offline Processing Results . . . . . . . . . . . . . . . 10–6
10.4.2 Request Application Cryptogram . . . . . . . . . . . . . . . . 10–9
10.4.3 Process Flow . . . . . . . . . . . . . . . . . . . . . . . 10–10
Chapter 11 • Card Action Analysis

11.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–2
11.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . 11–3
11.3 GENERATE APPLICATION CRYPTOGRAM (AC) Command . . . . . . . 11–3
11.4 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 11–4
11.4.1 Response to GENERATE AC for Combined DDA/AC Generation . . . 11–4
11.4.2 Standard Response to GENERATE AC . . . . . . . . . . . . . 11–5
vi
Chapter 12 • Online Processing

12.1 Terminal Requirements . . . . . . . . . . . . . . . . . . . . . . 12–2
12.2 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–2
12.2.1 GENERATE AC Response Data . . . . . . . . . . . . . . . . 12–2
12.2.2 Other Card Data . . . . . . . . . . . . . . . . . . . . . . 12–3
12.3 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . 12–3
12.3.1 Online Request Message Data . . . . . . . . . . . . . . . . . 12–4
12.3.2 Online Response Data . . . . . . . . . . . . . . . . . . . . 12–5
12.4 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–6
12.5 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–6
12.5.1 Online Request . . . . . . . . . . . . . . . . . . . . . . . 12–6
12.5.1.1 Combined DDA/AC Generation Processing . . . . . . . . . 12–6
12.5.1.2 Standard Online Processing . . . . . . . . . . . . . . . 12–7
12.5.2 Online Response . . . . . . . . . . . . . . . . . . . . . . 12–8
12.5.3 Issuer Authentication . . . . . . . . . . . . . . . . . . . . . 12–8
12.5.4 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–9
12.6 Prior Related Processing . . . . . . . . . . . . . . . . . . . . 12–10
12.7 Subsequent Related Processing . . . . . . . . . . . . . . . . . 12–10
Chapter 13 • Completion
13.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–2
13.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . 13–4
13.3 GENERATE AC Command . . . . . . . . . . . . . . . . . . . . . 13–4
13.4 Transaction Authorized Offline . . . . . . . . . . . . . . . . . . . 13–5
31 Oct 2001
Draft 12/18/00 Visa Public vii
13.5 Transaction Authorized Online . . . . . . . . . . . . . . . . . . . 13–6
13.5.1 Transmit Final GENERATE AC to the Card . . . . . . . . . . . . 13–6
13.5.2 Terminal Receives Final GENERATE AC Response . . . . . . . . 13–6
13.5.2.1 Issuer-to-Card Script Processing . . . . . . . . . . . . . 13–6
13.5.2.2 Terminal Requested an AAC in the Final GENERATE AC . . . . 13–7
13.5.2.3 Terminal Requested a TC in the Final GENERATE AC . . . . . 13–7
13.6 Online Processing Requested, Transaction Was Not Sent Online . . . . . 13–8
13.6.1 Check IAC and TAC-Default Settings . . . . . . . . . . . . . . 13–8
13.6.2 Issue Final GENERATE AC Command . . . . . . . . . . . . . 13–8
13.6.3 Terminal Completes Transaction . . . . . . . . . . . . . . . . 13–8
13.6.3.1 Terminal Requested AAC in Final GENERATE AC . . . . . . 13–8
13.6.3.2 Terminal Requested TC in Final GENERATE AC . . . . . . . 13–9
Chapter 14 • Issuer-to-Card Script Processing

14.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–2
14.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . 14–2
14.3 Online Response Data . . . . . . . . . . . . . . . . . . . . . . 14–3
14.4 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 14–3
14.5 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 14–4
14.5.1 Issuer Scripts . . . . . . . . . . . . . . . . . . . . . . . 14–4
14.5.2 Multiple Commands . . . . . . . . . . . . . . . . . . . . . 14–4
14.5.3 Script Errors . . . . . . . . . . . . . . . . . . . . . . . . 14–5
14.5.4 Multiple Scripts . . . . . . . . . . . . . . . . . . . . . . 14–5
14.5.5 Issuer Script with Tag “71” . . . . . . . . . . . . . . . . . . 14–5
14.5.6 Terminal Messages . . . . . . . . . . . . . . . . . . . . . 14–5
14.5.7 Issuer Notification . . . . . . . . . . . . . . . . . . . . . 14–5
14.5.8 Process Flow . . . . . . . . . . . . . . . . . . . . . . . 14–5
viii
Appendix A • Terminal and Acquirer Data Elements

A.1 Terminal and Acquirer Data Elements Table . . . . . . . . . . . . . . A–1
A.2 Terminal Data Element Tags . . . . . . . . . . . . . . . . . . . . A–22
Appendix B • Commands for Financial Transactions

B.1 Basic Processing Rules for Issuer Script Commands . . . . . . . . . . . B–2
B.2 EXTERNAL AUTHENTICATE Command—Response APDUs . . . . . . . B–2
B.3 GENERATE APPLICATION CRYPTOGRAM (AC) Command

Response APDUs . . . . . . . . . . . . . . . . . . . . . . . . B–3
B.4 GET CHALLENGE Command—Response APDUs . . . . . . . . . . . . B–3
B.5 GET DATA Command—Response APDUs . . . . . . . . . . . . . . . B–4
B.6 GET PROCESSING OPTIONS Command—Response APDUs . . . . . . . B–5
B.7 INTERNAL AUTHENTICATE Command—Response APDUs . . . . . . . . B–5
B.8 READ RECORD Command—Response APDUs . . . . . . . . . . . . . B–5
B.9 SELECT Command—Response APDUs . . . . . . . . . . . . . . . . B–6
B.10 VERIFY Command—Response APDUs . . . . . . . . . . . . . . . B–7
Appendix C • General Terminal Requirements

C.1 Terminal Types and Capabilities . . . . . . . . . . . . . . . . . . . C–1
C.1.1 Advice Creation . . . . . . . . . . . . . . . . . . . . . . . C–2
C.1.2 Amount Entry and Management . . . . . . . . . . . . . . . . . C–2
C.1.3 Card Reading . . . . . . . . . . . . . . . . . . . . . . . . C–3
C.2 Physical Characteristics . . . . . . . . . . . . . . . . . . . . . . C–4
C.3 Security Requirements . . . . . . . . . . . . . . . . . . . . . . . C–4
C.4 Data Management . . . . . . . . . . . . . . . . . . . . . . . . C–4
C.5 Cardholder and Attendant Interface . . . . . . . . . . . . . . . . . . C–5
C.5.1 Receipt . . . . . . . . . . . . . . . . . . . . . . . . . . C–5
C.6 Acquirer Interface . . . . . . . . . . . . . . . . . . . . . . . . . C–5
31 Oct 2001
Draft 12/18/00 Visa Public ix
Appendix D • Terminal Requirements for Visa Low-Value Payment

Feature
D.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . .D–2
D.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . .D–3
D.3 Terminal Requirements . . . . . . . . . . . . . . . . . . . . . . .D–4
D.4 VLP Purchase Transaction Process . . . . . . . . . . . . . . . . . .D–4
D.4.1 VLP Transaction With VLP-Capable Card at a VLP-Capable

Terminal . . . . . . . . . . . . . . . . . . . . . . . . . .D–4
D.4.2 VSDC Transaction With a Non-VLP-Capable Card at a

VLP-Capable Terminal . . . . . . . . . . . . . . . . . . . . .D–9
D.5 VLP Reset Transaction Processing . . . . . . . . . . . . . . . . . .D–9
D.5.1 VSDC Online-Capable Terminal . . . . . . . . . . . . . . . . .D–9
D.5.2 Dedicated Online Unattended Terminal—VLP Reset-Capable . . . . . .D–9
Appendix E • Acronyms
Glossary
Index
x
Figures
2–1: Sample Transaction Flow . . . . . . . . . . . . . . . . . . . 2–6

3–1: Directory Selection Method Example . . . . . . . . . . . . . . . . 3–8
3–2: Application Selection Processing Flow (1 of 3) . . . . . . . . . . . . 3–12
4–1: Initiate Application Processing Flow . . . . . . . . . . . . . . . . 4–5
5–1: Read Application Data Processing Flow . . . . . . . . . . . . . . . 5–4
6–1: SDA or DDA Determination . . . . . . . . . . . . . . . . . . . 6–6
6–2: SDA Flow . . . . . . . . . . . . . . . . . . . . . . . 6–11
6–3: DDA Flow (1 of 3) . . . . . . . . . . . . . . . . . . . . . 6–20
6–4: DDA Flow (2 of 2) . . . . . . . . . . . . . . . . . . . . . 6–21
6–5: DDA Flow (3 of 3) . . . . . . . . . . . . . . . . . . . . . 6–22
7–1: Processing Restrictions Flow . . . . . . . . . . . . . . . . . . 7–7
8–1: CVM List Processing . . . . . . . . . . . . . . . . . . . . 8–12
8–2: PIN Try Counter Checking . . . . . . . . . . . . . . . . . . 8–15
8–3: Offline PIN Processing . . . . . . . . . . . . . . . . . . . 8–18
8–4: Offline Enciphered PIN Processing . . . . . . . . . . . . . . . 8–20
8–5: Online PIN Processing . . . . . . . . . . . . . . . . . . . 8–21
8–6: Signature Processing . . . . . . . . . . . . . . . . . . . 8–22
8–7: Fail CVM Processing . . . . . . . . . . . . . . . . . . . . 8–22
8–8: No CVM Required Processing . . . . . . . . . . . . . . . . . 8–23
9–1: Terminal Risk Management Processing Flow (1 of 2) . . . . . . . . . . . 9–9
9–2: Terminal Risk Management Processing Flow (2 of 2) . . . . . . . . . . 9–10
10–1: Terminal Action Analysis . . . . . . . . . . . . . . . . . . . 10–10
12–1: Online Processing . . . . . . . . . . . . . . . . . . . . . 12–9
31 Oct 2001
Draft 12/18/00 Visa Public xi
Figures Visa Integrated Circuit Card
13–1: Completion Processing Flow . . . . . . . . . . . . . . . . . . 13–10

14–1: Issuer-to-Card Script Processing . . . . . . . . . . . . . . . . 14–6
D–1: VLP Transaction Flow . . . . . . . . . . . . . . . . . . . . D–8
xii
Tables
2–1: Terminal Functional Requirements . . . . . . . . . . . . . . . . 2–7

2–2: Command Support Requirements . . . . . . . . . . . . . . . . . 2–9
3–1: Application Selection—Card Data . . . . . . . . . . . . . . . . . 3–2
3–2: Application Selection—Terminal Data . . . . . . . . . . . . . . . 3–4
3–3: Application Selection Indicator Matching Criteria . . . . . . . . . . . . 3–6
3–4: Sample AIDs Matching . . . . . . . . . . . . . . . . . . . . 3–9
4–1: Initiate Application Processing—Card Data . . . . . . . . . . . . . . 4–2
4–2: Initiate Application Processing—Terminal Data . . . . . . . . . . . . . 4–3
5–1: Read Application Data—Card Data . . . . . . . . . . . . . . . . 5–2
5–2: Read Application Data—Card Files . . . . . . . . . . . . . . . . 5–2
6–1: Terminal Data Used in SDA or DDA Determination . . . . . . . . . . . 6–4
6–2: Card Data Used in SDA or DDA Determination . . . . . . . . . . . . 6–5
6–3: Offline Data Authentication—SDA Card Data . . . . . . . . . . . . . 6–7
6–4: Offline Data Authentication—SDA Terminal Data . . . . . . . . . . . . 6–8
6–5: Offline Data Authentication—DDA Card Data . . . . . . . . . . . . 6–12
6–6: Offline Data Authentication—DDA Card Data in INTERNAL
AUTHENTICATE Response . . . . . . . . . . . . . . . . . 6–13
6–7: Offline Data Authentication—DDA Terminal Data . . . . . . . . . . . 6–13
7–1: Processing Restrictions—Card Data . . . . . . . . . . . . . . . . 7–2
7–2: Processing Restrictions—Terminal Data . . . . . . . . . . . . . . . 7–3
7–3: Application Usage Control (AUC) . . . . . . . . . . . . . . . . . 7–5
8–1: CVM List Processing—Card Data . . . . . . . . . . . . . . . . . 8–3
8–2: Offline PIN—Card Data . . . . . . . . . . . . . . . . . . . . 8–5
8–3: Offline Enciphered PIN—Card Data . . . . . . . . . . . . . . . . 8–5
8–4: Offline PIN Processing—Card Data . . . . . . . . . . . . . . . . 8–6
31 Oct 2001
Draft 12/18/00 Visa Public xiii
Tables Visa Integrated Circuit Card
8–5: CVM Processing—Terminal Data . . . . . . . . . . . . . . . . 8–7

8–6: Offline Enciphered PIN—Terminal Data . . . . . . . . . . . . . . 8–8
9–1: Terminal Risk Management—Card Data . . . . . . . . . . . . . . 9–3
9–2: Terminal Risk Management—Terminal Data . . . . . . . . . . . . . 9–4
9–3: Example Terminal Parameters . . . . . . . . . . . . . . . . . 9–6
10–1: Offline Processing Results—Card Data . . . . . . . . . . . . . . 10–2
10–2: Request Application Cryptogram—Card Data . . . . . . . . . . . . 10–3
10–3: Offline Processing Results—Terminal Data . . . . . . . . . . . . . 10–3
10–4: Request Application Cryptogram—Terminal Data . . . . . . . . . . . 10–5
11–1: Card Action Analysis—Card Data . . . . . . . . . . . . . . . . 11–2
11–2: GENERATE AC Command Response Data . . . . . . . . . . . . . 11–2
11–3: Card Action Analysis—Terminal Data . . . . . . . . . . . . . . . 11–3
11–4: Card’s Response to First GENERATE AC Command . . . . . . . . . . 11–4
12–1: Online Processing—GENERATE AC Response Card Data . . . . . . . . 12–2
12–2: Online Processing—Other Card Data . . . . . . . . . . . . . . . 12–3
12–3: Online Processing—Terminal Data . . . . . . . . . . . . . . . . 12–3
12–4: Visa Smart Debit Credit (VSDC) Data Objects Required in Online Message . . . 12–4
12–5: New Authorization/Financial Transaction Response Data Elements . . . . . 12–5
13–1: Completion—Card Data . . . . . . . . . . . . . . . . . . . 13–2
13–2: Completion—Final GENERATE AC Response Data . . . . . . . . . . 13–3
13–3: Completion—Terminal Data . . . . . . . . . . . . . . . . . . 13–4
13–4: Offline Transaction Disposition Response . . . . . . . . . . . . . 13–5
13–5: Online Transaction Disposition Response . . . . . . . . . . . . . 13–8
14–1: Issuer-to-Card Script Processing—Terminal Data . . . . . . . . . . . 14–2
14–2: Issuer-to-Card Script Processing—Online Response Data . . . . . . . . 14–3
A–1: Terminal and Acquirer Data Elements . . . . . . . . . . . . . . . A–2
A–2: Terminal Data Element Tags . . . . . . . . . . . . . . . . . . A–22
B–1: Data Retrieval Using GET DATA . . . . . . . . . . . . . . . . B–4
B–2: Data Retrieval With GET PROCESSING OPTIONS . . . . . . . . . . B–5
D–1: Initiate Application Processing—Card Data . . . . . . . . . . . . . D–2
D–2: Initiate Application Processing—Card Data . . . . . . . . . . . . . D–3
D–3: Terminal TACs for VLP . . . . . . . . . . . . . . . . . . . D–6
xiv
About This Specification 1
The Visa Integrated Circuit Card Specification (VIS) provides the technical
details of chip card and terminal functionality related to Visa Smart Debit
and Visa Smart Credit (VSDC) transactions, Visa’s chip-based credit and
debit programs. It focuses on the functions performed by the chip card and
terminal as well as the interaction between the chip card and terminal at the
point of transaction.
The objective of the Visa Integrated Circuit Card Specification is to:
●
Communicate the implementation details of Europay, MasterCard, and
Visa (EMV) specifications to ease vendor development efforts
● Aid members and vendors in understanding the changes that chip brings
to the credit and debit payment services, especially in terms of the
processing taking place between the chip card and terminal at the point of
transaction
●
Provide Visa’s minimum requirements for chip-based credit and debit
programs
● Identify options that members and vendors can implement to meet
market needs
● Support Visa’s payment service rules and International Operating
Regulations for Visa Smart Debit and Visa Smart Credit (VSDC)
●
Define Visa’s implementation of optional EMV features
Because VIS is based on EMV, the two specifications should be used together
for reference and development purposes. However, VIS builds on the EMV
requirements in order to support the Visa payment service rules. To facilitate
understanding of the differences between these two specifications, please
refer to Chapter 2, Processing Overview.
31 Oct 2001
Draft 12/18/00 Visa Public 1–1
About This Specification Visa Integrated Circuit Card
1.1 Audience
This document is intended for members, vendors, and readers seeking a
technical understanding of the functionality of chip cards and terminals
supporting Visa Smart Debit and Visa Smart Credit programs.
1.2 VIS Update

This document serves as an update to VIS 1.3.2. The update includes changes
reflecting EMV 2000 Integrated Circuit Card Specification for Payment
Systems, Version 4.0, enhancements to VSDC functionality, and corrections
and clarifications to VIS 1.3.2. An impacts summary highlighting the
differences between VIS 1.3.2 and the current version, VIS 1.4.0, is provided
later in this chapter.
1–2
Visa Integrated Circuit Card 1.3 Terminology
1.3 Terminology
This section provides clarification on several terms used throughout the
specification.
1.3.1 Mandatory/Required/Recommended/Optional
Visa’s philosophy is to facilitate market requirements while ensuring global
interoperability. To this end, Visa’s minimum requirements reflect the EMV
mandatory items in addition to specific requirements outlined in the Visa
payment service rules or International Operating Regulations. All other
functionality is optional and not required.
Visa’s minimum requirements are designated using the terms “mandatory”,
“required”, and “shall.” Recommended functionality is designated in the
document using the term “should.” Elective data elements and functions are
designated using the terms “optional” or “may.”
Markets can customize their programs beyond the minimum requirements
through adoption of the optional functions and through proprietary
processing. Proprietary processing, however, must not interfere with global
interoperability.
1.3.2 Card/Integrated Circuit

In general, the term “card” is used to describe functions performed by the
VSDC application on the card. When it is necessary to distinguish between
the chip itself and another card feature such as the magnetic stripe, the term
“integrated circuit” may be used.
1.3.3 Terminated Transactions

When the term “terminal terminates transaction” is used, it includes the
processing to end the transaction and the display of the message to the
cardholder and merchant indicating why the transaction cannot be completed.
31 Oct 2001
1.4 Document Structure

This section provides an overview of the structure of the Visa Integrated
Circuit Card Specification. It begins with an overview of the three volumes, is
followed by an overview of each chapter, and concludes with the sub-heading
structure of each chapter.
1.4.1 Volume Overview

The document is organized into three volumes:
● Application Volume—This volume provides a technical overview of the
processing between the card and terminal. This volume may be used as an
overview to understand the processing and sequence of events involved in
a VSDC transaction flow.
● Card Volume—This volume specifies the technical details of EMV
related to the data and processing performed by the card. It also includes
additional Visa specific requirements for card functionality. Vendors
involved in the creation of the VSDC card application should focus on this
document for their development efforts.
● Terminal Volume—This volume specifies the technical details of EMV
related to the data and processing performed by the terminal. It also
includes additional Visa specific requirements for terminal functionality.
Vendors involved in the creation of the VSDC terminal application should
focus on this document for their development efforts.
To provide clarity, requirements from EMV may be restated in the various
volumes and, where necessary, information is replicated in the three volumes
to provide comprehensive information. Each volume includes a list of
acronyms, a glossary, and an index.
1.4.2 Chapter Overview

This guide is organized according to the functions that occur during VSDC
transaction flow and is divided into the following sections:
Chapter 1, About This Specification—This chapter provides an overview
of the VIS specification, VIS terminology, a summary of revisions for this
version of the VIS documents, and a list of reference materials.
Chapter 2, Processing Overview—This chapter provides an overview of
the each function and highlights whether the function is mandatory or
optional.
Chapter 3, Application Selection—This function determines which of the
applications, supported by both the card and terminal, will be used to conduct
the transaction.
1–4
Visa Integrated Circuit Card 1.4 Document Structure
Chapter 4, Initiate Application Processing—During this function, the

card receives any terminal data which was requested by the card during
Application Selection.
Chapter 5, Read Application Data—During this function, the terminal
reads the data records necessary for the transaction from the card.
Chapter 6, Offline Data Authentication—During this function, the
terminal authenticates data from the card using RSA public key technology.
Chapter 7, Processing Restrictions—During this function, application
version checks, effective and expiration dates checks, and other checks are
performed by the terminal at the point of transaction.
Chapter 8, Cardholder Verification—During this function, the terminal
determines the Cardholder Verification Method (CVM) to be used and
performs the selected CVM.
Chapter 9, Terminal Risk Management—During this function, the
terminal ensures that higher-value transactions are sent online and that chip
read transactions go online periodically. This risk management check protects
against threats that might be undetectable in an offline environment.
Chapter 10, Terminal Action Analysis—During this function, the terminal
applies rules set by the issuer in the card and by the acquirer in the terminal
to the results of offline processing. This analysis determines whether the
transaction should be approved offline, declined offline, or sent online for an
authorization.
Chapter 11, Card Action Analysis—During this function, velocity checking
and other risk management, internal to the card, is performed.
Chapter 12, Online Processing—During this function, the issuer’s host
computer reviews and authorizes or rejects transactions using the issuer’s
host-based risk parameters.
Chapter 13, Completion—During this function, the card and the terminal
conclude transaction processing.
Chapter 14, Issuer-to-Card Script Processing—During this function, the
card applies post-issuance changes sent from the issuer.
Appendix A, Data Elements—This appendix defines the data elements
used in processing the VSDC application from a terminal perspective.
Appendix B, Commands for Financial Transactions—This appendix
outlines the commands used during transaction processing.
Appendix C, General Terminal Requirements—This appendix lists the
requirements for VSDC terminals, which are in addition to the requirements
listed in the functional chapters.
31 Oct 2001
Appendix D, Terminal Requirements for Visa Low-Value Payment

Feature (VLP)—This appendix describes terminal requirements for an
optional source of pre-authorized spending power on the card for rapid
processing of low-value payments.
Appendix E, Acronyms—This appendix lists acronyms and their meanings.
This document also contains a glossary and an index.
1.4.3 Subheading Overview

For ease of use, the main chapters are structured in the same manner:
● Card Data—Provides the mandatory and optional data elements
required on the card to support the function. Data element tags are listed
when multiple tags are associated with a single data element name.
● Terminal Data—Provides the mandatory and optional data elements
needed in the terminal to support the function. Data element tags are
listed when multiple tags are associated with a single data element name.
● Commands—Provides the requirements for the commands used to
support the function.
● Processing—Provides the technical details of the function. If there are
several functions within a process, they may be listed separately.
NOTE: Flowcharts are representative of processing and may not include
all steps that may be performed.
● Prior Related Processing—Outlines prior processing to aid in
understanding previous activities related to this function.
● Subsequent Related Processing—Outlines subsequent processing to
aid in understanding future activities related to this function.
1.5 Revisions to This Specification

Revisions to this specification may be required to accommodate future EMV
changes, Visa payment service rules, or market needs. The impacts of these
changes will be communicated in the VIS changes list or in an update to this
document.
1–6
Visa Integrated Circuit Card 1.6 Impact Summary
1.6 Impact Summary

The following is an outline of changes and additional functionality from both a
card and terminal perspective for VIS 1.4.0 (April 2001).
1.6.1 Terminal
This section includes mandatory and optional changes. The testing of
terminals to support mandatory changes shall be aligned with the EMV 2000,
Version 4.0, migration requirements. Refer to the EMVCo website for
information on testing schedules.
1.6.1.1 Mandatory
● If the Directory method of Application Selection fails, the terminal shall
switch to the List of AIDs method.
● The terminal shall not allow Partial Selection during Application
Selection if the terminal indicators show it is not supported for the AID.
● During SDA and DDA, the terminal shall save the Data Authentication
Code (if present) and ICC Dynamic Number after recovery.
● If the SDA Tag List is one of the data elements read from the card, the
terminal shall validate that the only tag it contains is the tag for the AIP.
● ATMs supporting Offline PIN shall support CVM List processing.
1.6.1.2 Optional
● Visa Operating Regulations may permit the terminal to eliminate certain
common applications from consideration during Application Selection.
● The EMV Combined DDA/Generate AC option is included as a terminal
option.
● The public key encipherment used in the Offline Enciphered PIN
processing may occur either in the PIN pad or in the card reader. Secure
transfer of the PIN from the PIN pad to the card reader is required.
● Terminal support for Visa Low-value Payment feature of VSDC.
31 Oct 2001
1.6.2 Card
This section includes mandatory and optional changes. Contact the CAA for
information on testing schedules. Changes are backward compatible and cards
tested under versions 1.3.1 and 1.3.2 will continue to work in the new devices.
1.6.2.1 Mandatory
● If a card is personalized with an SDA Tag List, the only tag in the list
must be “82”, the tag for the Application Interchange Profile. Prior to
adding this requirement to EMV a survey was conducted to determine if
the SDA tag list was being used. The results indicated that it was not in
use and that the requirement could be added to EMV. To ensure
interoperability and backward compatibility, cards should begin
compliance immediately. An SDA tag list that does not comply will result
in Offline Data Authentication failure in EMV 4.0 terminals.
● Support of Cardholder Verification must be indicated in the Application
Interchange Profile, and a CVM List is required.
● Cumulative amounts are no longer incremented for offline declines.
● The Online Authorization Indicator is no longer reset after offline
approval.
1.6.2.2 Optional
● The Issuer Public Key length may equal that of the corresponding Visa CA
Public Key.
● The ICC Public Key length may equal that of the corresponding Issuer
Public Key.
● The EMV Combined DDA/Generate AC option is included as a VSDC card
option.
●
The EMV optional session key generation method is referenced as a VIS
option.
● A new cryptogram generation method, Cryptogram Version 14, is
referenced as a VIS option.
NOTE: Cryptogram Version 14 is not currently supported in VisaNet
systems and Issuers wishing to implement this option must be
aware that they will not be eligible for VisaNet Authentication
Services.
1–8
Visa Integrated Circuit Card 1.6 Impact Summary
● The Online Authorization indicator is optional in the card unless Issuer

Authentication or Issuer Script processing is supported.
● The Visa Low-value Payment feature of VSDC has been added.
●
A Cumulative Total Transaction Amount Upper Limit has been added.
● An Application Default Action bit has been added to allow issuers to send
transactions online if issuer script processing failed on a previous
transaction.
● An Application Default Action bit has been added to allow issuers to
decline transactions and block the application if the PIN Try Limit was
exceeded on a previous transaction.
31 Oct 2001
1.7 Reference Materials

The following documents contain additional information on Visa Smart Debit
and Visa Smart Credit. The websites for obtaining these documents or
information on obtaining them are listed below. For additional information,
contact your Visa member representative.
1.7.1 International Organisation for Standardisation (ISO) Documents

Information on ordering these documents is available on
http://www.iso.ch
● ISO 639:1988. Codes for the Representation of Names and Languages.
● ISO 3166:1997. Codes for the Representation of Names of Countries.
● ISO 4217:1995. Codes for the Representation of Currencies and Funds.
● ISO/IEC 7810:1995. Identification Cards—Physical Characteristics.
● ISO/IEC 7811:1995. Identification Cards—Recording Technique.
● ISO/IEC 7812:1994. Identification Cards—Identification of Issuers.
● ISO/IEC 7813:1995. Identification Cards—Financial Transaction Cards
● ISO/IEC 7816-4:1995. Identification Cards—Integrated Circuit Cards
with Contacts—Part 4: Interindustry Commands for Interchange.
● ISO/IEC 7816-5:1994. Identification Cards—Integrated Circuit Cards
with Contacts—Part 5: Numbering System and Registration Procedure for
Application Identifiers.
● 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 8859:1987. Information Processing—8-bit Single-Byte Coded Graphic
Character Sets.
●
ISO 9564:1991. Banking—Personal Identification Number Management
and Security.
1–10
Visa Integrated Circuit Card 1.7 Reference Materials
1.7.2 EMV Documents

Available on the EMVCo Website:
http://www.emvco.com/specifications.cfm
● EMV 2000 Integrated Circuit Card Specification for Payment Systems,
Version 4.0, Book 1, Application Independent ICC to Terminal Interface
Requirements, December, 2000.
● EMV 2000 Integrated Circuit Card Specification for Payment Systems,
Version 4.0, Book 2, Security and Key Management, December, 2000.
● EMV 2000 Integrated Circuit Card Specifications for Payment Systems,
Version 4.0, Book 3, Application Specification, December, 2000.
● EMV 2000 Integrated Circuit Card Specifications for Payment Systems,
Version 4.0, Book 4, Cardholder, Attendant and Acquirer Interface
Requirements, December, 2000.
1.7.3 Visa Documents

Available on the Visa website:
http://wwws2.visa.com/nt/chip/visdownload.html
● Visa Integrated Card Specification (Application Overview, Card
Specification, and Terminal Specification) (VIS - versions 1.3.2 and 1.4.0)
● VIS Corrections and Updates
Available on the Visa website:
http://visa.com/nt/suppliers/vendor
● Chip Card Products: Submission Requirements—Describes Visa
International requirements for approval of new and upgraded chip card
products.
Visa supports and recognizes approvals by EMVCo, LLC for EMV level 1
(Interface Module) and EMV level 2 (device application). EMVCo is the
owner of the EMV Integrated Circuit Card Specifications for Payment
Systems.
EMVCo specifications, type approval administrative documentation, test
requirements and test cases for EMV levels 1 and 2 may be obtained
through the EMVCo website www.emvco.com.
● Chip Card Products: Testing and Approval Requirements—Describes Visa
International requirements for approval of new and upgraded chip card
products. It summarized Visa’s present testing services, policies, and
pricing.
31 Oct 2001
● Common Personalization—A guide to a common approach to

personalization of all applications.
NOTE: This guide is the final authority for non-application specific
requirements.
Available on Visa InSite Global Products eLibrary:
(http://insite/global/Consumer Platform Search/content) or through a
regional representative:
● Certificate Authority User’s Guide—Visa Smart Debit and Visa Smart
Credit, Visa Cash—Information and procedures related to the Visa
Certificate Authority including Visa Certificate Authority Public Keys and
Issuer Public Key Certificates.
● Common Personalization for Visa Smart Debit and Credit (VSDC)—A
guide to personalization of VSDC Applications using the Common
Personalization Approach.
NOTE: The Visa Smart Debit and Visa Smart Credit Personalization
Templates have been added to this document.
● Visa Smart Debit and Visa Smart Credit Certification Authority Key
Revocation Visa Policies and Procedures—The Visa-specific policies and
procedures related to key revocation.
● Visa Smart Debit and Visa Smart Credit Member Implementation Guide
for Acquirers—Describes best practices, suggestions, considerations, and
step-by-step activities to assist with implementation for VSDC Acquirers.
● Visa Smart Debit and Visa Smart Credit Member Implementation Guide
for Issuers—Describes best practices, suggestions, considerations, and
step-by-step activities to assist with implementation for VSDC Acquirers.
● Visa Smart Debit and Visa Smart Credit Planning Guide—A reference
guide and roadmap for Acquirers and Issuers implementing Visa Smart
Debit or Visa Smart Credit programs. It describes the components and
decisions necessary for program implementation and focuses on what is
new and different about implementing a Visa Smart Debit or Visa Smart
Credit program.
● VSDC Service Activation Guide (SAG)—Describes planning
considerations, business aspects, technical aspects and other regional
tasks associated with completing a member implementation of VSCD.
● Visa Smart Debit/Visa Smart Credit Service Description—A document
focusing on the features and benefits of the service.
1–12
Visa Integrated Circuit Card 1.7 Reference Materials
Available on Visa InSite or through a Visa regional representative:

http://insite/ref/docs
● Card Acceptance Device Reference Guide: Requirements and Best Practices
Version 5.0—Provides vendors with insight towards designing their card
acceptance devices to meet current and future industry and Visa scheme
specific requirements and best practices.
● Visa Certification Management Service (VCMS) Testing and Certification
Guide-VIP System, Member Version—A guide for the VIP System
component of the VisaNet Certification Management System.
● Visa Certification Management Service (VCMS) User’s Manual-BASE II
System—A guide for the BASE II System component of the VisaNet
Certification Management System.
● VisaNet Card Technology Standards Manual—The standards applied to
PINs, PIN-related security, and the management of cryptographic keys as
well as the guidelines for encoding account and cardholder data on
Track 1 and Track 2 of the magnetic stripe of a Visa card.
http://insite/dept/buspubs1/library/vsmart/techlet.pdf
● Visa Smart Debit and Visa Smart Credit System Technical Manual—A
document that describes the changes to VisaNet to support VSDC.
http://insite/dynaweb/opregs
● Visa International Operating Regulations—Specifies standards all
Members must meet to operate and participate in Visa Payment Services
(Volumes I-IV).
Available through Visa regional representative:
● Visa Smart Debit/Credit Certificate Authority Internal
Procedures—Describes guidelines for enrolling the Visa Certificate
Authority and is intended for use by Regional staff supporting VSDC.
● Visa Smart Payment Operating Principles Guide—Board-approved
payment service principles for Visa Smart Debit and Visa Smart Credit.
Available by request to the VSDC Hotline:
●
Visa Smart Debit/Visa Smart Credit Early & Full Data Options for Host
Systems—Provide Member center managers with an overview of the Early
and Full options for their host systems.
31 Oct 2001
Processing Overview 2
This chapter provides an overview of a Visa Smart Debit and Visa Smart
Credit (VSDC) transaction. This is followed by a transaction flow showing the
order in which these functions may be performed and the commands sent by
the terminal to the card for communications. Charts at the end of the chapter
show functional and command support requirements for cards and terminals.
Regions may have additional restrictions and requirements.
2.1 Functional Overview

The following functions are used in VSDC transaction processing. Functions
marked as mandatory are performed for all transactions. Some steps within
these mandatory functions may be optional. Functions not marked mandatory
are optional and are performed based upon parameters in the card or
terminal, or both.
2.1.1 Application Selection (mandatory)

When a VSDC card is presented to a terminal, the terminal determines which
applications are supported by both the card and terminal. The terminal
displays all mutually supported applications to the cardholder, and the
cardholder selects the application to be used for payment. If these
applications cannot be displayed, the terminal selects the highest priority
application as designated by the issuer during card personalization.
31 Oct 2001
Processing Overview Visa Integrated Circuit Card
2.1.2 Initiate Application Processing/Read Application Data

(mandatory)
If a VSDC application is selected, the terminal requests that the card indicate
the data to be used for that application and the functions supported. The card
may indicate different data or different support functions based upon
characteristics of the transaction such as being domestic or international. The
terminal reads the data indicated by the card and uses the supported function
list to determine the processing to perform.
2.1.3 Offline Data Authentication

The terminal determines whether it should authenticate the card offline using
either offline static or dynamic data authentication based upon the card and
terminal support for these methods.
Offline Static Data Authentication (SDA) validates that important application
data has not been fraudulently altered since card personalization. The
terminal validates static (unchanging) data from the card using the card’s
Issuer Public Key, which is stored on the card inside a public key certificate
and a digital signature, which contains a hash of important application data
encrypted with the Issuer Private Key. A match of the recovered hash with a
generated hash of the actual application data proves that the data has not
been altered.
Offline Dynamic Data Authentication (DDA) validates that the card data has
not been fraudulently altered and that the card is genuine. DDA has two
forms: Standard DDA and Combined DDA/Generate AC. In both forms, the
terminal verifies the card static data in a similar manner to SDA.
With Standard DDA, the terminal requests that the card generate a
cryptogram using dynamic (transaction unique) data from the card and
terminal and an ICC Private Key. The terminal decrypts this dynamic
signature using the ICC Public Key recovered from card data. A match of the
recovered data to the original data verifies that the card is not a counterfeit
card created with data skimmed (copied) from a legitimate card.
With Combined DDA/Generate AC, the generation of the dynamic signature is
combined with the generation of the card’s Application Cryptogram during
Card Action Analysis to assure that the Application Cryptogram came from
the valid card.
2–2
Visa Integrated Circuit Card 2.1 Functional Overview
2.1.4 Processing Restrictions (mandatory)

The terminal performs Processing Restrictions to see whether the transaction
should be allowed. The terminal checks whether the effective date for the card
has been reached, whether the card is expired, whether the application
versions of the card and terminal match, and whether any Application Usage
Control restrictions are in effect. An issuer may use Application Usage
Controls to restrict a card’s use for domestic or international, cash, goods,
services, or cashback.
2.1.5 Cardholder Verification (mandatory)

Cardholder verification may be used to ensure that the cardholder is
legitimate and the card is not lost or stolen. The terminal uses a Card
Verification Method (CVM) List from the card to determine the type of
verification to be performed. The CVM List establishes a priority of cardholder
verification methods, which consider the capabilities of the terminal and
characteristics of the transaction to prompt the cardholder for a specific
cardholder verification method. If the CVM is offline PIN, the terminal
prompts the cardholder for a PIN and transmits the cardholder-entered PIN
to the card, which compares it to a Reference PIN stored secretly in the card.
The CVM List may also specify online PIN, signature, or no cardholder
verification required.
The terminal may use a default CVM as defined by Visa International
Operating Regulations if the card does not support CVM processing, no CVM
list is present or the last CVM processed in the card list is no CVM required.
2.1.6 Terminal Risk Management (mandatory)

Terminal Risk Management checks whether the transaction is over the
merchant floor limit, the account number is on an optional terminal exception
file, the limit for consecutive offline transactions has been exceeded, the card
is a new card, or the merchant has forced the transaction online. Some
transactions are randomly selected for online processing.
Terminal Risk Management also includes optional velocity checking by the
terminal using data elements from the card. The card data elements used are
those defined by EMV. Terminal velocity checking results are considered
during Terminal Action Analysis.
Visa recommends support for velocity checking by the card and the data
elements used card velocity checks are defined by Visa. Card velocity checking
results are considered during Card Action Analysis.
31 Oct 2001
2.1.7 Terminal Action Analysis (mandatory)

Terminal Action Analysis uses the results of Offline Data Authentication,
Processing Restrictions, Terminal Risk Management, and Cardholder
Verification and rules set in the card and terminal to determine whether the
transaction should be approved offline, sent online for authorization, or
declined offline. The card rules are set in fields called Issuer Action Codes
(IACs) sent to the terminal by the card and the terminal rules are in Terminal
Action Codes (TACs). After determining the transaction disposition, the
terminal requests an application cryptogram from the card. The type of
application cryptogram is based upon the transaction disposition with a
Transaction Certificate (TC) for an approval, an Authorization Request
Cryptogram (ARQC) for online, and an Application Authentication
Cryptogram (AAC) for a decline. The terminal includes an indicator in the
request message to the card if Combined DDA/AC Generation is to be
performed and the card has not requested Terminal Capabilities data from the
terminal.
2.1.8 Card Action Analysis (mandatory)

Upon receiving the application cryptogram request from the terminal, the
card performs Card Action Analysis where Card Risk Management checks
may be performed to determine whether to change the transaction disposition
set by the terminal. These may include checks for prior incomplete online
transactions, failure of Issuer Authentication or offline data authentication
failure on a previous transaction, and count or amount velocity checking
limits being reached. The card may convert a terminal request for an offline
approval to an online transaction or an offline decline, and the card may
convert an online request to an offline decline.
After completion of the checks, the card generates the application cryptogram
using application data and a secret DES key stored on the card. It returns this
cryptogram to the terminal. For offline approved transactions, the TC and the
data used to generate it are transmitted in the clearing message for future
cardholder disputes, or chargeback purposes, or both. The TC may be used as
a ‘proof ’ of transaction when a cardholder disputes a transaction and to verify
that the transaction data has not been changed by the merchant or acquirer.
For offline declined transactions, the cryptogram type is an AAC.
2.1.9 Online Processing

If the card and terminal determine that the transaction requires an online
authorization, the terminal transmits an online authorization message to the
issuer if the terminal has online capability. This message includes the ARQC
cryptogram, the data used to generate the ARQC, and indicators showing
offline processing results. During online processing, the issuer validates the
2–4
Visa Integrated Circuit Card 2.1 Functional Overview
ARQC to authenticate the card in a process called Online Card Authentication

(CAM). The issuer may consider these CAM results and the offline processing
results in its authorization decision.
The authorization response message transmitted back to the terminal may
include an issuer-generated Authorization Response Cryptogram (ARPC)
(generated from the ARQC, the Authorization Response Code, and the card’s
secret DES key). The response may also include post-issuance updates to the
card called Issuer Scripts.
If the authorization response contains an ARPC and the card supports Issuer
Authentication, the card performs Issuer Authentication by validating the
ARPC to verify that the response came from the genuine issuer (or its agent).
Successful Issuer Authentication may be required for resetting certain
security-related parameters in the card. This prevents criminals from
circumventing the card’s security features by simulating online processing
and fraudulently approving a transaction to reset counters and indicators. If
Issuer Authentication fails, subsequent transactions for the card will be sent
online for authorization until Issuer Authentication is successful.
2.1.10 Issuer-to-Card Script Processing

If the issuer includes script updates in the authorization response message,
the terminal passes the script commands to the card. Prior to applying the
updates, the card performs security checking to assure that the script came
from the valid issuer and was not altered in transit. Supported script
commands allow updating offline processing parameters, blocking and
unblocking the application, blocking the card, resetting the Offline PIN Try
Counter, and changing the Offline PIN value.
2.1.11 Completion (mandatory)

The card and terminal perform final processing to complete the transaction.
An issuer-approved transaction may be converted to a decline based upon
Issuer Authentication results and issuer-encoded parameters in the card. The
card uses the transaction disposition, Issuer Authentication results, and
issuer-encoded rules to determine whether to reset card-based counters and
indicators. The card generates a TC for approved transactions and an AAC for
declined transactions.
If the terminal transmits a clearing message subsequent to an authorization
message, the TC is transmitted in the clearing message. With single message
systems or systems involving acquirer host data capture of approved
transactions, the terminal must generate a reversal for issuer-approved
transactions which are subsequently declined by the card.
31 Oct 2001
Figure 2–1: Sample Transaction Flow
KEY Card Terminal
Mandatory SELECT
process List of Supported Command/Response
Application Selection
Applications READ RECORD
Command/Response
Mandatory
Supported Functions
process w/ GET PROCESSING OPTIONS Initiate Application
& Pointers to
optional Command/Response Processing
Application Data
steps
Provide Application READ RECORD Read Application

Optional Records Commands/Responses Data
process
1 Offline Data
Generate Dynamic INTERNAL AUTHENTICATE
Authentication
1 - If DDA Cryptogram Command/Response SDA or DDA
2 - If Offline
Enciphered
PIN
3 - Optional for Processing
Offline PIN Restrictions
4 - If Offline PIN
Generate Unpred.
Number 2
GET CHALLENGE Command/Response
3 Cardholder
PIN Try Counter GET DATA Command/Response Verification
4
Validate PIN VERIFY Command/Response
Last Online
Application GET DATA Terminal Risk
Transaction Counter Command/Response Management
(ATC) Register
GENERATE APPLICATION Terminal Action

CRYPTOGRAM Command Analysis
Perform Card Action

Analysis & generate GENERATE APPLICATION Online
Application CRYPTOGRAM Response Transaction?
Cryptogram
Online Processing
N
Validate ARPC EXTERNAL AUTHENTICATE
Issuer Authentication
Cryptogram Command/Response
Perform final checks GENERATE APPLICATION

& generate final CRYPTOGRAM Completion
cryptogram Command/Response
Issuer-to-Card Script Issuer-to-Card Script

Apply Script
Commands/Responses Processing
2–6
Visa Integrated Circuit Card 2.2 Terminal Mandatory and Optional Functionality
2.2 Terminal Mandatory and Optional Functionality

VSDC terminals are required to support the following mandatory functions.
Optional functions may be supported at the merchant or acquirer’s discretion
or may be required by market, regional, or Visa operating regulations.
Support for conditional functions is required if the associated condition is
true. Terminal functional requirements are shown in Table 2–1.
Table 2–1: Terminal Functional Requirements (1 of 2)
Function Terminal Support
Application Selection Mandatory

● Directory Method Optional (EMV)
● Explicit Selection Method Mandatory (EMV)
● Implicit Selection Method Not used for financial interchange (EMV)
Initiate Application Processing Mandatory (EMV)
Offline Data Authentication Conditional—If offline capable (EMV)

● SDA Conditional—If offline capable terminal (EMV) of if DDA supported (EMV)
● Standard DDA Optional (EMV)
Conditional—If Combined DDA/AC Generation supported (VIS) (VIS
recommends Standard DDA for offline capable terminals)
● Combined DDA/AC Generation Optional (EMV)
Processing Restrictions Mandatory (EMV)

● Application Version Number Mandatory (EMV)
● Application Usage Control Mandatory (EMV)
● Effective Date Checking Mandatory (EMV)
● Expiration Date Checking Mandatory (EMV)
Cardholder Verification Mandatory (EMV) with Operating Regulation exceptions (VIS)

●
No CVM Required Mandatory (EMV)
●
Fail CVM Processing Mandatory (EMV)
● Other CVMs (Offline PIN, Optional (EMV)
Online PIN, signature, etc.)
Conditional with Operating Regulation exceptions (VIS)
31 Oct 2001
Table 2–1: Terminal Functional Requirements (2 of 2)
Function Terminal Support
Terminal Risk Management Conditional—If merchant controlled terminal (EMV)

Some functions do not apply for online-only or offline-only terminals (EMV)
●
Terminal Exception File Optional (EMV)
● Merchant Force Online Optional (EMV)
● Floor Limits Mandatory (EMV)
● Transaction Log Optional (EMV)
● Random Selection Conditional—If both online & offline capable (EMV)
● Velocity Checking Conditional—If offline capable (EMV)
● New Card Mandatory—(EMV)
Terminal Action Analysis Mandatory (EMV)
Card Action Analysis n/a (card function)
Online Processing
● Online Capability Optional (EMV and VIS)
● Advice Messages Optional (EMV and VIS)
● Issuer Authentication Conditional—If online capable
Completion Mandatory
Miscellaneous Functions
● Cardholder amount validation Recommended (EMV)
● Voice Referrals Recommended
●
Card initiated referrals Not supported (VIS)
● Merchant forced acceptance Optional (EMV)
●
Chip card informational Optional (EMV)
advices
Conditional—At discretion of country or region (VIS)
● Prompt for chip read Mandatory (EMV)
2–8
Visa Integrated Circuit Card 2.2 Terminal Mandatory and Optional Functionality
2.2.1 Command Support Requirements

Terminal support for the VSDC commands is shown in Table 2–2.
Table 2–2: Command Support Requirements
Command Terminal Support
EXTERNAL AUTHENTICATE Conditional—If online-capable (EMV)
GENERATE APPLICATION Mandatory (EMV)

CRYPTOGRAM (AC)
GET CHALLENGE Conditional—If Offline Enciphered PIN supported (EMV)
GET DATA Conditional—If ATM or merchant controlled device (EMV)
GET PROCESSING OPTIONS Mandatory (EMV)
INTERNAL AUTHENTICATE Conditional—If DDA supported (EMV)
READ RECORD Mandatory (EMV)
Issuer Script Commands If sent from the Issuer, terminal must parse the script into commands and
send them to the card one at a time. The terminal has no knowledge of what
● APPLICATION BLOCK (EMV)
command is being sent. (EMV)
● APPLICATION UNBLOCK (EMV)
● CARD BLOCK (EMV)
● PUT DATA (VIS)
● UPDATE RECORD (VIS)
● PIN CHANGE/UNBLOCK (EMV)
SELECT Mandatory (EMV)
VERIFY Conditional—If Offline PIN supported (EMV)
31 Oct 2001
Application Selection 3
Application Selection is the process of determining which of the applications

that are supported by both the card and terminal will be used to conduct the
transaction. This process takes place in two steps:
1. The terminal builds a candidate list of mutually supported applications.
2. A single application from this list is identified and selected to process the
transaction.
Application Selection shall be performed as described in the EMV 2000

Integrated Circuit Card Specification for Payment Systems, Version 4.0
(EMV 4.0), Book 1, Section 8, and Book 4, Section 7.
This chapter is organized into the following sections:
3.1 Card Data
3.2 Terminal Data
3.3 Commands
3.4 Building the Candidate List
3.5 Identifying and Selecting the Application
3.6 Flow
3.7 Subsequent Related Processing
31 Oct 2001
Application Selection Visa Integrated Circuit Card
3.1 Card Data

The card data elements used in Application Selection are listed and described
in Table 3–1. For a detailed description of these data elements and their
usage, see Appendix A, Terminal and Acquirer Data Elements.
Table 3–1: Application Selection—Card Data (1 of 2)
Data Element Description
Application Definition File (ADF) The ADF is a file, which is the entry point to application elementary files (AEF),
which contain data elements for the application. The ADF may contain information
about the application such as language preference and application priority. It may
also contain a Processing Options Data Objects List (PDOL) of terminal data
elements requested by the card for processing.
Application Elementary Files AEF contains data elements used by the application in processing.
(AEF)
Application Identifier (AID) The AID is composed of the Registered Application Provider Identifier (RID) and
the Proprietary Application Identifier Extension (PIX). It identifies the application
as described in ISO/IEC 7816-5.
All Visa AIDs shall begin with a RID expressed as hexadecimal A000000003. The
Visa RID is concatenated with a Visa assigned PIX to identify the application.
● 1010—Visa Debit and Visa Credit
● 2010—Visa Electron
● 3010—Interlink
● 8010—Plus
● 999910—Proprietary ATM applications
The card AID shall have a suffix if more than one Visa debit or credit application is
present on a single card. For example, a card with both a Visa credit and a Visa
debit application might use the suffix as follows:
Example:
A000000003101001—first Visa application (for Visa Credit)
A000000003101002—second Visa application (for Visa Debit)
Application Label Mnemonic associated with AID according to ISO/IEC 7816-5. Used in application
selection. Application Label is required in the File Control Information (FCI) of an
Application Definition File (ADF) and mandatory in an ADF directory entry. It will
become mandatory in the ADF according to the EMVCo migration plan.
3–2
Visa Integrated Circuit Card 3.1 Card Data
Table 3–1: Application Selection—Card Data (2 of 2)
Application Preferred Name Mnemonic associated with AID. If the Application Preferred Name is present and
the Issuer Code Table Index entry is supported by the terminal, the Application
Preferred Name rather than the Application Label is displayed to the cardholder
during Application Selection.
Application Priority Indicator Indicates the priority of a given application or group of applications in a directory.
Directory Definition File (DDF) The DDF file is a file, which defines the directory structure beneath it. The FCI for
a DDF contains a pointer to a Directory File.
Directory File A directory file is a file listing DDFs and ADFs contained within the directory. It is
accessed by the READ RECORD command.
For detailed information on directory files, refer to the EMV 4.0, Book 1, Section 8.
File Control Information (FCI) The FCI is provided in response to the SELECT command. This information
varies depending on the type of file selected.
Issuer Code Table Index Indicates the code table (character set) support, according to International
Organisation for Standardisation (ISO) 8859, required in the terminal to display
the Application Preferred Name.
Payment Systems Environment The PSE begins with a DDF given the name “1PAY.SYS.DDF01”. The directory
(PSE) file associated with this DDF is known as the Payment Systems Directory.
Processing Options Data The PDOL is a list of tags and lengths for terminal-resident data objects
Objects List (PDOL) requested by the card and provided by the terminal in the GET PROCESSING
OPTIONS command during Initiate Application Processing.
Short File Identifier (SFI) The SFI is a pointer to elementary files (EF).
●
1–10 Reserved for EMV
● 11–20 Payment system specific
●
21–30 Issuer specific
31 Oct 2001
3.2 Terminal Data

The terminal data elements used in Application Selection are listed and
described in Table 3–2. For a detailed description of these data elements and
their usage, see Appendix A, Terminal and Acquirer Data Elements.
Table 3–2: Application Selection—Terminal Data
Application Identifier (AID) The AID, tag “9F06” in the terminal, is composed of the Registered Application
Provider Identifier (RID), and the Proprietary Application Identifier Extension
(PIX). It identifies the application as described in ISO/IEC 7816-5.
All Visa AIDs shall begin with a RID expressed as hexadecimal A000000003. The
Visa RID is concatenated with a Visa-assigned PIX to identify the application.
● 1010—Visa Debit and Visa Credit
● 2010—Visa Electron
● 3010—Interlink
● 8010—Plus
● 999910—Proprietary ATM applications
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 (Partial Selection is not supported), or
only up to the length of the AID in the terminal (Partial Selection is supported).
There is only one Application Selection Indicator per AID in the terminal and its
format is at the discretion of the terminal vendor.
Application Selection Indicators for Visa AIDs must indicate support for Partial
Selection.
List of supported applications The terminal shall maintain a list of applications supported by the terminal and
their respective AIDs.
PSE File Name The name of the PSE (1PAY.SYS.DDF01) is used in Application Selection if the
terminal supports directory selection.
3–4
Visa Integrated Circuit Card 3.3 Commands
3.3 Commands
SELECT
The SELECT command shall be performed as described in the EMV 4.0,
Book 1, Section 7.3.
The terminal sends the SELECT command to the card to obtain information
from the card on which applications are supported by the card and issuer
preferences such as the priority in which the application is selected, name of
the application, and language preference. The command either contains the
name of the Payment Systems Environment (used for the directory selection
method), a DDF name or a requested AID (used for the List of the AIDs
method).
The P1 parameter of the SELECT command indicates whether the application
is being selected by name. The P2 parameter indicates whether additional
applications with the same AID are being requested in support of AID suffixes
(where multiple applications with the same AID are supported by the card).
The command response may have the following SW1 SW2 return codes:
● 9000—Successful return from SELECT
● 6A81—Card is blocked or command not supported
● 6A82—Selected file not found
– PSE not found (Directory Selection Method not supported by the card)
– Last file when P2 parameter specified additional applications with the
same AID (command contains AID)
● 6283—Application is blocked
The card’s response includes the PDOL, if present on the card. The PDOL will
be used during Initiate Application Processing.
READ RECORD
The READ RECORD command shall be performed as described in the
EMV 4.0, Book 1, Section 7.2.
In the Directory Selection Method, the terminal reads the directory, an
Elementary File associated with the PSE, which lists all of the EMV payment
applications on the card and the card returns the requested record in the
response. The command includes the Short File Identifier (SFI) of the file to be
read and the record number of the record within the file.
31 Oct 2001
3.4 Building the Candidate List

Two approaches are used by the terminal to build a list of mutually supported
applications:
1. Directory Selection Method—Optional for cards and terminals, but if
supported by the terminal, it is attempted first. In the Directory Selection
Method, the terminal reads a directory (associated with the PSE) from the
card. This directory is a list of the applications supported by the card. The
terminal adds any applications listed both in the card list and in the
terminal list on the candidate list.
2. List of AIDs Method—Mandatory for cards and terminals. In List of
AIDs Method, the terminal issues a SELECT command for each
terminal-supported application. If the card response indicates that the
application is supported by the card, the terminal adds the application to
the candidate list.
NOTE: Terminals shall include all common applications in the final

candidate list except in certain conditions specified in Visa Operating
Principles and Regulations.
In either of the approaches described above, the terminal must check the
Application Selection Indicator to determine which of the matching criteria
are to be used for this application:
● Option 1—The AID from the card must exactly match the AID from the
terminal including the length (Partial Selection is not supported).
● Option 2—The AID from the card must exactly match the AID only up to
the length of the AID in the terminal and may be longer (Partial Selection
is supported).
The Application Selection Indicator for Visa AIDs shall indicate Option 2.
Table 3–3 shows AIDs that would not match for Option 1, but are considered
matches for Option 2.
Table 3–3: Application Selection Indicator Matching Criteria
Match Match
Terminal AID Card AID Option 1 Option 2
A0000000031010 A000000003101001 N Y
A0000000031010 A000000003101002 N Y
Note: The suffixes “01” and “02” make the AIDs unique. They are simply labels and need
not be in order.
3–6
Visa Integrated Circuit Card 3.4 Building the Candidate List
3.4.1 Directory Selection Method

Directory Selection Method processing includes the following steps:
1. The terminal selects the PSE, which is a special DDF, using the SELECT
command. The name of the PSE file is 1PAY.SYS.DDF01.
2. If the card responds with any code other than “9000” or “6A81”, the
terminal attempts to build the candidate list using the List of AIDs
Method.
3. If the card responds with SW1 SW2 “6181”, the session is terminated.
4. If the PSE is found and the card responds to the terminal with
SW1 SW2 = “9000”, the FCI for the PSE is included in the response to
SELECT. The FCI contains an SFI for the Payment Systems Directory.
Each record in this directory lists an application (or another directory
containing applications).
5. The terminal reads the Payment Systems Directory using the SFI for the
Payment Systems Directory to identify the file to be read.
The terminal uses the READ RECORD command to read each record in
the Payment Systems Directory until the card responds that there are no
more records (SW1 SW2 = “6A83”).
If the candidate list is empty and there are no more records, the terminal
attempts to build the candidate list using the List of AIDs Method.
6. Records are comprised of entries, which may be directories (DDFs) or
applications (ADFs). The terminal processes each entry in the record in
the order in which they occur. If the entry in the record is an ADF, the
terminal compares the AID in that record to the AIDs supported by
the terminal. If they match the terminal adds the card AID to the
candidate list.
7. If the entry in the record is a DDF, the terminal selects the DDF using the
SELECT command with the DDF name to obtain the SFI for the directory
file for that DDF.
The terminal reads and processes the records in that directory file until
there are no more entries (card responds with SW1 SW2 = “6A83”).
The terminal then reads the next record in the Payment Systems
Directory as described in Step 5.
31 Oct 2001
In the example in Figure 3–1, the terminal:

1. Reads Record 1 from the Payment Systems Directory.
2. Checks to see if either of the AIDs for the ADF Entry 1 or 2 match
terminal AIDs.
3. Reads Record 2 from the Payment Systems Directory.
4. Selects the DDF directory indicated in Entry 1 of Record 2.
5. Reads Record 1 from the DDF Directory.
6. Checks to see if either of the AIDs for the ADF Entry 1 or 2 match
terminal AIDs. If they match, it is added to the candidate list.
7. Returns to processing entries and records from the previous directory,
when card responds that there are no more records in the directory.
8. Checks to see if Entry 2, Record 2 from the Payment System Directory
matches a terminal AID. If they match, it is added to the candidate list.
9. Completes the candidate list when the card responds that there are no
more records in the Payment Systems Directory. If the candidate list is
empty, terminal attempts List of AIDs method.
Figure 3–1: Directory Selection Method Example
Payment
PSE Systems
Directory
Record 1 Record 2
Entry 1 Entry 2 Entry 1 Entry 2

ADF ADF DDF ADF
DDF DDF
Directory
Record 1
Entry 1 Entry 2
ADF ADF
3–8
Visa Integrated Circuit Card 3.4 Building the Candidate List
3.4.2 List of AIDs Method

List of AIDs Method processing includes the following steps:
1. The terminal retrieves the AID of an application from a list of applications
supported by the terminal.
2. The terminal attempts to select the application using the SELECT
command. The AID of the application to be selected is sent to the card in
the SELECT command.
3. If the card AID matches the terminal AID, the card responds to the
SELECT command, indicating that the application is supported by the
card (SW1 SW2 = “9000”). If the card does not find a matching AID, the
card responds with SW1 SW2 = “6A82”, indicating that the application
was not found.
4. If the card responds that the application is supported
(SW1 SW2 = “9000”), the terminal adds the application to the candidate
list. The AID (DF Name) returned by the card may be longer than the AID
used by the terminal to select the application. When this occurs, the AID
returned by the card is placed in the candidate list.
5. If the DF Name returned by the card is longer, the terminal selects the
next application of the same name by indicating next occurrence in P2 and
adds it to the candidate list until the card indicates in its response
(SW1 SW2 = “6A82”) that all matching applications have been selected.
Figure 3–4 shows sample matching AIDs.
Table 3–4: Sample AIDs Matching
Terminal Card
Terminal AID Application Card AID Application
A0000000031010 Visa A000000003101001 Visa Credit
A0000000031010 Visa A000000003101002 Visa Credit
The SELECT command is used with the terminal AID and parameter P2 set
to “02” to indicate that the card should provide the next application with the
same terminal AID.
Steps 1–5 are repeated until the terminal has attempted to select all of the
applications it supports.
31 Oct 2001
3.5 Identifying and Selecting the Application

If there are no mutually supported applications, the transaction is
terminated. If there is at least one mutually supported application, the
processing is as follows.
3.5.1 Terminal Makes Application Selection Decision

A terminal that does not support cardholder selection or confirmation shall
issue a SELECT command to the highest priority application, indicated by the
Application Priority Indicator on the card, which does not require
confirmation. If more than one application has the highest priority, the
terminal may issue a SELECT command for either application.
If the Directory Selection Method was used to build the list of applications, the
card may respond to the SELECT command with SW1 SW2 other than “9000”,
indicating that the transaction cannot be performed with the selected
application. If this occurs, and there are more available applications on the
list of available applications, the terminal should issue a SELECT command
to the application with the next highest priority.
3.5.2 Cardholder Makes Account Selection Decision
3.5.2.1 Terminal Supports Cardholder Confirmation

A terminal that does not support cardholder selection from a list of displayed
accounts, but supports cardholder confirmation of an account, shall request
cardholder confirmation for the highest priority application as indicated by
the Application Priority Indicator on the card. If more than one application
has the same priority, the terminal may process in the order encountered or
choose one of the applications. If the cardholder confirms the choice, the
terminal uses the SELECT command to select the application.
If the cardholder does not confirm, the terminal offers the next highest
priority application until the cardholder confirms or there are no more
available applications.
If the Directory Selection Method was used to build the list of applications,
the card may respond to the SELECT command with SW1 SW2 other than
“9000”, indicating that the transaction cannot be performed with the
selected application. If this occurs, and there are more available applications
on the list, the terminal should remove the rejected application from the
list of available applications and request confirmation of the next
available application.
3–10
Visa Integrated Circuit Card 3.5 Identifying and Selecting the Application
3.5.2.2 Terminal Supports Cardholder Selection

A terminal that supports cardholder selection shall present a list of
applications in priority order to the cardholder for selection. If more than one
application has the same priority, the terminal may display them to the
cardholder in the order encountered or decide the order. The cardholder
selects the application from the list and the terminal uses the SELECT
command to select the application.
If the Directory Selection Method was used to build the list of applications, the
card’s response to the SELECT command may indicate that the application is
blocked. If this occurs, and there are more available applications on the list,
the terminal should display “Try Again” and display the list of available
applications excluding the rejected application.
If the cardholder does not select an application, the terminal terminates the
transaction.
31 Oct 2001
3.6 Flow
Figure 3–2: Application Selection Processing Flow (1 of 3)
Card Application Selection

- Directory Selection
Terminal
Method
List of AIDs
Terminal Method
N
supports PSE
Card responds B
Y
with FCI and A
“9000” if (card Terminal clears the
not blocked and candidate list and
SELECT Y
PSE found and issues SELECT with
command
not blocked) or DFNAME =
(card not 1PAY.SYS.DDF01 Place current directory
blocked and and resumption
DDF found) information on directory
stack Y
SELECT Card SW1&2= DDF=

blocked? N N
response 9000? PSE? Terminal issues
SELECT with
Y DFNAME of DDF
N
Terminate Y
transaction
C B
Get SFI for Directory from
FCI and set record # to 1
Card responds
READ
with Directory Terminal issues
RECORD
Entry and READ RECORD
command
“9000” if found
READ
Directory stack Candidate
RECORD Record Found? N Y
empty? List Empty?
response
Y
N
N
Get entry
Choose
Get previous Application
directory from list and and SELECT
A N ADF? continue processing
Y
Y
Terminal
supports?
C
Add to candidate list N Another entry Increment

N
in record? record number
3–12
Visa Integrated Circuit Card 3.6 Flow
List of AIDs
Card Selection Terminal
Method
Get first AID from

terminal list of AIDs
Card responds Issue SELECT

SELECT
with FCI or error command with DF
command
message Name = AID.
Terminal
SELECT Card Blocked?
Y terminates card
response (SW1SW2 =
6A81) session
File
found for AID?
(SW1SW2 NE
6A82)
Y
N
Application
blocked? Y
(SW1SW2 =
6283)?
Add Application to
Candidate List
Choose
Application
Name in FCI Another AID in and SELECT
Y N
exact match? terminal list?
N
N
Name in FCI
partial match?
Y Y
Partial Selection N
supported for AID?
Set P2 in SELECT to “02”

Get next AID from
indicating select next application
terminal list of AIDs
with same DFNAME
B B
31 Oct 2001
Choose
Card Application
Terminal
& SELECT
Any mutually Terminal

supported N terminates the
applications? transaction
Terminal
displays highest
Terminal
priority Cardholder
confirmation Y
support? application on confirms?
list for
confirmation
Terminal
displays
Terminal Application
applications by
supports Y
priority and selected?
selection?
asks cardholder
to select
N
Terminal identifies
Applications highest priority
available without Y application not
confirmation? requiring Y
confirmation
Y
N
N
T N
Card responds with FCI

Terminal issues
for requested AID and SELECT SELECT command
“9000” (selection command with the identified
successful) or “6283”
application
(application blocked)
Successful
SELECT Terminal removes
SELECT Y
response application from list
(“9000”)?
Terminal proceeds to
B
Initiate Application
Processing
3–14
Visa Integrated Circuit Card 3.7 Subsequent Related Processing

Initiate Application Processing
The GET PROCESSING OPTIONS command sent to the card by the terminal
includes any terminal data specified in the PDOL. If supported, the PDOL
was included in the SELECT command response during Application Selection.
If Geographic Restrictions do not permit the selected application to be
initiated, the terminal terminates the transaction and returns to Application
Selection for selection of another application.
31 Oct 2001
Initiate Application Processing 4
During Initiate Application Processing, the terminal signals to the card that
transaction processing is beginning. The terminal accomplishes this by
sending the GET PROCESSING OPTIONS command to the card. When
issuing this command, the terminal supplies the card with any data elements
requested by the card in a Processing Options Data Objects List (PDOL). The
PDOL (a list of tags and lengths of data elements) is optionally provided by
the card to the terminal during Application Selection.
The card responds to the GET PROCESSING OPTIONS command with the
Application File Locator (AFL), a list of files and records, which the terminal
needs to read from the card. The card also provides the Application
Interchange Profile (AIP), a list of functions to be performed in processing
the transaction.
Initiate Application Processing shall be performed as described in the EMV
2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0
(EMV 4.0), Book 3, Section 6.1, and Book 4, Section 2.3.1.
4.1 Card Data
4.2 Terminal Data
4.3 GET PROCESSING OPTIONS Command
4.4 Processing
4.5 Prior Related Processing
31 Oct 2001
Initiate Application Processing Visa Integrated Circuit Card
4.1 Card Data

The card data elements used in Initiate Application Processing are listed and
described in Table 4–1. For a detailed description of these data elements and
their usage, refer to the Visa Integrated Circuit Card Specification,
Appendix A, Card and Issuer Data Element Tables.
Table 4–1: Initiate Application Processing—Card Data
File Control Information (FCI) Information such as file name and language preference provided by card in
response to the SELECT command issued by the terminal.
Processing Options Data Object The PDOL is a list of tags and lengths for terminal-resident data objects needed
List (PDOL) by the card in processing the GET PROCESSING OPTIONS command during
Initiate Application Processing (Chapter 3, Application Selection).
Application Interchange Profile A data element, which indicates the capability of the card to support specific
(AIP) functions in the application (SDA, DDA, Cardholder Verification, and Issuer
Authentication).
Application File Locator (AFL) Indicates the file location and range of records, which contain card data to be read
by the terminal for use in transaction processing. For each file to be read, the AFL
contains the following information:
● Byte 1—Short File Identifier (a numeric file label)
● Byte 2—Record number of the first record to be read
● Byte 3—Record number of the last record to be read
● Byte 4—Number of consecutive records containing data to be used in Offline
Data Authentication beginning with the first record to be read as indicated in
Byte 2.
4–2
Visa Integrated Circuit Card 4.2 Terminal Data
4.2 Terminal Data

The terminal data elements used in Initiate Application Processing are listed
and described in Table 4–2. For a detailed description of these data elements
and their usage, see Appendix A, Terminal and Acquirer Data Elements.
Table 4–2: Initiate Application Processing—Terminal Data
Terminal Country Code Terminal data indicating the country of the terminal. It is provided to the card in the
GET PROCESSING OPTIONS command if requested by the card in the PDOL.
Terminal Verification Results A terminal data element indicating the results of offline processing from a terminal
(TVR) perspective. This data element is transmitted in online authorization and clearing
messages.
Transaction Status Information Indicates the functions performed by the terminal. This data element is not
(TSI) provided in the online authorization and clearing messages.
4.3 GET PROCESSING OPTIONS Command

The GET PROCESSING OPTIONS command from the terminal signals the
card that transaction processing is beginning. The command is described in
the EMV 4.0, Book 3, Section 2.5.8 and Appendix B, Commands for Financial
Transactions, of this volume.
The data portion of the command contains the terminal data elements
requested by the card in the optional PDOL.
The data portion of the response contains the Application Interchange Profile
(AIP) and the Application File Locator (AFL).
31 Oct 2001
4.4 Processing
The terminal initiates application processing by sending the GET
PROCESSING OPTIONS command to the card. The terminal:
1. Extracts the PDOL (if present) from the FCI provided by the card in
response to the SELECT command.
2. Sets the Transaction Status Information (TSI) to zero.
3. Sets the Terminal Verification Results (TVR) to zero.
4. Sends the GET PROCESSING OPTIONS command to the card. Any data
elements requested in the PDOL are passed to the card in this command.
Refer to EMV 4.0, Book 3, Section 1.4, Rules for Using a Data Object List
(DOL).
5. Receives the card response to the GET PROCESSING OPTIONS
command.
6. If Geographic Restrictions apply, the card responds with “Conditions of
use not satisfied” (SW1 SW2 = “6985”), the terminal removes the
application from the list of candidate applications for this transaction and
returns to Application Selection processing.
7. If the card responds with the AFL and the AIP, the terminal proceeds to
Read Application Data.
4–4
Visa Integrated Circuit Card 4.4 Processing
Figure 4–1 shows the Initiate Application Processing flow.
Figure 4–1: Initiate Application Processing Flow
Card Terminal
Terminal completes
(Chapter 3)
Terminal sets TSI and TVR

to zero
Terminal uses PDOL (if

provided by card during
Application Selection) to
determine terminal data
elements to include in GET
PROCESSING OPTIONS
command.
GET Terminal issues GET

PROCESSING PROCESSING OPTIONS
OPTIONS (includes data requested by
command card in PDOL)
Card receives
command, does internal
processing & responds
with “9000”, AIP, & AFL
or error code
Terminal eliminates
GET Card response application from list of
= conditions of use not
PROCESSING Y eligible applications and
satisfied (SW1SW2
OPTIONS response returns to Application
6985)?
Selection (Chapter 3)
Terminal proceeds to Read

Application
Data (Chapter 5)
31 Oct 2001

The card supplies the PDOL (if present) to the terminal as part of the FCI
provided in response to the SELECT command.
The terminal returns to Application Selection if the card indicates that the
conditions of use are not satisfied.

Read Application Data
The AFL provided by the card in response to the GET PROCESSING
OPTIONS command is used by the terminal to determine what application
data to read from the card and what data is used in Online Data
Authentication if supported.
Offline Data Authentication
The AIP provided by the card in response to the GET PROCESSING
OPTIONS command is used by the terminal to determine if the card supports
Offline Data Authentication.
Cardholder Verification
Cardholder Verification.
Online Processing
Issuer Authentication.
4–6
Read Application Data 5
During Read Application Data, the terminal reads the card data necessary to
process the transaction and determines the data to be authenticated during
Static Data Authentication (SDA) or Dynamic Data Authentication (DDA).
Read Application Data shall be performed as described in the EMV 2000
(EMV 4.0), Book 3, Section 6.2.
5.1 Card Data
5.2 Terminal Data
5.3 READ RECORD Command
5.4 Processing
31 Oct 2001
Read Application Data Visa Integrated Circuit Card
5.1 Card Data

During Read Application Data, the terminal uses the data element (described
in Table 5–1), which was received from the card during Initiate Application
Processing.
Table 5–1: Read Application Data—Card Data
Application File Locator (AFL) In Initiate Application Processing, the card sent the terminal the AFL, which
contains an entry for each file to be read. Each entry designates:
● The Short File Identifier (SFI) of the file
● The numbers of the first and last record to be read from the file
● The number of records beginning with the first record read in the file to be used
for authentication during SDA and DDA
Read Application Data reads records from the card’s Application Elementary
Files (AEF) described in Table 5–2.
Table 5–2: Read Application Data—Card Files
Application Elementary Files Card data files containing data used for application processing. An AEF consists
(AEF) of a sequence of records, which are addressed by record number. Each AEF is
identified by a unique Short File Identifier (SFI). The terminal reads these records
using the READ RECORD command containing a designation of the SFI and
record number to be read.
5.2 Terminal Data

No terminal data is used in Read Application Data.
5–2
Visa Integrated Circuit Card 5.3 READ RECORD Command
5.3 READ RECORD Command

EMV 4.0, Book 3, Section 2.5.11.
The terminal uses a READ RECORD command to request a record from the
card:
● P2 includes the Short File Identifier (SFI) of the file to be read
● P1 is the record number within the file
Details are shown in Tables II-21 and II-22 in the EMV 4.0, Book 3.
The command response contains the requested record when
SW1 SW2 = “9000”.
5.4 Processing
The terminal uses the Application File Locator (AFL) to determine which
records to request from the card. For each entry in the AFL, the terminal uses
the READ RECORD command to request the first record number specified in
the AFL entry from the file specified by the SFI in this entry. After receiving
the requested record, the terminal requests subsequent records until the last
record specified in the AFL entry is received. The terminal processes the next
entry in the AFL in the same manner until all AFL entries are processed.
The AFL entry specifies how many records from the AEF are used for offline
data authentication. Beginning with the first record read from the Application
Elementary Files (AEF), the terminal shall put the record read into the list of
static data to be authenticated until the number of records specified in the
AFL entry has been put into the list.
The terminal shall store all recognized data objects for later use in processing
the transaction. Unrecognized data objects shall not be stored.
The terminal shall terminate the transaction under any of these conditions:
● More than one occurrence of a single primitive data object is encountered
while reading data from the ICC
● The completion code (SW1 SW2) returned by the card in the READ
RECORD response is not “9000”
●
All mandatory data objects are not received. Mandatory data objects are
shown in the Visa Integrated Circuit Card Specification, Appendix A,
Terminal and Acquirer Data Elements.
31 Oct 2001
Read Application Data Visa Integrated Circuit Card
The terminal could perform Read Application Data as shown in Figure 5–1.
Figure 5–1: Read Application Data Processing Flow
Card Terminal
Terminal completes
Initiate Appl. Terminal stores data
Processing for later use
Terminal selects first P1

entry from AFL = last record number
in AFL entry?
N
Y
SDA Count = count in
AFL entry
Any more AFL
entries?
P1 = first record
number in AFL Y
P2 = SFI
Terminal selects next

AFL entry
READ Terminal sends Terminal
Card passes record
RECORD READ RECORD increments P1
to terminal
command command to card (record number)
Requested record in SW1 SW2 = N

READ RECORD 9000 (successful
response read)?
SDA Count = 0? N
Puts data in a list of N

All mandatory
SDA data N
data received?
Y
Decrement SDA
Count by 1
Y
Any Terminal proceeds to

Terminal
data element tags Offline Data
already Y terminates
Authentication
received? transaction
(Chapter 6)
5–4
Visa Integrated Circuit Card 5.5 Prior Related Processing

The terminal gets the AFL from the card in the GET PROCESSING
OPTIONS response for use during Read Application Data.

Other functions use the data saved during Read Application Data for
processing.
The terminal uses the list of static data to be authenticated built during Read
Application Data for validation of the Signed Static Application Data during
SDA or the ICC Public Key Certificate during DDA.
31 Oct 2001
Offline Data Authentication 6
Offline Data Authentication is the process by which the terminal

authenticates data from the card using RSA public key technology. Offline
Data Authentication has two forms:
●
Static Data Authentication (SDA)
● Dynamic Data Authentication (DDA)
During SDA processing, the terminal authenticates static (unchanging) data
from the card. SDA ensures that issuer-selected card data elements have not
been changed since the card was personalized.
During DDA processing the terminal authenticates the static card data and
also authenticates a cryptogram, which the card generates using
transaction-unique data. DDA ensures that issuer-selected card data
elements have not been altered since the card was personalized. DDA also
confirms that the card is genuine and has not been created by copying data
from a valid card to a counterfeit card (skimming). DDA can be either
Standard DDA or Combined DDA/Application Cryptogram (AC) Generation.
Offline Data Authentication results are considered in the card and terminal’s
decision of whether to approve offline, go online for authorization, or decline
offline. Online authorization systems may use the results of Offline Data
Authentication in their authorization response decision.
Offline Data Authentication shall be performed as described in the EMV 2000
(EMV 4.0), Book 2, Sections 5 and 6. All offline-capable terminals shall
support Offline Data Authentication. Offline Data Authentication support is
optional for cards.
31 Oct 2001
Offline Data Authentication Visa Integrated Circuit Card

6.1 Terminal Requirements
6.2 Determining Whether to Perform SDA or DDA
6.3 Static Data Authentication (SDA)
6.4 Dynamic Data Authentication (DDA)
6–2
Visa Integrated Circuit Card 6.1 Terminal Requirements

Terminals shall support the following requirements for Offline Data
Authentication.
6.1.1 Support for Offline Data Authentication

Offline-capable terminals shall support SDA and should support DDA.
Online-only terminals such as ATMs are not required to support offline data
authentication.
6.1.2 Visa Certificate Authority (CA)

SDA and DDA use RSA public/private key pairs, which require the
implementation of a Visa Certificate Authority (CA). The Visa CA provides
public key cryptographic services for the initialization and support of Offline
Data Authentication. The Visa CA functions in a secure environment to
ensure the security and integrity of all processes, keys, and related data.
The terminal-related services provided by the Visa CA:
● Generate all Visa RSA key pairs.
● Distribute the Visa Public Keys to acquirers.
● Notify acquirers of revocation and introduction of keys as outlined in the
EMV 4.0, Book 2, Section 10.
6.1.3 RSA Key Pairs

To enable the use of the Visa RSA key pairs that are used in both SDA and
DDA, the following shall occur:
● The Visa CA shall generate one or more Visa RSA key pairs
●
The Visa CA shall convey the Visa CA Public Key components of the Visa
key pairs to acquirers
● Acquirers shall be responsible for the distribution of the Visa CA Public
Keys to all terminals that support SDA or DDA and for the deletion of
keys that have been revoked
31 Oct 2001
6.1.4 Security Requirements

To ensure a sufficient level of support for RSA key backup, key recovery, and
key migration, all terminals shall be capable of securely storing six Visa CA
Public Keys and their associated data elements. Each of these six keys is
between 768 and 1984 bits in length, and all six key storage slots shall be
available for use at the same time.
Terminals shall support the Visa and EMV requirements for withdrawal and
introduction of the Visa CA Public Keys. EMV requirements for key handling
in the terminal are shown in the EMV 4.0, Book 2, Sections 10 and 11.
6.2 Determining Whether to Perform SDA or DDA
6.2.1 Terminal Data

The terminal uses the terminal data (described in Table 6–1) when
determining whether to perform SDA or DDA.
Table 6–1: Terminal Data Used in SDA or DDA Determination
Terminal Capabilities Contains flags indicating the terminal’s support for SDA and DDA which may be
used in deciding whether to perform SDA or DDA
● SDA supported
● Standard DDA supported
● Combined DDA/AC Generation Supported
Transaction Status Information Contains a flag that is set when SDA or DDA is performed
(TSI)
Terminal Verification Results Contains a flag that is set when neither SDA or DDA is performed
(TVR)
6–4
Visa Integrated Circuit Card 6.2 Determining Whether to Perform SDA or DDA
6.2.2 Card Data

The terminal uses the data (described in Table 6–2) from the card when
determining whether to perform SDA or DDA.
Table 6–2: Card Data Used in SDA or DDA Determination
Application Interchange Profile Contains flags indicating the card’s support for SDA and DDA:
(AIP) ● SDA supported
● DDA supported
●
Combined DDA/AC Generation supported
6.2.3 Commands
No commands are used to determine whether to perform SDA or DDA.
6.2.4 Process
Only one offline data authentication method is performed in a single
transaction. Combined DDA/AC Generation receives priority over Standard
DDA and Standard DDA receives priority over SDA. If the card and terminal
do not support a common authentication method, offline data authentication
is not performed.
Card support for SDA and DDA is shown in the Application Interchange
Profile (AIP). Terminal support for SDA and DDA is shown in Terminal
Capabilities, but the terminal may use other means to determine whether it
supports these methods.
The terminal uses the following rules to determine whether to perform SDA,
Standard DDA or Combined DDA/AC Generation:
●
If both the card and the terminal support Combined DDA/AC Generation,
the terminal shall perform Combined DDA/AC Generation
● Otherwise, if both the card and the terminal support Standard DDA, the
terminal shall perform Standard DDA
● Otherwise, if both support SDA, the terminal shall perform SDA
●
If none of the previous conditions are satisfied, the terminal shall not
perform SDA or DDA and shall set the Offline Data Authentication was
Not Performed bit to “1” in the TVR
31 Oct 2001
Figure 6–1 illustrates how the terminal could determine whether to perform
SDA, Standard DDA, or Combined DDA/AC Generation.
Figure 6–1: SDA or DDA Determination
Combined DDA/AC Offline DDA is

Offline SDA supported
Generation supported bit N supported set to “1” in N
AIP? set to “1” in AIP?
set to “1” in AIP?
Y Y Y
N N
N
Terminal Terminal
Terminal supports
supports Combined DDA/ supports N
Standard DDA?
AC Generation? SDA?
Y Y
Method used is
Combined DDA
AC Generation Y Terminal sets Offline Data
Auth. was Not Performed
Method used is bit to “1” in TVR.
Standard DDA
Terminal proceeds to DDA Terminal proceeds to SDA Terminal proceeds to

processing processing Processing Restrictions
(Section 6.4) (Section 6.3) (Chapter 7)
6–6
Visa Integrated Circuit Card 6.3 Static Data Authentication (SDA)
6.3 Static Data Authentication (SDA)

When SDA is performed, the terminal validates static (unchanging)
application data from the card using RSA public key technology. The
validation process involves recovering the Issuer Public Key from a certificate
on the card and validating static card data using a signature from the card.
SDA ensures that the card data has not been fraudulently altered since
personalization.
6.3.1 Card Data

During SDA, the terminal uses the data (described in Table 6–3) that was
received from the card in previous steps.
Table 6–3: Offline Data Authentication—SDA Card Data (1 of 2)
Data Description
Certificate Authority Public Key Used with the RID to designate which Visa CA Public Key to use for offline data
Index (PKI) authentication.
Issuer Public Key (PK) A certificate that has been signed with the Visa Private Key and includes the
Certificate Issuer Public Key. The format is shown in the EMV 2000 Integrated Circuit Card
Specification for Payment Systems, Version 4.0 (EMV 4.0), Book 2, Section 5,
Table 4. The certificate includes the following subfields:
● The Issuer Public Key Length—Must be less than or equal to the length of the
Visa CA Public Key
● The Issuer Public Key or the leftmost digits of the Issuer PK if the entire PK
does not fit in the certificate
● The hash result from hashing the Issuer PK and other data elements specified
in the EMV 4.0, Book 2, Section 5, Table 1
Issuer Public Key Exponent Used in the RSA decryption algorithm.
Issuer Public Key Remainder If necessary, it contains the portion of the Issuer Public Key that does not fit within
the Issuer Public Key Certificate.
Registered Application Identifier A portion of the Application Identifier (AID) that identifies the card scheme. The
(RID) RID is used with the PKI to designate the Visa CA Public Key to use for offline
data authentication. Visa’s RID is A000000003.
Signed Static Application Data Used in the validation of the card’s static data during SDA. The SAD is signed with
(SAD) the Issuer Private Key and includes a hash of the card static data. The SAD
format is shown in the EMV 4.0, Book 2, Section 5, Table 5. The format of the
data to be hashed is in Table IV-2 of the same document.
31 Oct 2001
Table 6–3: Offline Data Authentication—SDA Card Data (2 of 2)
Data Description
Static Data Authentication Tag Optional field containing the tag of the AIP (tag “82”). If other tags are present,
List SDA processing fails.
Static Data to be Authenticated The data fields from the card to be used in the validation of the SAD. It consists of
the data in the records identified in the AFL as being used for data authentication
and the data identified in the optional Static Data Authentication Tag List. If
present it contains the tag for the AIP (“82”). The terminal checks that this is the
only tag present in the SDA Tag List.
6.3.2 Terminal Data

The terminal data elements described in Table 6–4 are required if the
terminal supports SDA.
Table 6–4: Offline Data Authentication—SDA Terminal Data
Data Description
Certificate Authority Public Key Each Visa CA Public Key used for offline data authentication in SDA and DDA is
Index (PKI) identified by the PKI in conjunction with the Registered Application Identifier (RID)
of the Application Identifier (AID).
The Visa CA Public Keys The public keys stored in terminal for use in Issuer PK Certificate recovery. The
Visa RID and a PKI unique within the Visa RID are associated with each Visa CA
Public Key. Additional requirements are in Section 6.1.3 RSA Key Pairs, and
Section 6.1.4 Security Requirements, in this chapter.
Terminal Verification Results Contains a flag that is used to indicate SDA failure.
(TVR)
Registered Application Provider Identifies the scheme-specific list of public keys in the terminal. Used in
Identifier (RID) conjunction with the PKI to identify the Visa CA Public Key to use of offline data
authentication. Visa’s RID is A000000003.
6.3.3 Commands
No commands are used in SDA.
6–8
6.3.4 SDA Process

SDA shall be performed by the terminal as described in the EMV 4.0, Book 2,
Section 5, and Book 3, Section 6.3. The following summarizes this SDA
processing:
1. Retrieval of the Visa CA Public Key
The terminal uses the Certificate Authority PKI and the RID from the
card to retrieve the terminal-stored Visa CA Public Key and related
information.
2. Retrieval of the Issuer Public Key
The terminal performs the following actions:
a. Validates that the Issuer Public Key Certificate is the same length as
the Visa CA Public Key Modulus.
b. Recovers the data from the Issuer Public Key Certificate using the
Visa CA Public Key. The recovered data includes the Issuer Public
Key.
c. Checks the recovered data for:
■ A valid data trailer
■ A valid data header
■ A valid certificate format
■ An Issuer Identification Number which corresponds to the
Application PAN
■ A non-expired expiration date
■ A valid Issuer Public Key algorithm
d. Generates a hash from the certificate data and compares it to the
recovered hash.
e. Reconstructs the Issuer Public Key Modulus from the recovered data
and the Issuer Public Key Remainder, if present.
NOTE: Validation of the Certificate Serial Number (optional step 10 in EMV)
is not currently supported by VIS.
31 Oct 2001
3. Verification of the Signed Static Application Data (SAD)

a. Validates that the SAD is the same length as the Issuer Public Key
Modulus.
b. Recovers the data from SAD using the Issuer Public Key.
c. Checks the recovered data for
■ A valid data format
d. Concatenates data from the recovered SAD, the static data identified
by the Application File Locator (AFL), and the data identified in the
Static Data Application Tag List. If the SDA Tag List is present, the
terminal checks that the only tag it contains is the tag for the
Application Interchange Profile (“82”). If any other tags are found,
SDA has failed. The rules for formatting this authentication data are
in the EMV 4.0, Book 2, Section 5. If the input list cannot be built,
SDA has failed.
e. Calculates a hash from the concatenated data.
f. Compares the calculated hash with the hash recovered from SAD. If
they are not the same, SDA fails.
4. SDA Results
If all of steps above execute successfully, SDA passes.
If SDA fails, the Offline Static Data Authentication Failed bit shall be set
to “1” in the TVR.
The Offline Data Authentication was Performed bit in the Transaction
Status Information (TSI) shall be set to “1” if SDA is performed.
6–10
Figure 6–2 illustrates how SDA could be performed.
Figure 6–2: SDA Flow
Card data to support Terminal sets ICC Data

N
SDA present? Missing bit to “1” in TVR
Terminal data to
N
support SDA present?
Terminal uses Visa CA PK to

recover Issuer PK from Issuer
PK Certificate and Issuer PK
Remainder
Recovered
certificate passes validity N
checking?
Terminal uses Issuer PK to

recover SAD, which includes a
hash of static data
Recovered data passes

N
validity checking?
Y
Terminal sets Offline Static
N
Terminal concatenates data Data Auth. Failed bit to “1” in
recovered from SAD and static TVR
data to be authenticated &
calculates a hash from
concatenation result
Terminal sets Offline Data Auth.

Calculated hash was Performed bit to “1” in TSI
equals hash recovered
from SAD? Y
Processing Restrictions
(See Chapter 7)
31 Oct 2001
6.4 Dynamic Data Authentication (DDA)

If DDA is to be performed, the terminal validates static application data from
the card using RSA public key technology in a manner similar, but not
identical, to SDA. After validating the static data, the terminal asks the card
to generate a dynamic signature using dynamic data from the terminal and
card. The terminal validates this dynamic signature. The DDA process
verifies that the card is genuine, that the card has not been created from
skimmed data, and that the data on the card has not been fraudulently
altered.
6.4.1 Card Data

During DDA, the terminal uses the data elements that were used for SDA
except for the Signed Static Application Data (SAD). In addition DDA requires
the card data described in Table 6–5.
Table 6–5: Offline Data Authentication—DDA Card Data
Data Elements Description
ICC Public Key (PK) Certificate Contains the ICC Public Key and a hash of the static data. This data is signed with
the Issuer Private Key.
ICC Public Key Exponent Contains the exponent to be used by the RSA algorithm that recovers the ICC PK
Certificate.
ICC Public Key Remainder If necessary, contains that part of the ICC Public Key that did not fit in the ICC PK
Certificate.
Dynamic Data Authentication Contains the tags and lengths of the terminal data to be included in the
Data Object List (DDOL) INTERNAL AUTHENTICATE command requesting a dynamic signature.
6–12
Visa Integrated Circuit Card 6.4 Dynamic Data Authentication (DDA)
During DDA, the terminal receives the data (described in Table 6–6) from the
card in the INTERNAL AUTHENTICATE response.
Table 6–6: Offline Data Authentication—DDA Card Data in INTERNAL AUTHENTICATE Response
Signed Dynamic Application Signed Dynamic Application DataThe dynamic signature generated by the
Data card. The data signed in the Signed Dynamic Application Data includes:
●
The ICC Dynamic Data—Dynamic data from the card used in the hash
algorithm
● A hash result-which was generated from the ICC Dynamic Data and the
terminal dynamic data passed with the INTERNAL AUTHENTICATE
command
The format of the Signed Dynamic Application Data is shown in the EMV 4.0,
Book 2, Section 6, Table 13.
6.4.2 Terminal Data

The same terminal data elements that are used by SDA are also used by DDA.
In addition, the data elements described in Table 6–7 are required for DDA.
Table 6–7: Offline Data Authentication—DDA Terminal Data
Default Dynamic Data Indicates the data to include in the command requesting a dynamic signature
Authentication Data Object List if a DDOL is not received from the card. The Default DDOL shall contain only
(Default DDOL) the tag and length for the Unpredictable Number. No other data objects shall
be referenced in the Default DDOL.
Terminal Verification Results Contains an indicator set when DDA fails.

(TVR)
Unpredictable Number An unpredictable transaction-unique number generated by the terminal and

included in the INTERNAL AUTHENTICATE command.
31 Oct 2001
6.4.3 Commands
6.4.3.1 INTERNAL AUTHENTICATE Command

The terminal sends the INTERNAL AUTHENTICATE command to the card
during DDA to request a dynamic signature.
The command includes the terminal dynamic data specified by the DDOL
from the card or by the terminal’s Default DDOL if a DDOL was not received
from the card.
The INTERNAL AUTHENTICATE response includes the Signed Dynamic
Application Data.
6.4.3.2 GENERATE APPLICATION CRYPTOGRAM (AC) Command

The terminal issues the first GENERATE AC command during Terminal
Action Analysis processing. If the transaction is eligible for Combined
DDA/AC Generation and the tag for Terminal Capabilities is not present in
CDOL1, bit 6 in the P1 byte (Reference Control Parameter) in the
GENERATE AC command is set to “1”.
When CDOL1 from the card contains the tag for Terminal Capabilities, the
terminal returns Terminal Capabilities in the GENERATE AC Command
data. The card and terminal consider the transaction eligible for Combined
DDA/AC Generation if the following conditions are met:
● Byte 3 bit 5 of the Terminal Capabilities = “1”, indicating that the
terminal can perform Combined DDA/AC Generation
● Byte 1 bit 2 of the card's AIP equals “1”, indicating that the card can
perform Combined DDA/AC Generation
If the transaction is eligible for Combined DDA/AC Generation, the card shall
return a TC or an ARQC within the DDA cryptographic envelope as described
in the EMV 4.0, Book 2, Section 6.6.1.
6.4.4 Processing
During DDA processing, the terminal uses RSA public key decryption
technology to recover and validate the Issuer PK Certificate, the ICC PK
Certificate and the Signed Dynamic Application Data (the dynamic signature)
from the card.
The only functions performed by the card during DDA processing are the
generation of the dynamic signature and setting of the CVR bit to indicate
that Offline Dynamic Data Authentication has occurred.
6–14
Standard DDA shall be performed by the terminal as described in the

EMV 4.0, Book 2, Sections 6 and 6.5.
Combined DDA/AC Generation shall be performed by the terminal as
described in the EMV 4.0, Book 2, Sections 6 and 6.6.
6.4.4.1 Standard DDA

Standard DDA processing requires the following steps:
1. Retrieval of the Certificate Authority Public Key
The terminal uses the Certificate Authority Public Key Index and the RID
previously received from the card to retrieve the terminal-stored Visa CA
Public Key and related information.
b. Recovers the data from Issuer Public Key Certificate using the Visa
CA Public Key. The recovered data includes the Issuer Public Key.
Application PAN
d. Calculates a hash from the data elements recovered from the
certificate, the Issuer PK Remainder, and the Issuer PK Exponent.
e. Compares the calculated hash to the hash recovered from the Issuer
Public Key Certificate.
f. Reconstructs the Issuer Public Key Modulus from the recovered Issuer
Public Key and the Issuer Public Key Remainder, if present.
NOTE: Validation of the Certificate Serial Number (optional Step 10 in EMV)
31 Oct 2001
3. Retrieval of the ICC Public Key

a. Validates that the ICC Public Key Certificate is the same length as the
Issuer Public Key Modulus.
b. Recovers the data from ICC Public Key Certificate using the Issuer
Public Key.
■ A recovered PAN which matches the Application PAN from the
card
d. Calculates a hash from the recovered certificate data and the static
data to be authenticated (from the records identified by the AFL and
the data elements in the Static Data Authentication Tag List). The
rules for formatting this authentication data are in the EMV 4.0,
Book 3, Section 6.3. If the input list cannot be built, DDA has failed.
e. Compares the calculated hash result with the hash recovered from
ICC PK Certificate. If they are not the same, DDA has failed.
4. Dynamic Signature Generation
The terminal issues an INTERNAL AUTHENTICATE command that
includes a concatenation of the data elements specified by the DDOL. If a
DDOL was not received from the card, the Default DDOL from the
terminal is used. If the DDOL used does not contain the tag for the
Unpredictable Number, DDA fails.
The card generates Signed Dynamic Application Data by signing the
terminal dynamic data from the INTERNAL AUTHENTICATE command
and dynamic data from the card with the ICC Private Key stored on the
card. The Signed Dynamic Application Data is passed to the terminal in
the INTERNAL AUTHENTICATE response.
6–16
5. Dynamic Signature Verification

The terminal:
a. Validates that the Signed Dynamic Application Data is the same
length as the ICC Public Key Modulus.
b. Recovers the Signed Dynamic Application Data using the ICC Public
Key.
d. Concatenates the data recovered from the Signed Dynamic Application
Data and the DDOL data and calculates a hash from this concatenated
data.
Signed Dynamic Application Data. If they are not the same, DDA has
failed.
6. DDA Results
If all of the steps above execute successfully, Standard DDA has passed.
If DDA fails, Offline Dynamic Data Authentication Failed bit shall be set
to “1” in the TVR.
The Transaction Status Information (TSI) shall be updated to indicate
that offline data authentication was performed.
The DDA steps described above are illustrated in Figure 6–3.
31 Oct 2001
6.4.4.2 Combined DDA/AC Generation

Combined DDA/AC Generation processing is the same as Standard DDA in
Steps 1 through 3 as described below. Combined DDA/AC Generation
processing includes the following steps:
1. Retrieval of the Certificate Authority Public Key
The terminal uses the Certificate Authority Public Key Index and the RID
previously received from the card to retrieve the terminal-stored Visa CA
Public Key and related information.
The terminal:
b. Recovers the data from Issuer Public Key Certificate using the Visa
CA Public Key. The recovered data includes the Issuer Public Key.
Application PAN
d. Calculates a hash from the data elements recovered from the
certificate, the Issuer PK Remainder, and the Issuer PK Exponent.
e. Compares the calculated hash to the hash recovered from the Issuer
Public Key Certificate.
f. Reconstructs the Issuer Public Key Modulus from the recovered Issuer
Public Key and the Issuer Public Key Remainder, if present.
NOTE: Validation of the Certificate Serial Number (optional Step 10 in EMV)
6–18
3. Retrieval of the ICC Public Key

The terminal:
a. Validates that the ICC Public Key Certificate is the same length as the
Issuer Public Key Modulus.
b. Recovers the data from ICC Public Key Certificate using the Issuer
Public Key.
■ A recovered PAN which matches the Application PAN from the
card
d. Calculates a hash from the recovered certificate data and the static
data to be authenticated (from the records identified by the AFL and
the data elements in the Static Data Authentication Tag List). The
rules for formatting this authentication data are in the EMV 4.0,
Book 3, Section 6.3. If the input list cannot be built, DDA has failed.
ICC PK Certificate. If they are not the same, DDA has failed.
The remaining processing for Combined DDA/AC Generation takes place

during Card Action Analysis done by the card and Terminal Action Analysis
and Online Processing done by the terminal.
31 Oct 2001
Figure 6–3: DDA Flow (1 of 3)
Card Retrieval of Terminal

Certificate Authority
Public Key
Data required Set ICC Data Missing
to authenticate ICC PK N
bit to “1” in TVR
available?
Retrieve Terminal CA PK using

RID/CA PK Index
A
CA PK found for
RID/CA PK N
Index?
Issuer ID Number =
N first digits of
Y
Retrieval of Issuer PAN?
Public Key
Issuer
PK Certificate
N Y
& CA PK same
length?
Y Issuer PK Certificate
Y
expired?
Recover data in Issuer PK
Certificate using CA PK
N
Concatenate certificate's
Issuer PK and Issuer PK
Recovered data Remainder to get Issuer PK
has valid header, trailer, Modulus
N
format and PK Algorithm
Indicator?
Y B
Concatenate recovered certificate

data, Issuer PK Remainder, and
Issuer PK Exponent
Calculate hash from concatenated

data
Recovered hash = Terminal proceeds to DDA

N
calculated hash? failure
C
A
6–20
Card B Terminal
Retrieval of ICC
Public Key
ICC PK Certificate
and Issuer PK Modulus N
same length?
Recover data in ICC PK Certificate

using Issuer PK
Recovered
data has valid header, trailer,
N
format, and PK algorithm
indicator?
Concatenate certificate data

elements, ICC PK Remainder,
ICC PK Exponent, and static data
to be authenticated
Apply hashing algorithm to result

of concatenation
Calculated hash =
N
recovered hash?
Recovered PAN =
Application PAN? N
Certificate expired? Y
DDA Failed
Standard DDA?
Y N C
Concatenate
certificate’s ICC PK and
ICC PK Remainder to
form ICC PK Modulus
Proceed to Processing
D
Restrictions
31 Oct 2001
Dynamic D
Card Signature Terminal
(Standard Generation (Standard DDA Only)
DDA Only)
DDOL received from Card?

G
N
Use Terminal’s
Use Card DDOL
Default DDOL
Recovered data
has valid header,
trailer, & format?
DDOL includes
N
Unpredictable Number?
Y
Concatenate recovered
data from Signed
INTERNAL Terminal issues INTERNAL Dynamic Application
AUTHENTICATE AUTHENTICATE command Data with DDOL data
Command with DDOL data elements
Card generates
dynamic signature
Calculate hash
using ICC Private
from
Key and returns
concatenated data
response to terminal
INTERNAL SW1 SW2 =

9000
AUTHENTICATE
(INTERNAL N
response with Recovered hash =
AUTHENTICATE N
dynamic signature successful)? calculated hash?
Dynamic
Signature
Y DDA
Verification Success
Signed Dynamic Y
Application Data & N
ICC PK Modulus
same length?
Set Offline Data

Y Authentication
was Performed in
TSI.
Recover data in C
Signed Dynamic
Application Data using
ICC PK Proceed to
DDA Processing
Restrictions
Failure (Chapter 7)
G
Set Offline Dynamic
Data Authentication
Failed to “1” in TVR.
6–22

The Application Interchange (AIP) is received from the card showing whether
card support for SDA and DDA.
The terminal reads data from the card that includes the data elements
required for the offline data authentication methods supported by the card.
Static data to be authenticated is included in the records identified in the AFL
as participating in offline data authentication.

Terminal Action Analysis
The TVR bits for Offline Data Authentication was Not Performed, Offline
Static Data Authentication Failure, Offline Dynamic Data Authentication
Failure are considered in deciding if the transaction should be declined offline
or sent online.
The terminal indicates in the GENERATE AC Command to the card if
Combined DDA/AC Generation is to be performed.
Online Processing
If Combined DDA/AC Generation was requested and the card response to the
first GENERATE AC was an ARQC or a TC, the terminal performs the
remaining processing for Combined DDA/AC Generation. If the process of
validating the dynamic signature is successful, the terminal continues
processing. If the dynamic signature is not valid and a TC was returned, the
terminal declines the transaction with a Z1 response code.
Completion
● SDA and Standard DDA
After an online authorization, the card may reset the SDA Failure
Indicator and DDA Failure Indicator to “0” based upon Issuer
Authentication options and results.
If SDA or DDA failed and the transaction is to be declined offline because
an online authorization could not be completed, the SDA Failure Indicator
or DDA Failure Indicator is set to “1”.
31 Oct 2001
● Combined DDA/AC Generation

If Combined DDA/Generate AC was performed and failed, the terminal
processes as follows:
– If a TC was returned in the first GENERATE AC, the terminal issues
an offline decline.
– If an ARQC was returned in the first GENERATE AC, the terminal
requests an AAC in the final GENERATE AC (transaction is declined
offline).
6–24
Processing Restrictions 7
The Processing Restrictions function is performed by the terminal using data

elements from the terminal and the card. It includes checks on application
versions, effective and expiration dates, and conditions at the point of
transaction.
Processing Restrictions shall be performed as specified in the EMV 2000
(EMV 4.0), Book 3, Section 6.4, and Book 4, Part I, Section 2.3.3.
This chapter contains the following sections:
7.1 Card Data
7.2 Terminal Data
7.3 Application Version Number
7.4 Application Usage Control
7.5 Application Effective Date
7.6 Application Expiration Date
31 Oct 2001
Processing Restrictions Visa Integrated Circuit Card
7.1 Card Data

The card data elements used in Processing Restrictions are listed and
described in Table 7–1. For a detailed description of these elements and their
usage, refer to the Visa Integrated Circuit Card Specification, Appendix A,
Card and Issuer Data Element Tables.
Table 7–1: Processing Restrictions—Card Data
Application Effective Date The Application Effective Date is the date when the application becomes activated
for use.
Application Expiration Date The Application Expiration Date is the date after which the application is no longer
available for use.
Application Usage Control The AUC indicates any restrictions set forth by the issuer on the geographic
(AUC) usage and services permitted for the card application. If present, it is used in
Application Usage Control checking by the terminal.
Application Version Number This data element (card tag “9F08”) indicates the version of the application on the
card. It is used in Application Version Number checking by the terminal. Cards
complying with this specification should use 140.
Issuer Country Code The Issuer Country Code is an EMV data element (tag “5F28”) indicating the
country of card issuance. If present, it is used in Application Usage Control
checking by the terminal.
7–2
7.2 Terminal Data

The terminal data elements used in Processing Restrictions are listed and
Table 7–2: Processing Restrictions—Terminal Data
Application Version Number This data element, (tag “9F09”), indicates the version of the application in the
terminal. Terminals complying with this specification should use 140.
Terminal Country Code This data element indicates the country in which the terminal is located. It is used
in Application Usage Control checking by the terminal.
Terminal Verification Results Contains bits, which are set to “1” based on the results of Processing Restrictions.
(TVR)
Transaction Date This is the local date (in the terminal) on which the transaction processing is
taking place. It is used by the terminal in effective and expiration date checking.
Transaction Type This data element indicates the type of financial transaction. (It is represented by
the first two digits of International Organisation for Standardisation
(ISO) 8583-1987, Processing Code.) It is used in Application Usage Control
checking by the terminal.
7.3 Application Version Number

The terminal compares the Application Version Number in the card to the
Application Version Number in the terminal to see if they are the same. If
they are not the same, the terminal indicates in the Terminal Verification
Results (TVR) that the application versions differ.
31 Oct 2001
7.4 Application Usage Control

Application Usage Control checking is a process in which the terminal checks
various conditions at the point of transaction to determine if processing
should continue. If the Application Usage Control (AUC) and the Issuer
Country Code are present on the card, the terminal shall check the following
application restrictions:
1. The terminal compares Issuer Country Code to the Terminal Country
Code.
a. If they are equal, the transaction is considered domestic. If the
transaction is domestic, the appropriate indicator shall be set to “1” in
the AUC on the card depending on Transaction Type, in order to
proceed with the transaction. The terminal validates that the
appropriate indicator is set in the AUC.
For example, if the Transaction Type indicates a cash transaction, the
terminal validates that the indicator “Valid for domestic cash
transactions” is set in the AUC.
b. If they are not equal, the transaction is considered international. If the
transaction is international, the appropriate indicator shall be set to
“1” in the AUC (card), depending on Transaction Type, in order to
proceed with the transaction. The terminal validates that the
appropriate indicator for the transaction type is set in the AUC.
For example, if the Transaction Type indicates a cash transaction, the
terminal validates that the indicator “Valid for international cash
transactions” is set in the AUC.
2. To process the transaction at an ATM, the indicator for “Valid at ATMs”
shall be “1” in the AUC.
3. To process a transaction at a card acceptance device other than an ATM,
the indicator “Valid at terminals other than ATMs” shall be “1” in the
AUC.
7–4
Visa Integrated Circuit Card 7.4 Application Usage Control
If any of the above checks fail, the terminal indicates that the “Requested
Service is not Allowed for Card Product” in the TVR. Figure 7–3 illustrates
how the AUC from the card is used in this processing. If the indicated bit has
a value of “1”, that usage or capability is supported.
NOTE: The dashes in this chart indicate that the setting of this bit is not
applicable. When this data element is coded, all bits are either “0”
or “1”.
Table 7–3: Application Usage Control (AUC)
Byte b8 b7 b6 b5 b4 b3 b2b b1 Usage
1 1 - - - - - - - Valid for domestic cash transactions
1 - 1 - - - - - - Valid for international cash

transactions
1 - - 1 - - - - - Valid for domestic goods
1 - - - 1 - - - - Valid for international goods
1 - - - - 1 - - - Valid for domestic services
1 - - - - - 1 - - Valid for international services
1 - - - - - - 1 - Valid at ATMs
1 - - - - - - - 1 Valid at terminals other than ATMs
2 1 - - - - - - - Domestic cashback allowed
2 - 1 - - - - - - International cashback allowed
31 Oct 2001
7.5 Application Effective Date

Issuer-optional Application Effective Date checking ensures that the
application is active by validating that the Application Effective Date from the
card is less than or equal to the Terminal Transaction Date (local to the
terminal). If the Application Effective Date is greater than the terminal’s
Transaction Date, the terminal indicates in the TVR that the application is
not yet effective.
7.6 Application Expiration Date

Application Expiration Date checking is mandatory. The terminal validates
that the application has not expired by checking whether the Application
Expiration Date from the card is greater than or equal to the Terminal
Transaction Date (local to the terminal). If the Application Expiration Date is
less than the Terminal Transaction Date, the terminal indicates in the TVR
that the application has expired.
7–6
Visa Integrated Circuit Card 7.6 Application Expiration Date
Figure 7–1: Processing Restrictions Flow
Card Terminal B
Application AUC indicates

Version Number for transaction allowed at
ATM Device? N
card and terminal other than ATM
present? Devices?
Y
Y
N
Application
Y
Version Numbers
identical?
AUC indicates Set Requested Service
N N not Allowed for Card Y
N ATM Transaction
Allowed? Product bit to “1” in TVR
Set ICC and Terminal
Have Different
Application Versions bit
to “1” in TVR
Y
Application
AUC and Effective Date <
Issuer Country Current Date
Code present?
N
Y
Issuer AUC indicates Set Application not

Country Code = Transaction Type yet Effective bit to “1” Y
N in the TVR
Terminal Country allowed for Internat’l
Code? transactions?
Y
Y
N
Application
N
Expiration Date >
AUC indicates Set Requested Service Current Date?
Transaction Type
N Not Allowed for Card
allowed for domestic
transactions? Product to “1” in TVR
N
Set Application has

Y Expired bit to “1” in Y
the TVR
B
Terminal proceeds
to Cardholder
Verification
(Chapter 8)
31 Oct 2001

The terminal uses the READ RECORD command to obtain the Application
Version Number and Application Expiration Date from the card. The AUC and
Application Effective Date are also read from the card, if present.

During Terminal Action Analysis, the terminal compares the TVR with the
Issuer Action Codes (IACs) and Terminal Action Codes (TACs) to determine
the action to be taken if application versions differ, cards are not yet effective
or expired, or requested service not allowed for card product.
7–8
Cardholder Verification 8
Cardholder Verification is used to ensure that the cardholder is legitimate

and the card is not lost or stolen.
In Cardholder Verification, the terminal determines the Cardholder
Verification Method (CVM) to be used and performs the selected CVM. The
results of CVM processing play a role in later processing.
CVMs supported are:
●
Offline Plaintext PIN
●
Offline Enciphered PIN
● Online PIN
● Signature
Signature may be combined with the Offline PIN validation methods. CVM
processing is designed to support additional CVMs such as biometric methods
as they are adopted. With the Offline PIN methods, the validation of the PIN
is done within the card.
The terminal uses rules in a CVM List from the card to select the CVM to be
used. The selection criteria in the CVM List can include the type of
transaction (cash or purchase), the transaction amount, and the capabilities of
the terminal. The CVM List also specifies the terminal action if the CVM fails.
Cardholder Verification shall be performed as described in the EMV 2000
(EMV 4.0), Book 3, Section 2.5.12 and Section 6.5.
31 Oct 2001
Cardholder Verification Visa Integrated Circuit Card

8.2 Card Data
8.3 Terminal Data
8.4 Commands
8.5 Processing
8–2
Visa Integrated Circuit Card 8.1 Terminal Requirements

Terminals shall comply with the following Cardholder Verification
requirements:
●
PIN Pad Support—The terminal shall be designed and constructed to
facilitate the addition of a PIN pad, if one is not already present.
● CVM List Processing—If the card supports CVM processing, POS
terminals shall use the card’s CVM List to determine appropriate
cardholder verification processing for the transaction. Certain terminal
types as defined by Visa (for example, ATMs) shall be allowed to request
Online PIN entry even though it is not supported by the CVM List.
If the card does not support CVM processing, the terminal shall perform
the cardholder verification specified for Visa magnetic stripe transactions.
● Standard Terminal Messages—The terminal should support the
following Visa proprietary message:
– 32—LAST PIN TRY: Indicates that there is one PIN try remaining for
the application.
8.2 Card Data

The data from the card (described in Table 8–1) is used by the terminal during
CVM List processing. For a detailed description of these data elements and
their usage, refer to the Visa Integrated Circuit Card Specification,
Appendix A, Card and Issuer Data Element Tables.
Table 8–1: CVM List Processing—Card Data (1 of 2)
Application Currency Code Used to determine whether the CVM Conditions involving amounts can be used.
Application Interchange Profile Contains an indicator showing whether the card supports cardholder verification.
(AIP)
31 Oct 2001
Table 8–1: CVM List Processing—Card Data (2 of 2)
Cardholder Verification Method Identifies a prioritized list of methods of cardholder verification for the card
(CVM) List application. A CVM List contains the following subfields:
● Amount X—Amount used in some CVM Conditions
●
Amount Y—Second amount used in some CVM Conditions
● CVM entry—The CVM List may contain multiple entries. Each entry contains
the following subfields:
Subfield Description
CVM Code Designates the action to take if the CVM fails. Choices
are process the next CVM entry or fail CVM processing.
CVM Type The type of CVM to perform:

● Plaintext PIN verified offline
● Enciphered PIN verified online
● Plaintext PIN verified offline and signature
● Signature
● Enciphered PIN verified offline
● Enciphered PIN verified offline and signature
●
No CVM required (CVM processing is considered
successful with no additional CVM processing)
● Fail CVM processing (CVM processing is considered a
failure with no additional CVM processing)
CVM Conditions Conditions when this CVM entry should be used:
●
Always
● If transaction is cash or quasi-cash
●
If the terminal supports the CVM
● If transaction amount is less than Amount X
● If transaction amount is more than Amount X
●
If transaction amount is less than Amount Y
● If transaction amount is more than Amount Y
Note: The last 4 conditions require that the transaction be
in the card’s Application Currency.
For an example of a CVM List., refer to the Visa Integrated Circuit Card
Specification, Chapter 8, Cardholder Verification.
8–4
If Offline PIN is performed, the terminal may request the PIN Try Counter
(described in Table 8–2) from the card.
Table 8–2: Offline PIN—Card Data
PIN Try Counter Designates the number of PIN tries remaining. The card decrements the PIN Try
Counter with each unsuccessful VERIFY command received and resets it to the
PIN Try Limit if the Transaction PIN matches the Reference PIN or when a script
command to reset the counter is processed.
If the card supports Offline Enciphered PIN, the issuer may generate an ICC
PIN Encipherment public/private key pair to use solely for PIN encipherment
or may use the ICC key pair used for DDA. The card shall have the data
elements (described in Table 8–3) for whichever key pair is used.
Table 8–3: Offline Enciphered PIN—Card Data (1 of 2)
Certificate Authority Public Key With the Registered Application Provider Identifier (RID), designates the Visa CA
Index (PKI) Public Key to use to decipher the Issuer PK Certificate.
ICC PIN Encipherment or ICC Encrypted with the Issuer Private Key and contains the public key to be used in
Public Key (PK) Certificate PIN encipherment.
ICC PIN Encipherment or ICC Contains the portion, if necessary, of the public key, which does not fit into the
Public Key Remainder public key certificate.
ICC PIN Encipherment or ICC Stored in a secure location on the card. Used to decipher the enciphered PIN after
Private Key it is received at the card.
ICC PIN Encipherment or ICC Used in the algorithm to decipher the enciphered PIN.
Public Key Exponent
Issuer Public Key (PK) Encrypted with the Visa Private Key and contains the Issuer public key to be used
Certificate to decipher the ICC PIN Encipherment or ICC PK Certificate. This is the same
certificate used for DDA and SDA.
Issuer Public Key Remainder Contains the portion, if necessary, of the public key, which does not fit into the
public key certificate.
31 Oct 2001
Table 8–3: Offline Enciphered PIN—Card Data (2 of 2)
Issuer Public Key Exponent Used in the algorithm to decipher the ICC PIN Encipherment or ICC PK
Certificate.
Registered Application Provider The portion of the Application Identifier (AID), which Identifies the scheme. With
Identifier (RID) the PKI, the RID designates the Visa CA Public Key to use to decipher the Issuer
PK Certificate during Offline Enciphered PIN processing.
The card data described in Table 8–4 is used internally by the card during
Offline PIN processing.
Table 8–4: Offline PIN Processing—Card Data
Card Verification Results (CVR) Contains indicators set by the card to reflect Cardholder Verification processing.
PIN Try Limit Issuer-specified maximum number of consecutive incorrect PIN tries allowed.
Reference PIN The cardholder PIN that is stored in a secure location on the card.
8–6
8.3 Terminal Data

The terminal data (described in Table 8–5) is used during CVM processing.
For a detailed description of these data elements and their usage, see
Appendix A, Terminal and Acquirer Data Elements.
Table 8–5: CVM Processing—Terminal Data
Amount, Authorized The amount of the transaction in the transaction currency. Also referred to as the
transaction amount.
Cardholder Verification Method Indicates the results of the last CVM performed.
(CVM) Results
Enciphered PIN Data Transaction PIN enciphered at the PIN pad for online verification or for offline
verification if the PIN pad and card reader do not share a tamper-evident device.
PIN Pad Secret Key Secret DES key used by the PIN pad during Offline Plaintext PIN processing to
encipher the keyed PIN and by the card reader to decipher the enciphered PIN.
This key is required if the card reader and PIN pad do not reside in a single
tamper-evident device. This key is not used for Offline Enciphered PIN
encipherment.
Terminal Capabilities Indicates the cardholder verification methods supported by the terminal.
Terminal Verification Results Indicators are set in the TVR for the following conditions:
(TVR) ● Cardholder verification was not successful
● Unrecognized CVM
● PIN Try Limit exceeded (on current or previous transaction)
● PIN entry required and PIN pad not present or not working
●
PIN entry required, PIN pad present, but PIN was not entered
● Online PIN entered
Transaction Currency Code The currency in which the transaction is initiated.
Transaction PIN Contains value keyed by the cardholder for PIN verification.
Transaction Status Information Contains an indicator, which is set when Cardholder Verification is performed.
(TSI)
31 Oct 2001
If the terminal supports Offline Enciphered PIN, it shall have data (described
in Table 8–6) which is the same data used for SDA and DDA.
Table 8–6: Offline Enciphered PIN—Terminal Data
Certificate Authority Public Key A unique index is associated with each Visa CA Public Key. It is used to identify
Index (PKI) the public key to use for PIN encipherment.
Registered Application Provider Used with the PKI to identify the public keys associated with the scheme. Visa’s
Identifier (RID) RID is A000000003.
Visa CA Public Keys The terminal uses the selected key to decrypt the Issuer PK Certificate from the
card.
8.4 Commands
The following commands are used for Offline PIN processing.
GET DATA
May be used by the terminal during Offline PIN processing to obtain the PIN
Try Counter from the card in order to determine whether the PIN Try Limit
was exceeded on a previous transaction or is close to being exceeded. This
retrieval of the PIN Try Counter is optional for the terminal.
The data portion of the command contains the tag for the PIN Try Counter.
The card returns an SW1 SW2 other than “9000” from the GET DATA
command if the PIN Try Counter is a proprietary data element. In this case,
the terminal shall bypass the checking of the PIN Try Counter and continue
with Offline PIN processing.
GET CHALLENGE
The GET CHALLENGE command is used to obtain an unpredictable number
from the card for use with Offline Enciphered PIN.
The terminal shall support the GET CHALLENGE command if the terminal
supports Offline Enciphered PIN.
The response data field contains the unpredictable number generated by the
card.
8–8
VERIFY
Used for Offline Enciphered PIN and Offline Plaintext PIN. The VERIFY
command initiates the card comparison of the Transaction PIN and the
Reference PIN.
The terminal shall support the VERIFY command if the terminal supports
offline CVM verification.
The P2 parameter in the VERIFY command shall be:
● “80” if the CVM is Offline Plaintext PIN.
● “88” if the CVM is Offline Enciphered PIN.
The valid SW1 SW2 values in the VERIFY response are:
● “9000” if the keyed Transaction PIN matches the Reference PIN.
● “63Cx” if the PINs do not match. The “x” value representing the number of
PIN tries remaining. “63C0” means the PIN Try Limit was exceeded
during the VERIFY command processing.
● “6983” or “6984” if the PIN Try Limit was exceeded on a previous
transaction or a previous VERIFY command.
8.5 Processing
Cardholder verification involves the following two functions:
● CVM List processing—The terminal determines the CVM to use.
● CVM processing—The terminal performs the CVM selected in CVM List
processing.
8.5.1 CVM List Processing

The purpose of CVM List Processing is to determine the CVM to use for the
transaction based on rules set by the issuer (the CVM List), the capabilities of
the terminal, and characteristics of the transaction.
If the Application Interchange Profile (AIP) indicates that CVM processing is
not supported, the terminal shall perform the CVM designated for Visa
magnetic stripe transactions.
If the AIP indicates that CVM processing is supported but no CVM List is
received from the card, the terminal shall set the ICC data Missing bit in the
TVR to “1” and terminate Cardholder Verification without setting the
Cardholder Verification was Performed bit in the TSI.
31 Oct 2001
If a CVM List is received from the card and the card’s Application Interchange
Profile (AIP) indicates that CVM processing is supported, the terminal shall
process the CVM List. The terminal shall process each CVM List entry in the
order in which it appears in the CVM List.
1. Selecting the CVM Entry
The terminal shall select the CVM entry when all of the following are
true:
– The CVM Condition Code is understood by the terminal.
– The card data required by the condition is present (for example,
Application Currency Code when the CVM list includes a CVM
Condition with an amount check).
– The condition in the CVM Condition Code is satisfied. The “Terminal
Supports CVM” condition is satisfied if Terminal Capabilities indicates
that the CVM is supported. The conditions involving amounts require
that the Transaction Currency Code equals the Application Currency
Code.
Otherwise, the terminal shall go to the next entry.
2. Processing the CVM Entry
If the conditions expressed in the CVM Condition Code are satisfied, the
terminal shall attempt to perform the CVM. If the terminal does not
recognize the CVM, the terminal shall set Unrecognized CVM bit to “1” in
the TVR and perform the action designated in the CVM Code.
Details on processing specific CVMs are described in the next section of
this chapter.
3. CVM Success
If the CVM is performed successfully, Cardholder Verification is complete
and successful.
4. CVM Failure
If the CVM fails, the terminal shall check the CVM Code to see whether
the terminal should fail CVM processing or go to the next CVM entry:
– If the CVM Code indicates “Fail CVM,” the terminal shall set the
Cardholder Verification was not Successful bit to “1” in the TVR.
Cardholder Verification is complete.
– If the CVM Code indicates “Apply Succeeding CVM,” the terminal
shall process the CVM entry if one is present.
8–10
5. No More CVM Entries

If the terminal reaches the end of the CVM List, Cardholder Verification
has failed and the terminal shall set Cardholder Verification was Not
Successful bit to “1” in the TVR.
6. Completion of Cardholder Verification
Cardholder Verification is complete if any one of the following occurs:
– Any one CVM passes
– A CVM fails and the CVM entry’s CVM Code indicates “Fail CVM”
– The CVM List is exhausted
If the last CVM processed was “No CVM Required”, the terminal shall
perform the Visa-specified method of cardholder verification for the
terminal type if one has been specified. For example, if Visa has specified
signature as the default cardholder verification method for the POS
terminal, the POS terminal shall print a signature line on the receipt.
When CVM List processing completed, the terminal shall set Cardholder
Verification was Performed to “1” in the Transaction Status Information
(TSI).
31 Oct 2001
Figure 8–1 illustrates how a terminal could perform CVM List processing.
Figure 8–1: CVM List Processing
Card’s Terminal Terminal

AIP shows card performs Visa proceeds to
N A
supports magnetic stripe Terminal Risk
CVM? CVM processing Management
Terminal sets Terminal

CVM List ICC Data N recognizes
N
present? Missing in the CVM?
TVR
Y
Y
Terminal selects first Terminal

Terminal sets
CVM in CVM List supports
“Unrecog. CVM”
in TVR CVM?
Y
N
Terminal N CVM = PIN?

N understands CVM
Condition?
Y
Y Terminal sets “ PIN Terminal

entry required but PIN performs
pad not present or processing for
CVM
N not working” in TVR specified CVM
Condition data
available?
CVM
CVM Condition N
Y A Successful?
satisfied?
N CVM Code= Y
Y Apply
Succeeding CVM
Entry? Terminal sets
Cardholder
Verification was
N
CVM Code = Performed in TSI.
Any more CVM
N Fail CVM
entries?
Terminal sets
“cardholder Visa
Y verification not specified CVM was No
default CVM for Y CVM Req’d?
successful” in
terminal?
TVR. Y
Terminal selects next
N
CVM in CMV List.
N
Terminal completes
Terminal
Cardholder
performs mag
Verification
stripe CVM
Processing
8–12
8.5.2 CVM Processing

The terminal processes CVM entries according to the rules for the individual
CVM.
8.5.2.1 Offline Plaintext PIN

The following requirements apply when the CVM is Offline Plaintext PIN.
With Offline Plaintext PIN the Transaction PIN is sent in the clear to the
card. For PIN security, the terminal may encipher the PIN at the PIN pad
with the PIN Pad Secret Key and decipher it at the card reader using the
same key.
If the terminal does not support Offline PIN or if the PIN pad is
malfunctioning, the terminal shall:
●
Set PIN Entry Required and PIN Pad not Present or not Working to “1” in
the TVR.
● Proceed as though the CVM failed (that is, perform the action specified in
the CVM Code of the CVM List entry).
If the merchant or cardholder directs the terminal to bypass PIN entry, the
terminal shall:
● Set PIN Entry Required, PIN Pad Present, but PIN was not Entered to “1”
in the TVR.
● Consider the CVM unsuccessful.
● Continue with the action specified in CVM Code in the card’s CVM List
entry.
● PIN Try Limit Exceeded shall not be set to “1” in the TVR.
When the terminal determines that an offline PIN is to be entered, the
terminal shall either prompt immediately for PIN entry or shall check the
card’s PIN Try Counter.
1. Checking the PIN Try Counter
If the terminal is to check the PIN Try Counter, the terminal issues a GET
DATA command to the card. The GET DATA response from the card
either contains the value of the PIN Try Counter or is an error response
with no PIN Try Counter.
a. GET DATA Error Response
A response other than “9000” indicates that the PIN Try Counter is a
proprietary data element, which is not available to the terminal. If a
response other than “9000” is received, the terminal shall bypass PIN
Try Counter checking and prompt for PIN Entry.
31 Oct 2001
b. No PIN Tries Remaining

If the PIN Try Counter is zero indicating no remaining PIN tries, the
terminal shall:
■ Not allow offline PIN entry.
■ Set PIN Try Limit Exceeded to “1” in the TVR.
■ Not display any message regarding PINs.
■ Perform the action specified in the CVM List entry’s CVM Code.
c. PIN Tries Remaining
If the response to the GET DATA command contains PIN Try Counter
value of “1” indicating one remaining PIN try, the terminal should
display the Visa proprietary message of “Last PIN Try” as described in
the Terminal Requirements section of this chapter.
The terminal shall display “Enter PIN” to prompt for PIN entry.
8–14
Figure 8–2 shows how Checking the PIN Try Counter could be performed.
Figure 8–2: PIN Try Counter Checking
CARD TERMINAL
Receive GET DATA GET DATA Issue GET DATA
and respond with command for PIN Try Counter
PIN try counter if
card allows
SW1 SW2 =
GET DATA response
9000?
N
PIN Try Counter N PIN Try Counter

= 0? = 1?
Y Y
Set PIN Try Limit

Display “Last PIN Try” N
Exceeded in TVR.
Do not display any

Display “Enter PIN”
PIN messages
Perform CVM Code Proceed to PIN

action. Checking
2. Enciphering the PIN

If the card reader and PIN pad are integrated into a single tamper-evident
device and the CVM is Offline Plaintext PIN, no encipherment of the
Transaction PIN is performed. The plaintext PIN is passed from the PIN
pad to the card reader.
If the card reader and PIN pad are in separate devices and the CVM is
Offline Plaintext PIN, the PIN pad shall encipher the Transaction PIN
with the PIN Pad Secret Key according to the International Organisation
for Standardisation (ISO) 9564-1 prior to passing it to the card reader. The
card reader shall decipher the PIN when received. The PIN is passed in
the clear from the card reader to the card.
31 Oct 2001
If the CVM is Offline Enciphered PIN, the PIN may be RSA enciphered at
the PIN pad or may be enciphered using other means between the PIN
pad and the ICC reader and RSA enciphered at the card reader and
passed to the card in enciphered format.
3. PIN Checking using VERIFY command
When the offline PIN is entered, the terminal shall transmit a VERIFY
command containing the Transaction PIN to the card. The VERIFY P2
parameter shall be “80” to indicate Offline Plaintext PIN.
a. PIN Verification (performed by the card)
■ If the card’s PIN Try Counter is zero, the card does no PIN
compare and returns a VERIFY response with SW1 SW2 equal to
“6983” or “6984”.
■ If the Transaction PIN and the card’s Reference PIN are not equal,
the card decrements its PIN Try Counter and returns SW1 SW2
equal to “63Cx” where x is the number of PIN tries remaining.
■ If the PINs are equal, the card resets the PIN Try Counter to the
PIN Try Limit and returns SW1 SW2 of “9000”.
b. PINs Match
If the Transaction PIN matched the Reference PIN (SW1 SW2 equal
“9000”), the terminal should display the “PIN OK” message.
c. PIN Try Limit Exceeded on Previous Transaction
If the PIN Try Limit was exceeded on a previous transaction
(SW1 SW2 equal “6983” or “6984”), the terminal shall:
■ Set PIN Try Limit Exceeded to “1” in the TVR.
■ Perform the action specified in CVM Code of the CVM List entry.
8–16
d. Non-Matching PINs
If the PINs did not match (SW1 SW2 equal “63Cx”), the terminal
action is based upon the value of “x”, which represents the number of
PIN tries remaining.
■ If zero PIN tries remain, the terminal:
– Should display the “Incorrect PIN” message.
– Shall set PIN Try Limit Exceeded to “1” in the TVR.
– Shall not transmit any further VERIFY command messages to
the card.
■ If the PIN tries remaining is nonzero, the terminal:
– Should display the “Incorrect PIN” message followed by the
“Enter PIN” message to prompt for PIN entry.
– If the PIN tries remaining is one, should display the Visa
proprietary message of “Last PIN Try” between these two
messages.
– After PIN entry, shall issue another VERIFY command to the
card and repeat the Offline PIN process.
If PIN verification is successful prior to the PIN Try Counter being

decremented to zero, the terminal should display the “PIN OK”
message.
31 Oct 2001
Figure 8–3 illustrates how the terminal could perform Offline PIN processing.
Figure 8–3: Offline PIN Processing
Card Offline PIN

Terminal
Processing
Display “Enter PIN”
Cardholder enters
PIN
Enciphered
PIN
Encriphered PIN? Y processing
Terminal Issues
Card receives VERIFY command VERIFY command
Verify comand with Entered PIN.
and responds
PINs Matched
VERIFY command SW1 SW2 = Terminal proceeds to

Y Display “PIN OK” Terminal Risk
response 9000?
Management
N
PIN Try Limit Exceeded Previously
Terminal performs
Set PIN Try Limit
SW1 SW2 = action specified in
Y Exceeded to “1” in
6983 or 6984? CVM Code of CVM
TVR
List entry.
N
Invalid Response from VERIFY Command
SW1 SW2 = Terminate

N
63Cx? transaction
Display
“Incorrect PIN”
PIN Try Limit Exceeded on This Transaction
Terminal performs
PIN Tries Terminal sets “PIN
Remaining action specified in
Y Try Limit Exceeded”
= 0? CVM Code of CMV
in TVR.
List entry.
N More PIN Tries Remaining
PIN Tries Display

Remaining Y “Last PIN Try”
=1?
8–18
8.5.2.2 Offline Enciphered PIN

The steps for processing for Offline Enciphered PIN are the same as for
Offline Plaintext PIN except for the following differences, which are detailed
in the EMV 4.0, Book 2, Chapter 7.
NOTE: Step numbers correspond to those in Section 8.5.2.1.
2. Enciphering the PIN
If the CVM is Offline Enciphered PIN, the PIN may be RSA enciphered at
the PIN pad or may be enciphered using other means between the PIN
pad and the ICC reader and RSA enciphered at the card reader and
passed to the card in enciphered format.
If the terminal has obtained the ICC PIN Encipherment Key data from
the card, the terminal recovers the ICC PIN Encipherment Public Key in
the same manner that the ICC Public Key is recovered during DDA (See
Chapter 6, Offline Data Authentication, for details). If the ICC PIN
Encipherment Key data was not received from the card during Read
Application Data, the terminal recovers the ICC Public Key in this same
manner. If the data for either key recovery is not available, the CVM shall
fail.
The terminal shall issue a GET CHALLENGE command to the card to
request an unpredictable number.
Upon receiving the GET CHALLENGE response containing the
unpredictable number from the card, the terminal shall:
– Concatenate the Transaction PIN (in PIN Block format), the
unpredictable number from the card, and a terminal-generated
Random Pad Pattern as shown in the EMV 4.0, Book 2, Section 7.2,
Table 21.
– Encipher the concatenated data with the ICC PIN Encipherment
Public Key previously recovered from the ICC PIN Encipherment PK
Certificate, or the ICC Public Key if the ICC PIN Encipherment Public
Key is not available.
3. PIN Checking using the VERIFY command
The terminal sets the P2 parameter of the VERIFY command to “88” to
indicate that the PIN is enciphered.
Upon receiving the VERIFY command with P2 equal to “88”, the card
deciphers the Transaction PIN using the ICC Data Encipherment Private
Key, if present, or if not present, the ICC Private Key.
4. Processing
After the PIN is deciphered, PIN checking continues in the same manner
as with Offline Plaintext PIN described in Section 8.5.2.1, Step 3.
31 Oct 2001
The processing for Offline Enciphered PIN is shown in Figure 8–4.
Figure 8–4: Offline Enciphered PIN Processing
Card Terminal
Enciphered
PIN
Processing
ICC
ICC PK
Enciphered
N Certificate N Fail CVM Processing
PIN PK Certificate
available?
available?
Y
Y
Use ICC Enciphered Use ICC PK

PIN PK Certificate. Certificate.
Recover Public Key

(See DDA section of
Chapter 6)
Generate ICC GET Issue GET

Unpredictable CHALLENGE CHALLENGE
Number command command
GET CHALLENGE Concatenate data

response w/ICC (ICC Unpred.
Unpredictable Number Number, PIN, etc)
Encipher
concatenated data
with public key.
Set P2 to “88” in
VERIFY command.
Issue VERIFY
command and
VERIFY
continue processing
command
as with Offline
Plaintext PIN.
8–20
8.5.2.3 Online PIN

The following requirements apply when the selected CVM is Online PIN:
● If the terminal does not support Online PIN or if the PIN pad is
malfunctioning, the terminal shall:
– Set PIN Entry Required and PIN Pad not Present or not Working to
“1” in the TVR.
– Perform the action specified in CVM Code for the CVM List entry.
● If the merchant or cardholder directs the terminal to bypass PIN entry,
the terminal shall:
– Set PIN Entry Required, PIN Pad Present, but PIN was not Entered to
“1” in the TVR.
– Perform the action specified in CVM Code of the CVM List entry.
● The terminal shall allow a PIN to be entered for Online PIN verification
even if the card’s PIN Try Limit is exceeded.
● If the Online PIN is successfully entered, the terminal shall set Online
PIN Entered to “1” in the TVR. The CVM is considered to have passed.
The processing for Online PIN is shown in Figure 8–5.
Figure 8–5: Online PIN Processing
Terminal proceeds to Enciphered PIN is

Encipher PIN Set Online PIN
Online PIN Terminal Risk included in online
according to current Entered to 1
Management authorization
standards. in TVR.
(Chapter 9) (Chapter 10)
8.5.2.4 Signature
When the CVM is signature and the terminal supports the signature process,
the CVM is considered to have passed and Cardholder Verification is
complete. At the end of the transaction, the terminal shall print a receipt with
a line for the cardholder’s signature.
If the terminal does not support the signature process, the terminal shall
proceed to the action specified in the CVM Code for the CVM List entry.
31 Oct 2001
The processing for Signature is shown in Figure 8–6.
Figure 8–6: Signature Processing
Terminal performs
Terminal
SIGNATURE action specified in
supports N
CVM Code of CVM
signature?
List entry.
Terminal Risk
Management.
8.5.2.5 Signature and Offline PIN

If the CVM combines Signature with Offline PIN or Offline Enciphered PIN,
both methods in the CVM must be successful for Cardholder Verification to be
considered successful.
8.5.2.6 Fail CVM

When the CVM is “Fail CVM Processing,” the CVM is considered to have
failed.
The processing for Fail CVM is shown in Figure 8–7.
Figure 8–7: Fail CVM Processing
Fail CVM Terminal performs

action specified in
CVM Code of CVM
List entry.
8–22
8.5.2.7 No CVM Required

If the CVM is “No CVM Required,” the CVM is considered to have passed.
Cardholder Verification is complete.
The processing for No CVM Required is shown in Figure 8–8.
Figure 8–8: No CVM Required Processing
NO CVM REQUIRED Terminal has

Visa Specified Default Y Perform Default CVM
CVM?
Terminal Risk
Management
(Chapter 9)

The terminal receives the Application Interchange Profile (AIP) from the card,
which indicates whether the card supports Cardholder Verification.
The terminal reads the CVM List and other data used for Cardholder
Verification from the card.
31 Oct 2001

The terminal uses TVR indicators including Cardholder Verification
indicators along with rules from the card (IACs) and terminal (TACs) in its
decision on whether to approve offline, go online for an authorization, or
decline offline.
Card Action Analysis
The card uses Cardholder Verification results in its decision on whether to
approve offline, go online for an authorization, or decline offline.
The card considers whether the PIN Try Limit was exceeded on a previous
transaction in its decision on whether to go online or decline offline. The
Application Default Action (ADA) provides the card rules for the action to
take.
Completion
After a failed attempt to go online for an authorization for a transaction where
the PIN Try Limit was exceeded on a previous transaction, the card uses
parameters in ADA to determine whether to decline the transaction.
Issuer-to-Card Script Processing
The PIN CHANGE/UNBLOCK command can be used to reset the PIN Try
Counter to equal the PIN Try Limit. The Reference PIN may also be changed
with this command.
The APPLICATION UNBLOCK command can be used to unblock an
application which was blocked during CVM processing.
8–24
Terminal Risk Management 9
Terminal Risk Management provides issuer authorization for higher-value

transactions and ensures that transactions initiated from cards go online
periodically to protect against threats that might be undetectable in an offline
environment.
Although Issuers are mandated to set the Terminal Risk Management is to be
Performed bit to “1” in the Application Interchange Profile (AIP) to trigger
Terminal Risk Management, terminals shall perform Terminal Risk
Management regardless of the card settings.
Terminal Risk Management shall be performed as described in the EMV 2000
(EMV 4.0), Book 3, Section 6.6, and Book 4, Sections 2.3.5 and 2.4.
31 Oct 2001
Terminal Risk Management Visa Integrated Circuit Card

9.1 Card Data
9.2 Terminal Data
9.3 GET DATA Command
9.4 Terminal Exception File
9.5 Merchant Forced Transaction Online
9.6 Floor Limits
9.7 Random Transaction Selection
9.8 Terminal Velocity Checking
9.9 New Card Check
9.10 End Terminal Risk Management
9–2
9.1 Card Data

The card data elements used in Terminal Risk Management are listed and
Table 9–1: Terminal Risk Management—Card Data
Application Identifier (AID) Identifies the Terminal Floor Limit to be used during Terminal Risk Management
Application Primary Account Cardholder account number used in terminal exception file checking.
Number (PAN)
Application Transaction Counter A counter of the number of transaction processed by the card since the application
(ATC) was put on the card and is used in terminal velocity checking.
Last Online Application The ATC value of the last transaction that went online. If terminal velocity checking
Transaction (ATC) Register or new card checking by the terminal is required by the card, this data element
and both of the data elements listed below must be present.
Lower Consecutive Offline Limit This data element (tag “9F14”) is the issuer-specified preference for the maximum
number of consecutive offline transactions allowed before a transaction must be
sent online if the terminal is online capable. It is used in terminal velocity checking.
Upper Consecutive Offline Limit This data element (tag “9F23”) is the issuer-specified preference for the maximum
number of consecutive offline transactions allowed before transactions must be
declined offline. It is used in terminal velocity checking.
31 Oct 2001
9.2 Terminal Data

The terminal data elements used in Terminal Risk Management are listed
and described in Table 9–2. For a detailed description of these elements and
Table 9–2: Terminal Risk Management—Terminal Data
Amount, Authorized This numeric data element (tag “9F02”) stores the amount (excluding
adjustments) for the current transaction. It is used in floor limit checking.
Maximum Target Percentage to Value used in terminal risk management for random selection of transactions for
be used for Biased Random online processing.
Selection
Target Percentage to be used Value used in terminal risk management for random selection of transactions for
for Random Selection online processing.
Terminal Floor Limit This data element (tag “9F1B”) indicates the floor limit in the terminal in
conjunction with the Application Identifier for the application. It is used in floor limit
checking and random selection of transactions for online processing.
Terminal Verification Results A series of indicators in which the results of offline processing from a terminal
(TVR) perspective are recorded. It is used to record the results of all terminal risk
management checks.
Threshold Value for Biased Value used in terminal risk management for random selection of transactions for
Random Selection online processing.
Transaction Log To prevent the use of split sales to bypass floor limits, the terminal may have a
transaction log of approved transactions. This log, minimally contains the
Application PAN and transaction amount, and optionally contains the Application
PAN Sequence Number and Transaction Date. The number of transactions to be
stored and maintenance of the log is outside the scope of this specification. This
log, if present, may be used in terminal floor limit checking.
Transaction Status Information Indicates the terminal functions performed during the transaction. This data
(TSI) element is not provided in the online authorization and clearing messages, but is
used by the terminal to indicate that terminal risk management was performed.
9–4
Visa Integrated Circuit Card 9.3 GET DATA Command
9.3 GET DATA Command

The GET DATA command is used by the terminal to read the Last Online
ATC Register and the Application Transaction Counter (ATC), if not already
present in the terminal, from the card. This information is used to support
terminal velocity checking and new card checking by the terminal. See
Appendix B, Commands for Financial Transactions, for details on use of the
GET DATA command.
SW1 SW2 is “9000” in the command response when the requested data is
returned.
9.4 Terminal Exception File

If a terminal exception file is present, the terminal checks whether the
Application Primary Account Number (PAN) on the card is listed on the
exception file.
If the card is listed on the exception file, the terminal sets the Card Appears
on Terminal Exception File bit to “1” in the TVR.
9.5 Merchant Forced Transaction Online

At online-capable terminals, the merchant may indicate to the terminal that
the transaction should be processed online.
If the merchant forces the transaction online, the terminal sets the Merchant
Forced Transaction Online bit to “1” in the TVR.
9.6 Floor Limits

Floor limit checking is performed so that transactions with amounts above the
terminal floor limit are sent online for authorization.
The terminal compares the Amount, Authorized to the Terminal Floor Limit.
If the transaction amount is greater than or equal to the floor limit, the
terminal sets the Transaction Exceeds Floor Limit bit to “1” in the TVR. Even
when the floor limit is zero, the terminal performs this check and sets the
Transaction Exceeds Floor Limit bit to “1” in the TVR.
If the terminal supports a transaction log, the terminal checks to see if there
is a log entry with the same Application PAN, and optionally, the same
Application PAN Sequence Number.
If there are multiple entries with the same PAN, the terminal selects the most
recent entry. The terminal adds the amount for the current transaction to the
amount stored in the log for that entry.
31 Oct 2001
If the sum of the current Amount, Authorized and the previous amount is
greater than or equal to the Terminal Floor Limit, the terminal sets the
Transaction Exceeds Floor Limit bit to “1” in the TVR.
9.7 Random Transaction Selection

Terminals capable of supporting offline and online transactions shall
randomly select transactions for online processing.
If the Amount, Authorized is less than the Threshold Value for Biased
Random Selection, Random Selection is performed. The terminal generates 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 will be selected for online processing.
If the transaction is selected, the terminal sets the Transaction Selected
Randomly for Online Processing bit to “1” in the TVR.
To assist in understanding the random transaction selection process described
in the EMV 4.0, Book 3, Section 6.6.2, three examples are provided in this
section.
Assume that the terminal contains the parameters to be used for random
transaction selection (shown in Table 9–3) and the terminal has generated a
random number of 25.
Table 9–3: Example Terminal Parameters
Terminal floor limit 100
Terminal random number 25
Threshold for Biased Random Selection 40
Target percentage for Random Selection 20%
Maximum target percentage for Biased Random Selection 50%
EXAMPLE 1
The transaction amount is 20. Since the transaction
amount (20) is less than the threshold for Biased Random
Selection, random selection is performed. The terminal
random number (25) is compared to the target
percentage (20%), and because the random number is
higher the transaction is not selected for online processing.
9–6
Visa Integrated Circuit Card 9.8 Terminal Velocity Checking
EXAMPLE 2
The transaction amount is 60. This is above the threshold
for Biased Random Selection but below the terminal floor
limit, so biased random selection is performed.
The transaction amount is 20 above the threshold, which is
one-third of the difference between the terminal floor limit
and the threshold for biased random selection
(100 - 40 = 60). Therefore, one-third of the difference
between the maximum target percentage and the target
percentage (50% - 20% = 30% x 1/3 = 10%) is added to the
target percentage to result in a target for this transaction
value of 30% (10% + 20%).
The terminal’s random number is 25 (less than the target
of 30), so the transaction is selected for online processing.
EXAMPLE 3
The transaction amount is 150. Because this is above the
terminal floor limit, the transaction is not subjected to
random selection. It is selected for online processing by the
terminal’s floor limit checking function.
9.8 Terminal Velocity Checking

Velocity checking permits issuers to request online processing after a specified
number of consecutive offline transactions. Terminal Velocity Checking shall
be supported by offline-capable terminals. Issuers may elect not to support
velocity checking by the terminal.
If both the Lower Consecutive Offline Limit (“9F14”) and Upper Consecutive
Offline Limit (“9F23”) have been provided by the card in Read Application
Data processing, the terminal shall perform velocity checking. If either of
these data objects is not present in the card, the terminal shall bypass this
processing.
The terminal sends a GET DATA command to the card requesting the Last
Online ATC Register and the ATC. The card returns these data elements in
the command response.
The terminal compares the ATC and the Last Online ATC Register:
●
If the ATC minus the Last Online ATC Register is greater than the Lower
Consecutive Offline Limit, the terminal sets the Lower Consecutive
Offline Limit Exceeded bit to “1” in the TVR.
31 Oct 2001
● If the ATC minus the Last Online ATC Register is greater than the Upper
Consecutive Offline Limit, the terminal sets the Upper Consecutive
Offline Limit Exceeded bit to “1” in the TVR.
NOTE: Similar velocity checks may be performed by the card during Card
Action Analysis. The TVR bits for Lower and Upper Consecutive
Offline Limit Exceeded are not set during the Card Action Analysis
checks.
9.9 New Card Check

New card checking by the terminal is performed if the Upper and Lower
Consecutive Offline Limits are present in the card and the Last Online ATC
Register is provided to the terminal in the response to GET DATA. This
register is reset during Completion after an online approval based on Issuer
Authentication results and card parameters.
The terminal sends the GET DATA command to the card requesting the Last
Online ATC Register (if this data element is not already present in the
terminal). The card responds to the GET DATA command with the Last
Online ATC Register.
The terminal checks the Last Online ATC Register. If the register is zero, the
terminal sets the New Card bit to “1” in the TVR.
NOTE: A new card check similar to this may be performed by the card during
Card Action Analysis. The TVR bit for New Card is not set during the
Card Action Analysis checks.
9.10 End Terminal Risk Management

Upon completion of Terminal Risk Management, the terminal shall set the
Terminal Risk Management was Performed bit to “1” in the Transaction
Status Information (TSI).
9–8
Visa Integrated Circuit Card 9.10 End Terminal Risk Management
Figure 9–1: Terminal Risk Management Processing Flow (1 of 2)
A
Terminal
Transaction log
present
Terminal exception in terminal?
file present?
Y
Y
Amount,
Log Entry Present
N authorized + amount
which matches current Y
in log > terminal
Card appears on transaction
N floor limit
exception file?
N Y
N
Y
Terminal sets
Terminal sets Card Transaction amount > Transaction Exceeds
Y
Appears on Terminal terminal floor limit Floor Limit bit to “1” in
Exception File bit to “1” in TVR
TVR
N
N
Merchant Terminal sets Transaction

elected to force Terminal randomly
Seleted Randomly for
transaction selects transaction for Y
Online Processsing bit to
online? online processing
“1” in TVR
Y
N
Terminal sets Merchant
Forced Transactions N
Online bit to “1” in TVR
B
31 Oct 2001
Draft 12/18/00
Visa Public 9–9
Figure 9–2: Terminal Risk Management Processing Flow (2 of 2)
Terminal
Lower and
Upper Consecutive
N
Offline Limits read
by terminal?
Terminal issues GET

DATA
to obtain ATC and Last
Online ATC Register
Both ATC and Last Terminal sets ICC Data

Online ATC Register N
Missing bit to “1” in TVR
returned?
Y
Terminal sets both Lower
Consecutive Offline Limit
Exceeded and Upper
(ATC-Last
Online ATC Register) >
Exceeded bits to “1” in TVR
Lower Consecutive
Offline Limit?
Terminal sets Lower

Exceede bit to “1”
in TVR
(ATC-
Last Online ATC
Register) > Upper N N
Consecutive Offline
Limit
Terminal sets Upper

Exceeded bit to “1”
in TVR
Terminal
proceeds to
Last Online
N Terminal Action
ATC Register = 0
Analysis
(Chapter 10)
Y
Terminal sets “new card”

bit in CVR
9–10

The following data is read from the card:
● Primary Account Number, used in checking the terminal exception file
● Upper and Lower Consecutive Limits, used in Terminal Velocity
Checking, if present on the card

Based on card and terminal settings, the terminal determines what action to
take if:
● Card was on terminal exception file
● Merchant forced transaction online
● Floor Limits exceeded
● Transaction randomly selected for online processing
● Velocity Checking amounts or counters exceeded
● New card
31 Oct 2001
Terminal Action Analysis 10
In Terminal Action Analysis, the terminal applies rules set by the issuer in
the card and by the acquirer in the terminal to the results of offline processing
to determine whether the transaction should be approved offline, declined
offline, or sent online for an authorization.
Terminal Action Analysis involves two steps:
1. Review Offline Processing Results—The terminal reviews the results
of offline processing recorded in the TVR to determine whether the
transaction should go online, be approved offline, or be declined offline.
This process considers issuer-defined criteria from the card called Issuer
Action Codes (IACs) and Visa-defined criteria in the terminal called
Terminal Action Codes (TACs).
2. Request Cryptogram Processing—The terminal requests a
cryptogram from the card.
Terminal Action Analysis shall be performed as described in the EMV 2000

10.1 Card Data
10.2 Terminal Data
10.3 GENERATE APPLICATION CRYPTOGRAM (AC) Command
10.4 Processing
31 Oct 2001
Terminal Action Analysis Visa Integrated Circuit Card
10.1 Card Data

The card data elements described in Table 10–1 were previously received from
the card and are used during Terminal Action Analysis. For a detailed
description of card data elements and their usage, refer to the Visa Integrated
Circuit Card Specification, Appendix A, Terminal and Acquirer Data
Elements.
Table 10–1: Offline Processing Results—Card Data
Issuer Action Codes (IACs) Each IAC contains a series of bits, defined during issuer personalization, which
correspond to the bits in the Terminal Verification Results (TVR). The three IACs
are:
● IAC—Denial
The bits, which correspond to the TVR conditions for which the issuer would
like an offline decline. If the terminal does not receive an IAC—Denial from the
card, the terminal uses all “0”s.
● IAC—Online
like to go online for an authorization. If the terminal does not receive an
IAC—Online from the card, the terminal uses all “1”s.
● IAC—Default
like an offline decline if online processing is not available. If the terminal does
not receive an IAC—Default from the card, the terminal uses all “1”s.
10–2
The card data described in Table 10–2 is used during the Request Application
Cryptogram phase.
Table 10–2: Request Application Cryptogram—Card Data
Card Data Management Object The CDOL1 contains the tags and lengths for the terminal data objects, which are
List 1 (CDOL1) needed by the card to generate the first application cryptogram, and for other
processing.
10.2 Terminal Data

The terminal data elements described in Table 10–3 are used in the review of
offline processing results. For a detailed description of these terminals and
Table 10–3: Offline Processing Results—Terminal Data (1 of 2)
Authorization Response Code Indicates the terminal’s requested disposition for the transaction.
Terminal Action Codes (TAC) The TACs are Visa-defined bit-strings, which are similar to the card’s Issuer Action
Codes (IACs) except that they are stored in the terminal. The TACs are three data
elements which each consist a series of bits, which correspond to the bits in the
TVR. The TACs are:
● TAC—Denial
The acquirer sets the bits, which correspond to the TVR conditions, which
should cause an offline decline. The TAC—Denial shall contain a value of
X'0010000000'. This TAC value causes a decline for the Service Not Allowed
condition.
Note: Acquirers not supporting all of the VSDC data in the authorization
request shall decline transactions offline if DDA fails using a TAC—Denial
value of X'0810000000'.
31 Oct 2001
Table 10–3: Offline Processing Results—Terminal Data (2 of 2)
Terminal Action Codes (TAC) ● TAC—Online

(continued) The acquirer sets the bits, which correspond to the TVR conditions, which
should generate an online authorization.
The TAC—Online shall contain a value of X'D84004F800'. This TAC value

generates an online authorization when:
– Offline data authentication is not performed or failed

– The PAN is on the terminal exception file
– The application is expired
– An Online PIN is entered
– The transaction exceeds the floor limit
– The upper (“9F23”) or lower consecutive offline limit (“9F14”) is exceeded
– The transaction is randomly selected for online processing
– The merchant forced the transaction online
● TAC—Default
The acquirer sets the bits, which correspond to the TVR conditions for which
the transaction defaults to an offline decline if online processing is not
available.
The terminal shall contain the value of “D84000A800”. This TAC value
generates a decline if the transaction cannot be sent online for authorization
when:
– Offline data authentication is not performed or failed

– The PAN is on the terminal exception file
– The application is expired
– The transaction exceeds the floor limit
– The Upper Consecutive Offline Limit (“9F23”) is exceeded
– The merchant forced the transaction online
Note: Markets not supporting offline data authentication in cards may remove
the TAC—Online and TAC—Default settings for offline data authentication not
performed resulting in a TAC—Online value of X'584004F800' and a
TAC—Default of value of X'584000A800'.
A means for updating the TACs by the acquirer shall be supported as defined in
the EMV 4.0 Book 4, Section 6.2.
Terminal Verification Results The TVR is a series of bits which are set during transaction processing to
(TVR) represent transaction processing status as seen from the perspective of the
terminal.
10–4
Visa Integrated Circuit Card 10.3 GENERATE APPLICATION CRYPTOGRAM (AC)
Terminal Specification, Version 1.4.0 Command
The terminal data described in Table 10–4 is used during the Request
Application Cryptogram phase.
Table 10–4: Request Application Cryptogram—Terminal Data
Data Objects specified in The terminal includes the data objects specified by the issuer in the CDOL1 in the
CDOL1 by the issuer GENERATE APPLICATION CRYPTOGRAM (AC) command.

In the Request Application Cryptogram step, the terminal issues the card a
GENERATE APPLICATION CRYPTOGRAM (AC) command. The terminal
indicates in P1, the reference control parameter of this command, if Combined
DDA/AC Generation is to be performed. The specific requirements for the
GENERATE AC command are in Appendix B, Commands for Financial
Transactions, and in the EMV 4.0, Book 3, Section 2.5.5.
The data portion of this command contains the terminal data requested by the
card in CDOL1. The P1 parameter of the command designates the type of
cryptogram being requested as shown in the EMV 4.0, Book 3, Table I–10.
If the TC Hash Value is to be input to the Application Cryptogram algorithm,
the card will have referenced the TC Hash Value in CDOL1, and the terminal
shall generate and transmit the TC Hash Value in the GENERATE AC
command along with the other data elements referenced in the CDOL1.
31 Oct 2001
10.4 Processing
Terminal Action Analysis consists of two steps:
●
Review of Offline Processing Results
● Generate Cryptogram Processing
10.4.1 Review Offline Processing Results

The review of offline processing results is performed after Terminal Risk
Management but also may be performed earlier to eliminate the need for
unnecessary processing. For example, Terminal Action Analysis could be
performed after Static Data Authorization (SDA) to eliminate the need for
Cardholder Verification when SDA failure results in an offline decline.
This review is performed entirely within the terminal using processing rules
called IACs, which were previously received, from the card and rules from the
terminal called TACs.
During processing the terminal compares bits in the IACs and TACs to the
corresponding bits in the Terminal Verification Results (TVR). If
corresponding bits in the TVR and the IAC or TAC are both set to “1”, the
disposition for the IAC or TAC is used.
10–6
The following example illustrates how the comparisons work.

EXAMPLE: IAC USAGE EXAMPLE
The issuer wishes to decline transactions offline if Offline Dynamic Data Authentication fails or
if the PIN Try Limit is exceeded so the IAC—Denial bits from the card are set as below:
Offline DDA Failed PIN Try Limit Exceeded
↓ ↓
IAC—Denial 00001000 00000000 00100000 00000000 00000000
The terminal records offline processing results in the TVR. In the following transactions, the
application is expired. In Transaction 2, Offline DDA has also failed.
Transaction 1: The application is expired so the TVR is set to:
Expired Application
↓
TVR 00000000 01000000 00000000 00000000 00000000
IAC—Denial 00001000 00000000 00100000 00000000 00000000
Decline offline is not set here because the TVR and IAC—Denial have no corresponding bits that
are set to “1”.
Transaction 2: Offline DDA has failed and the application is expired so the TVR is set to:
Offline DDA Failed Expired Application ¯ ¯
↓ ↓
TVR 00001000 01000000 00000000 00000000 00000000
IAC-Denial 00001000 00000000 00100000 00000000 00000000
Offline DDA Failed is set to “1” in the IAC—Denial and the TVR so the transaction disposition is
set to decline offline.
Similar comparisons are done with the other IACs and the TACs.
31 Oct 2001
The processing steps taken by the terminal are:

1. The terminal compares the IAC—Denial to the TVR. If no IAC—Denial is
present, the terminal uses a default value of X'0000000000'. If any
corresponding bits in the IAC—Denial and the TVR are both “1”, the
terminal:
– Sets the Authorization Response Code to “Z1” (Offline Decline).
– Sets the cryptogram type in the P1 parameter of the GENERATE AC
command to an Application Authentication Cryptogram (AAC).
– Proceeds to the Request Application Cryptogram step.
2. The terminal does a similar compare with the TAC—Denial and the TVR.
If no TAC—Denial is present, the terminal uses a default value of
X'00000000'. If any corresponding bits are set to “1”, the same actions as
done for the IAC—Denial should be performed.
NOTE: Programs could perform the IAC and TAC comparisons to the TVR
with the following logic:
If ((IAC—Denial) OR (TAC—Denial) AND TVR) not = zeros,
Then decline the transaction
Similar logic could be used for the Online and Default conditions.
3. If the terminal has online capabilities, it compares the IAC—Online and
TAC—Online to the TVR. If no IAC—Online is present, the terminal uses
a default value of X'11111111'. If no TAC—Online is present, the terminal
uses a default value of X'00000000'.
If any corresponding bits in the IAC—Online and TVR are both “1”, the
terminal:
– Sets the cryptogram type in the GENERATE AC P1 parameter to an
Authorization Request Cryptogram (ARQC) to request an online
cryptogram.
10–8
4. If the terminal does not have online capabilities, it compares the

IAC—Default and the TAC—Default to the TVR. If no IAC—Default is
present, the terminal uses a default value of X'11111111'. If no
TAC—Default is present, the terminal uses a default value of
X'00000000'.
If any corresponding bits are both set to “1”, the terminal:
– Sets the Authorization Response Code to “Z3” (Offline Decline Unable
To Go Online).
– Sets the cryptogram type to AAC in the P1 parameter of the
GENERATE AC command.
5. If none of the previous compares found corresponding bits which were
both “1”, the terminal:
– Sets the Authorization Response Code to “Y1” (Offline Approve).
– Sets the cryptogram type in the P1 parameter of the GENERATE AC
command to a Transaction Certificate (TC).
10.4.2 Request Application Cryptogram

The second phase of Terminal Action Analysis is requesting a TC, ARQC or
AAC from the card depending upon the outcome of the review of the offline
processing results.
The terminal formats the GENERATE AC command and issues it to the card.
The terminal indicates in P1 (sets bit 6 to 1) of this command if Combined
DDA/AC Generation is to be performed.
31 Oct 2001
10.4.3 Process Flow

Figure 10–1 shows how Terminal Action Analysis might be performed.
Figure 10–1: Terminal Action Analysis
Terminal uses IAC-

IAC-Denial
N Denial default value
present?
of all bits set to “0”
Terminal uses TAC-

TAC-Denial
N Denial default value
present?
of all bits set to “0”
Are any
corresponding bits
set in both TVR and the
IAC-Denial or
TAC-Denial?
Online capable
terminal?
Y N
Terminal uses IAC- Terminal uses IAC-

Online default IAC-Online IAC-Default Default default
N N
value of all bits set present? present? value of all bits set
to “1” to “1”
Y Y
Terminal uses Terminal uses TAC-

TAC-Online TAC-Online Default default
N TAC-Default present? N
default value of all present? value of all bits set
bits set to “0” to “0”
Y
Y
Are any
corresponding bits set in
both TVR & IAC-Default or Y
TAC-Default?
Are any
corresponding bits set
in TVR & IAC-Online or N N
TAC-Online?
Terminal sets Auth Resp
Code to Z (offline
Y Terminal sets Auth
approved)
Resp Code to Z3
P1 (Cryptogram type) (offline declined)
in GEN AC = ARQC P1 (Cryptogram type) in
(Send Online) GEN AC = TC (Approve)
P1 (Cryptogram type)
in GEN AC = AAC
DDA/ Terminal sets P1 in
Card AC Generation to Y GENERATE AC indicating
(Decline)
be done? DDA/AC Generation req'd
N
Proceed to Card
Action Analysis GENERATE AC Terminal issues 1st
(See Chapter 11) command Generate AC
10–10

The terminal reads application data from the card, which includes the CDOL1
and Issuer Action Codes if they are present on the card.
Offline Data Authentication, Processing Restrictions, Cardholder
Verification, and Terminal Risk Management
These offline functions set bits in the TVR based upon the results of
processing. Terminal Action Analysis compares these TVR bits to the bits in
the IACs and TACs to determine transaction disposition.
During Offline Data Authentication, the terminal determines if Combined
DDA/AC Generation is to be performed. If so, the terminal saves this
information so that the Reference Control parameter of the first
GENERATE AC command can be updated.

During Card Action Analysis performs additional risk management to
determine whether it will override the terminal’s Terminal Action Analysis
decision to approve offline, decline offline, or send online.
31 Oct 2001
Card Action Analysis 11
Card Action Analysis allows issuers to perform velocity checking and other
risk management, which is internal to the card. Visa proprietary card risk
management features described in this section include checking:
●
Activity on previous transactions
● If card is a new card
●
Velocity counters
Card Action Analysis shall be performed as described in the EMV 2000
(EMV 4.0), Book 3, Section 6.8.
11.1 Card Data
11.2 Terminal Data
11.4 Processing
31 Oct 2001
Card Action Analysis Visa Integrated Circuit Card
11.1 Card Data

The card data elements used in Card Action Analysis are listed and described
in Table 11–1. For a detailed description of these elements and their usage,
refer to the Visa Integrated Circuit Card Specification, Appendix A, Terminal
and Acquirer Data Elements.
Table 11–1: Card Action Analysis—Card Data
Card Risk Management Data List of data objects with their associated labels (tags) and lengths, to be passed
Object List 1 (CDOL1) from the terminal to the card application with the first GENERATE APPLICATION
CRYPTOGRAM (AC) command.
The GENERATE AC Command Response data elements are listed and

described in Table 11–2.
Table 11–2: GENERATE AC Command Response Data
Application Cryptogram The value of the cryptogram.
Application Transaction Counter A counter of the number of transactions initiated since the application was put on
(ATC) the card.
Cryptogram Information Data Contains indicators for:

● The type of cryptogram returned by the card:
– An Application Authentication Cryptogram (AAC) for a decline
– A Transaction Certificate (TC) for an approval
– An Authorization Request Cryptogram (ARQC) for online processing (first
GENERATE AC only)
● Other status information including Service Not Allowed.
Issuer Application Data Contains proprietary application data for transmission to the Issuer. This includes
the CVR.
Card Verification Results A Visa proprietary data element containing indicators, which are set, based upon
the results of offline processing for current and previous transactions.
11–2
11.2 Terminal Data

The terminal data element used in Card Action Analysis is listed and
described in Table 11–3.
Table 11–3: Card Action Analysis—Terminal Data
Data Requested in CDOL1 The terminal provides the data requested by the card in the CDOL1. For a list of
data required, refer to the Visa Integrated Circuit Card Specification, Appendix E,
Cryptogram Versions Supported.

The GENERATE APPLICATION CRYPTOGRAM (AC) command response is
returned by the card at the end of Card Action Analysis. It contains the data
shown in Table 11–3. See Appendix B, Commands for Financial Transactions,
for detail on use of the GENERATE AC Command. This command may
indicate if Combined DDA/AC Generation is to be performed.
31 Oct 2001
Card Action Analysis Visa Integrated Circuit Card
11.4 Processing
The terminal does no processing during Card Action Analysis.
The GENERATE AC command, which the card receives from the terminal,
contains a parameter indicating the cryptogram type, which the terminal is
requesting. This cryptogram type indicates the terminal’s transaction decision
(approve offline, decline offline, send online).
Based on the results of this Card Risk Management performed by the card
(including checking activity on previous transactions, if card is a new card,
and velocity counters), the card determines a transaction response. The card’s
response may override the terminal’s decision indicated by the Cryptogram
Type:
● The card may override the terminal’s decision to approve offline by
deciding to either send online or decline offline.
● The card may override the terminal’s decision to go online by deciding to
decline offline.
These decision rules are shown in Table 11–4.
Table 11–4: Card’s Response to First GENERATE AC Command
Card Responds
AAC ARQC TC
Terminal AAC Decline — —

Requests
ARQC Decline Go Decline —
TC Decline Go Decline Approve
11.4.1 Response to GENERATE AC for Combined DDA/AC Generation

If the terminal has indicated in the GENERATE AC command that Combined
DDA/AC Generation is to be performed and the card is returning a TC or an
ARQC, the card generates a dynamic signature and returns it in the response
to GENERATE AC.
11–4
11.4.2 Standard Response to GENERATE AC

The card returns a cryptogram and indicates the response decision by the
cryptogram type.

The terminal reads the Card Risk Management Data Object List 1 (CDOL1)
from the card.
At the end of Terminal Action Analysis, the terminal issues the first
GENERATE AC command to the card to request an Application Cryptogram
and to provide data requested by the card in CDOL1.

Online Processing
At the beginning of Online Processing, the terminal receives the response to
the first GENERATE AC command returned by the card during Card Action
Analysis.
Online Processing uses the cryptogram type received from the card in this
response to determine whether the transaction should be declined or approved
offline or whether an online authorization should be performed.
Completion
If online processing was requested, but the terminal was unable to send the
transaction online, additional card and terminal processing is performed.
● The terminal performs additional analysis (similar to Terminal Action
Analysis) using the Issuer Action Code (IAC) Denial and Terminal Action
Code (TAC) Denial to determine which cryptogram (AAC or TC) to request
in the final GENERATE AC command.
● The card performs additional Card Risk Management checks to determine
final transaction disposition.
31 Oct 2001
Online Processing 12
Online Processing allows the issuer’s host computer to review and authorize
or decline transactions using the issuer’s host-based risk management
parameters. In addition to performing traditional online fraud and credit
checks, host authorization systems may perform Online Card Authentication
using a card-generated dynamic cryptogram and may consider offline
processing results in the authorization decision.
The response from the issuer may include post-issuance updates to the card
and an issuer-generated cryptogram, which the card can validate to ensure
that the response came from the valid issuer or both. This validation is called
Issuer Authentication.
This chapter describes the terminal online processing functions, which are
new with Visa Smart Debit and Visa Smart Credit (VSDC). Online
processing functions, which are also performed with magnetic, stripe-read,
and key-entered transactions are not described.
Online processing shall be performed as described in the EMV 2000
(EMV 4.0), Book 3, Part II, Section 6.9, and Book 4, Part I, Section 2.3.8.
This chapter is organized in the following manner:
12.2 Card Data
12.3 Terminal Data
12.4 Commands
12.5 Processing
31 Oct 2001
Online Processing Visa Integrated Circuit Card

Online processing may be requested by the terminal or the card.
12.2 Card Data

The card data described in this section is used by the terminal during Online
Processing.
12.2.1 GENERATE AC Response Data

The GENERATE AC response received from the card is coded according to
Format 1 or Format 2 as described in the EMV 4.0, Book 3, Part I,
Section 2.5.5.4.
If the response is Format 1, the value field in the response consists of a
concatenation of the value portion of the data listed and described in
Table 12–1.
Table 12–1: Online Processing—GENERATE AC Response Card Data
Application Cryptogram The cryptogram value from the card.
(ATC) the card.
Cryptogram Information Data Contains an indicator of the type of cryptogram. An Authorization Request
Cryptogram (ARQC) is designated by b'10' in the first two bits (bits 8–7).
Issuer Application Data Issuer Application Data is a Visa-mandatory field used to transmit Visa
discretionary data to the terminal for input to the online request message or
clearing record. The terminal passes this data through to the issuer.
If the response is Format 2, the response data is present as BER-TLV data

elements within tag “77”. If the Format 2 response contains tag “9F4B”
(Signed Dynamic Application Data), the Application Cryptogram is contained
within this data element and the terminal shall validate the dynamic
signature.
12–2
12.2.2 Other Card Data

The terminal also uses the card data element listed and described in
Table 12–2 during Online Processing.
Table 12–2: Online Processing—Other Card Data
Application Interchange Profile The AIP contains a flag, which indicates whether the card supports Issuer
(AIP) Authentication. The AIP is received during Initiate Application Processing from the
card in the GET PROCESSING OPTIONS response.
12.3 Terminal Data

The data from the terminal used during the Issuer Authentication portion of
Online Processing is listed and described in Table 12–3.
Table 12–3: Online Processing—Terminal Data
Transaction Status Information Contains a bit for Issuer Authentication was Performed which the terminal sets
(TSI) to “1” when Issuer Authentication is performed.
Terminal Verification Results Contains a bit indicating whether Issuer Authentication Was Unsuccessful which
(TVR) the terminal sets to “1” when Issuer Authentication fails.
31 Oct 2001
12.3.1 Online Request Message Data

In addition to the data elements required for magnetic stripe initiated
transaction, as a minimum, the terminal shall provide the VSDC data objects
listed in Table 12–4 in the online message in support of Cryptogram
Version 10 and 14 and VSDC processing at the host computer.
Table 12–4: Visa Smart Debit Credit (VSDC) Data Objects Required in Online Message
Data Objects Source
Amount, Authorized Transaction amount from terminal
Amount, Other Portion of transaction amount that is cashback from terminal (if
present)
Application Cryptogram Authorization Request Cryptogram (ARQC) received from card in

GENERATE APPLICATION CRYPTOGRAM (AC) response
Application Interchange Profile (AIP) Received from card during Initiate Application Processing
Application PAN Sequence Number Received from card during Read Application Data
Application Transaction Counter (ATC) Received from card in GENERATE AC response
Interface Device (IFD) Serial Number From terminal or acquirer (optional)
Issuer Application Data Received from card in GENERATE AC response
Terminal Capabilities From terminal or acquirer
Terminal Country Code From terminal
Terminal Verification Results (TVR) Transaction data from terminal
Transaction Currency Code From terminal
Transaction Date From terminal
Transaction Type Transaction data from terminal
Unpredictable Number Transaction data from terminal
12–4
The format of the online message from the terminal is outside the scope of the
Visa Integrated Circuit Card Specification. The VisaNet online message
format is described in the Visa Smart Debit/Credit System Technical Manual.
The VSDC data elements in the online message may be considered in the
issuer host decision to decline or approve the transaction. This issuer decision
logic is outside the scope of the Visa Integrated Circuit Card Specification.
12.3.2 Online Response Data

The data elements listed in Table 12–5 are optional in the response message
from the issuer to the acquirer. If present, these data elements shall be
transmitted by the acquirer to the terminal.
Table 12–5: New Authorization/Financial Transaction Response Data Elements
Issuer Authentication Data Contains the following subfields:

● Authorization Response Cryptogram (ARPC)—cryptogram generated by
issuer host
● Authorization Response Code—response code used in generation of ARPC
Issuer Script Contains command data from the issuer to be used to update the card
application.
The Authorization Response Code in Table 12–5 is the code generated by the
issuer during online processing and used in the generation of the
Authorization Response Cryptogram (ARPC). This code shall not change in
transmission from the issuer to the terminal. The terminal shall transmit this
Authorization Response Code to the card as part of the Issuer Authentication
Data.
31 Oct 2001
12.4 Commands
Online Processing uses the GENERATE APPLICATION CRYPTOGRAM (AC)
command response and the EXTERNAL AUTHENTICATE command and
response.
GENERATE APPLICATION CRYPTOGRAM (AC) response
Prior to sending the online request, the terminal receives the card’s response
to the GENERATE AC command.
The command response is described in the EMV 4.0, Book 3, Part I,
Section 2.5.5.4, and in Appendix B, Commands for Financial Transactions.
EXTERNAL AUTHENTICATE
If Issuer Authentication is to be performed after the online response is
received, the terminal issues an EXTERNAL AUTHENTICATE command to
ask the card to perform Issuer Authentication. The command is described in
the EMV 4.0, Book 3, Part I, Section 2.5.4 and Appendix B, Commands for
Financial Transactions.
The command contains the Issuer Authentication Data shown in Table 12–5.
The command response SW1 SW2 is “9000” if Issuer Authentication was
successful.
12.5 Processing
Online Processing includes processing the online request, processing the
online response, and optionally performing Issuer Authentication.
12.5.1 Online Request

After receiving the response to the first GENERATE AC command from the
card, the terminal performs either Standard Online Processing only or
Combined DDA/AC Generation Processing.
12.5.1.1 Combined DDA/AC Generation Processing

If Combined DDA/AC Generation was indicated in the GENERATE AC
command and the response to GENERATE AC is an ARQC or TC, the
terminal performs the processing indicated in the EMV 4.0, Book 2,
Section 6.6. This includes the following processing:
1. Uses the ICC Public Key to unlock the dynamic signature (Signed
Dynamic Application Data) and recover the hash of data elements.
2. Checks that the Cryptogram Information Data recovered matches the
Cryptogram Information Data received in the clear in the GENERATE AC
response.
12–6
3. Calculates a hash from the dynamic data elements that are in the clear.
4. Checks that the calculated hash matches the hash recovered from the
Signed Dynamic Application Data.
If any of the above steps fail, the terminal indicates Combined DDA/AC
Generation failed in the TVR and proceeds to Completion.
If all of the above steps are successful, Combined DDA/AC Generation has
passed and the terminal continues processing as described in the next section.
12.5.1.2 Standard Online Processing

If Standard Online Processing is to be performed:
1. Set the Card Risk Management Was Performed bit in the TSI to “1”.
2. The terminal shall transmit an online request message if all of these
conditions are true:
– The terminal requested a Transaction Certificate (TC) or an
Authorization Request Cryptogram (ARQC) in the GENERATE AC
command
– The Cryptogram Information Data in the card’s response indicates an
ARQC is being returned
– Combined DDA/AC Generation did not fail
– The terminal has online capability
3. The terminal shall terminate the transaction if any of the following
conditions occur:
– The terminal requested an Application Authentication Cryptogram
(AAC) and the card returns an ARQC or a TC
– The terminal requested an ARQC and the card returns a TC
4. The terminal shall proceed to the Completion function described in
Chapter 13, Completion, if any of the following conditions occurs:
– Combined DDA/AC Generation was performed and failed
– The card responds with an AAC or TC
– The card responds with an ARQC but the terminal is unable to process
the transaction online
31 Oct 2001
12.5.2 Online Response

During Online Response processing, the terminal receives the online response
from the issuer host and determines whether Issuer Authentication should be
performed. The terminal proceeds to:
● The Issuer Authentication step described below in Section 12.5.3 if both of
the following conditions are met:
– The authorization response contains the Issuer Authentication Data
– The card supports Issuer Authentication, as shown in the Application
Interchange Profile (AIP)
● The Completion function described in Chapter 13, Completion, if either of
the following conditions occurs:
– The authorization response does not contain Issuer Authentication
Data
– The card does not support Issuer Authentication, as shown in the AIP
12.5.3 Issuer Authentication

If Issuer Authentication is to be performed:
1. The terminal shall set the Issuer Authentication was Performed bit to “1”
in the Transaction Status Information (TSI).
2. The terminal shall transmit an EXTERNAL AUTHENTICATE command
to the card.
3. The card performs Issuer Authentication and transmits the EXTERNAL
AUTHENTICATE command response to the terminal indicating whether
Issuer Authentication was successful or failed.
4. If the EXTERNAL AUTHENTICATE response indicates that Issuer
Authentication failed (SW1 SW2 not equal to “9000”), the terminal shall
set the Issuer Authentication was Unsuccessful bit to “1” in the Terminal
Verification Results (TVR).
5. The terminal shall then proceed to the Completion function described in
Chapter 13, Completion.
12–8
12.5.4 Flow
The Online Processing flow is shown in Figure 12–1.
Figure 12–1: Online Processing
Card Terminal Issuer
Card Action Analysis Set Card Risk Combined Terminal validates

Card returns GENERATE Management DDA/AC
Y dynamic signature &
response from first AC response Performed to “1” in requested and TC
or ARQC? hash of static data
GENERATE AC TSI
Y Valid?
N
N
ARQC &
terminal can N
process online? If AAC returned or
dynamic signature
is not valid, the
A
terminal indicates
Y DDA/AC Generation
failed in TVR
Issuer returns
Terminal transmits online auth. Authorization Request authorization
request to issuer through acquirer with ARQC
response
Authorization Response
Terminal receives authorization
with optional ARPC
response
and/or issuer script
Data in response?
N
Y
AIP shows
card supports Issuer N
Authentication?
Y
Card performs Terminal issues Completion.
EXTERNAL (See Chapter 13)
Issuer EXTERNAL
AUTHENTICATE
Authentication AUTHENTICATE
command
(validates ARPC) command
Terminal receives
EXTERNAL
EXTERNAL
AUTHENTICATE
AUTHENTICATE
response
response
Terminal sets Issuer

Auth. Performed to “1”
in TSI
Response Set Issuer

shows Issuer Authentication was
N
Authentication Unsuccessful to “1”
passed? in TVR
A Completion
(See Chapter 13)
31 Oct 2001

In Card Action Analysis, the card sets Cryptogram Information Data (CID) to
indicate the cryptogram type. An ARQC is used if the transaction should be
sent online for authorization. The CID is returned to the terminal in the
GENERATE AC response.

Completion
The card uses the Issuer Authentication results to determine the disposition
of the transaction and whether to reset certain counters and indicators. If
Combined DDA/AC Generation was performed and failed and the response to
the first GENERATE AC was:
● Approve (TC), the transaction shall be declined with a Z1.
● Go Online (ARQC), the terminal shall issue a second GENERATE AC
requesting an AAC.
Issuer-to-Card Script Processing
If the online response contained an Issuer Script, the card may consider the
results of Issuer Authentication determine whether these updates may be
applied.
12–10
Completion 13
Completion is performed by the terminal and the card to conclude the

transaction processing. Completion includes the following processing:
●
If online processing was requested and the terminal did not support
online processing or the online authorization was unable to complete, the
terminal and card perform additional analysis to determine whether the
transaction should be approved or declined offline.
● If Combined DDA/Generate AC was performed and failed, the terminal
processes as follows:
– If a TC was returned in the first GENERATE AC, the terminal issues
an offline decline
– If an ARQC was returned in the first GENERATE AC, the terminal
requests an AAC in the second GENERATE AC
● An issuer’s online approval may be changed to a decline based upon Issuer
Authentication results and card options.
●
Indicators and counters are set to reflect what has occurred during
transaction processing.
● After an online authorization, indicators and counters may be reset based
upon Issuer Authentication status and card options.
The terminal may perform additional functions subsequent to completion,
such as allowing the cardholder signature to be verified, printing a receipt,
and capturing data for clearing. Additional Completion functions may be
performed by the terminal if they do not interfere with the defined
Completion functions.
Completion shall be performed as described in the EMV 2000 Integrated
Circuit Card Specification for Payment Systems, Version 4.0 (EMV 4.0),
Book 3, Part II, Section 6.11, and Book 4, Part I, Section 8.2.
31 Oct 2001
Completion Visa Integrated Circuit Card
This chapter is organized as follows:

13.1 Card Data
13.2 Terminal Data
13.3 GENERATE AC Command
13.4 Transaction Authorized Offline
13.5 Transaction Authorized Online
13.6 Online Processing Requested, Transaction Was Not Sent Online
13.1 Card Data

The terminal uses the card data elements listed and described in Table 13–1
during Completion. For a detailed description of card elements and their
Table 13–1: Completion—Card Data
Card Risk Management Data A list of data objects (tags and lengths) to be passed to the card with the final
Object List 2 (CDOL2) GENERATE AC command
Issuer Action Code—Default Contains a series of bits that correspond to the bits in the TVR. The issuer sets a
bits to “1” in this IAC if the issuer would like the corresponding TVR condition to
generate an offline decline when an online authorization cannot be completed.
See Chapter 10, Terminal Action Analysis, for more information on the
IAC—Default.
13–2
The final GENERATE AC response data elements used in Completion are

listed and described in Table 13–2.
Table 13–2: Completion—Final GENERATE AC Response Data
Application Cryptogram Contains the value of the cryptogram.
(ATC) the card.
Card Verification Results (CVR) A Visa proprietary data element containing indicators that are set based upon the
results of offline processing for current and previous transactions.
Cryptogram Information Data Contains indicators including the type of cryptogram returned by the card:
(CID) ● An Application Authentication Cryptogram (AAC) for a decline
● A Transaction Certificate (TC) for an approval
● An Authorization Request Cryptogram (ARQC) for online processing (first
GENERATE AC only)
Issuer Application Data Contains proprietary application data for transmission to the Issuer. This includes
the CVR.
31 Oct 2001
13.2 Terminal Data

The terminal data elements listed and described in Table 13–3 are used by the
terminal during Completion. For a detailed description of terminal data
elements and their usage, see Appendix A, Terminal and Acquirer Data
Elements.
Table 13–3: Completion—Terminal Data
Authorization Response Code A terminal data element provided to the card which indicates the disposition of the
transaction.
Y1 = Offline approved
Z1 = Offline declined
Y3 = Unable to go online (offline approved)
Z3 = Unable to go online (offline declined)
Terminal Verification Results A terminal data element used to record offline processing results, such as SDA
(TVR) failure or floor limit exceeded, from a terminal perspective.
Terminal Action Code—Default Contains a series of Visa-defined bits that correspond to the bits in the TVR.
When a bit is set to “1” in this TAC an offline decline is generated if the
corresponding TVR condition is true and an online authorization cannot be
completed.
See Chapter 10, Terminal Action Analysis, for additional information on the
TAC—Default.
13.3 GENERATE AC Command

The GENERATE APPLICATION CRYPTOGRAM (AC) command is used by
the terminal to request that the card provide a cryptogram indicating the
cards authorization response.
The P1 parameter in the command indicates the type of cryptogram being
requested as shown in the EMV 4.0, Book 3, Part I, Section 2.5.5, Table II-10.
The data portion contains the data specified in the CDOL2 received from the
card during Read Application Data.
The response to the command contains the data shown in Table 13–2.
13–4
Visa Integrated Circuit Card 13.4 Transaction Authorized Offline
13.4 Transaction Authorized Offline

When the card responded with a Transaction Certificate (TC) or an
Application Authentication Cryptogram (AAC) in response to the first
GENERATE AC command, the terminal shall complete the transaction
offline.
The terminal should display a message to indicate the action taken (approved,
declined, or service not allowed) as indicated in the Cryptogram Information
Data (CID) returned in the response to the first GENERATE AC and as
shown in Table 13–4.
If the TVR indicates that Combined DDA/AC Generation failed, the
transaction is declined by the terminal as follows:
● If a TC was returned in the first GENERATE AC command, the
transaction is declined with a Z1 Response Code
● If an ARQC was returned in the first GENERATE AC command, the
terminal requests an AAC in the second GENERATE AC
Table 13–4: Offline Transaction Disposition Response
First GENERATE AC response cryptogram type Authorization

in CID Response Code Transaction Disposition
TC and Combined DDA/AC Generation not performed Y1 Offline approved

or Passed
AAC Z1 Offline declined
ARQC or TC and Combined DDA/AC Generation Z1 Offline declined

Failed
31 Oct 2001
13.5 Transaction Authorized Online
13.5.1 Transmit Final GENERATE AC to the Card

If the online authorization was successfully completed, the terminal issues a
final GENERATE AC command to the card to request additional card analysis
and a final Application Cryptogram.
The terminal uses the Authorization Response Code received from the issuer
in the online authorization response to determine the type of cryptogram to
request from the card:
● If the issuer has approved the transaction (Authorization Response
Code = 00, 10, or 11), the terminal requests an approval (TC).
● If the issuer has requested a referral (Authorization Response
Code = 01 or 02), it is recommended that the terminal request a decline
(AAC).
● If the Authorization Response Code does not indicate approve or refer, the
terminal requests an AAC.
For additional information on Authorization Response Codes (V.I.P. Field 39),
refer to the V.I.P. System Technical Reference, Volume 2, Field and Code
Descriptions.
13.5.2 Terminal Receives Final GENERATE AC Response

When the terminal receives the card’s response to the GENERATE AC
command, it performs the steps described in the following sections.
13.5.2.1 Issuer-to-Card Script Processing

Before completing the transaction, the terminal shall process the Issuer
Script, if present in the online message as described in Chapter 14, Issuer-to-
Card Script Processing.
The terminal shall not display a message indicating that the transaction has
been approved or declined until after the completion of Issuer Script
processing to ensure that the card was not removed from the terminal during
Issuer Script processing.
If Issuer Script processing was performed for the transaction, the terminal
should ensure that a message, such as a clearing or advice is transmitted that
contains the results of Issuer Script processing. The message may be
transmitted for reasons other than Issuer Script processing or may be
transmitted solely for the purpose of conveying the Issuer Script Results.
13–6
Visa Integrated Circuit Card 13.5 Transaction Authorized Online
13.5.2.2 Terminal Requested an AAC in the Final GENERATE AC

If the terminal requested an AAC in the final GENERATE AC command, the
terminal responds with a decline regardless of the cryptogram type returned
by the card in the final GENERATE AC response. The terminal shall complete
the transaction and display a message indicating that the transaction was
declined.
13.5.2.3 Terminal Requested a TC in the Final GENERATE AC

If the card responds with a TC, the terminal shall complete the transaction
and display a message indicating that the transaction was approved.
If the card responds with an AAC after the final GENERATE AC, the terminal
shall complete the transaction and display a message indicating that the
transaction was declined.
NOTE: At an ATM, if a cash disbursement or account transfer transaction was
declined by the card because of an issuer authentication failure, after
the card transmits the AAC to the ATM in the response to the final
GENERATE AC command, the ATM shall transmit a reversal. If a
balance inquiry transaction is declined for the same reason, the ATM
shall not display the balance.
At a POS device, if an online-approved purchase transaction is
declined by the card because of an Issuer Authentication failure, a
reversal is required if the acquirer’s authorization system is single
message or host-data-capture.
31 Oct 2001
13.6 Online Processing Requested, Transaction Was Not Sent Online
13.6.1 Check IAC and TAC-Default Settings

If online processing is requested and the terminal does not support online
processing or is unable to send the transaction online, the terminal performs
Terminal Action Analysis using the Issuer Action Code (IAC)—Default and
the Terminal Action Code (TAC)—Default. This processing is identical to the
process described in Chapter 10, Terminal Action Analysis, except that only
the default IACs and TACs are used.
13.6.2 Issue Final GENERATE AC Command

Based on the results of this processing, the terminal sets the P1 parameter in
the final GENERATE AC command to indicate that an AAC (decline) or TC
(approval) is being requested. The data specified in the CDOL2 is included in
the data portion of the command. The Authorization Response Code in this
data is determined as shown in Table 13–5.
Table 13–5: Online Transaction Disposition Response
Authorization
Terminal Requests Response Code Transaction Disposition
TC Y3 Unable to go online (offline approved)
AAC Z3 Unable to go online (offline declined)
The terminal then issues the final GENERATE AC command that includes
the Authorization Response Code.
13.6.3 Terminal Completes Transaction

Upon receipt of the card’s response to the final GENERATE AC command, the
terminal performs the following processing.
13.6.3.1 Terminal Requested AAC in Final GENERATE AC

If the terminal requested an AAC in the final GENERATE AC, the terminal
shall complete the transaction as a decline regardless of the Cryptogram Type
returned by the card. The terminal shall display a message indicating that the
transaction was declined.
13–8
Visa Integrated Circuit Card 13.6 Online Processing Requested, Transaction Was
Terminal Specification, Version 1.4.0 Not Sent Online
13.6.3.2 Terminal Requested TC in Final GENERATE AC

If the terminal requested a TC in the final GENERATE AC, it examines the
Cryptogram Type specified in the Cryptogram Information Data returned in
the GENERATE AC response.
● If the card responds with a TC, the terminal shall complete the
transaction and display a message indicating that the transaction was
approved.
● If the card responds with an AAC, the terminal shall complete the
transaction and display a message indicating that the transaction was
declined.
31 Oct 2001
Figure 13–1: Completion Processing Flow
Terminal
Card
Terminal analyzes
first GENERATE AC
response
Set Authorization
Cryptogram = Y Response Code to Z1 B
AAC? (decline)
N
Set Auth.
Combined Resp. Code
Cryptogram Y DDA/AC Gen Y
= TC? to Z1
failed?
(decline)
N N
Set P1 in Set Auth.
ARQC & Resp.Code to
DDA/AC Gen. Y GEN AC to A
failed? AAC (decline) Y1 (approve)
N
C
Transaction ((IAC-Def.
completed online? N OR TAC-Def.) & N
TVR) = 0?
Set Authorization
Y
Y Y Response Code
to Z3 & P1 to AAC
Set P1 in GEN AC to Set Authorization
TC (approval) or AAC Response Code
(decline) based on to Y3 & P1 to TC
Auth. Resp. Code
Final Issue Final

Card receives Final GENERATE AC C
GENERATE AC
Generate AC command
Command
Card responded
Card responds to with a TC?
Final Receives Final
Final GENERATE AC
GENERATE AC GENERATE AC
with TC (approve) or
Response response
AAC (decline) Y
N
Terminal
Terminal processes requested an Y
Issues Script if in AAC?
auth. response
B
A
N
Terminal responds Terminal responds

with an approval with a decline
13–10

The card’s response to the first GENERATE AC may indicate a TC or AAC
indicating an offline approval or decline.
Online Processing
The Authorization Response Code is received in the authorization response.
31 Oct 2001
Issuer-to-Card Script Processing 14
Issuer-to-Card Script Processing permits issuers to change personalized data

on cards without reissuance. With this function the issuer transmits
commands in issuer scripts contained in the authorization response message.
The terminal passes these commands to the card where they are executed if
security requirements are satisfied.
Issuer-to-Card Script Processing shall be performed as described in the EMV
This chapter is organized in the following manner:
14.1 Card Data
14.2 Terminal Data
14.3 Online Response Data
14.4 Commands
14.5 Processing
31 Oct 2001
Issuer-to-Card Script Processing Visa Integrated Circuit Card
14.1 Card Data

During Issuer-to-Card Script Processing, the terminal uses no data elements
from the card.
14.2 Terminal Data

The terminal data listed and described in Table 14–1 is used in Issuer-to-Card
Script Processing. For a detailed description of these elements and their
Table 14–1: Issuer-to-Card Script Processing—Terminal Data
Terminal Verification Contains two script related flags:

Results (TVR) ● Issuer Script Failed before final GENERATE APPLICATION CRYPTOGRAM (AC)
Command—shall be set to “1” if Issuer Script processing fails
● Issuer Script Failed after final GENERATE AC Command—shall be set to “1” if Issuer
Script processing fails
Transaction Status The TSI a bit, which is set to “1” when Issuer-to-Card Script processing is performed.
Information (TSI)
Issuer Script Results Issuer Script Results are returned to the issuer through a clearing message, another
message such as a reversal, the next online authorization, or an offline advice message. It is
a 5–byte field defined as follows:
Byte 1 Contains the results of script processing and the sequence number of the
command, which failed script processing. This sequence number is zero if
script processing is successful.
Bytes 2–5 Contain the Issuer Script Identifier received in the Issuer Script.
Although it is preferable that the terminal transmit the full five-byte Issuer Script Results to
the acquirer, it is acceptable for the terminal to transmit only the first byte indicating script
results. If this is done, the following shows the mapping from the one-byte Issuer Script
Results transmitted by the terminal to the five-byte Issuer Script Results transmitted by the
acquirer to Visa.
Mapping Terminal Issuer Script Results to Acquirer Issuer Script Results
Terminal to Acquirer Acquirer to V.I.P./BASE II
Issuer Script Results (only 1 byte is transmitted: Map 1 byte transmitted by

byte 1, indicating actual script results) terminal into first byte; zero fill
next 4 bytes (Script Identifier)
14–2
Visa Integrated Circuit Card 14.3 Online Response Data
14.3 Online Response Data

The response to the online authorization request may contain the data
(described in Table 14–2) that is used in Issuer-to-Card Script Processing.
Table 14–2: Issuer-to-Card Script Processing—Online Response Data
Issuer Script This version of the Visa Integrated Circuit Card Specification supports at most
one Issuer Script per response. The Issuer Script may contain one or more
commands. In a subsequent version of this specification, issuers may transmit
more than one Issuer Script. The tag for the script should be “72”. The format of
the Issuer Script is shown in Figures 5 and 6 of the EMV 4.0, Book 3,
Section 6.10.
14.4 Commands
The Visa-defined Issuer Script Commands support the functions listed below
and are described in detail in the Card Volume of the specification and in the
EMV 4.0, Book 3, Section 2.5, and the Visa Integrated Circuit Card
Specification, Appendix C, Commands for Financial Transactions. Issuer
proprietary commands may also be received and should be passed through to
the card.
APPLICATION BLOCK
The command blocks the use of the selected application. If during the
processing of a transaction, the application is blocked, the terminal shall
continue to process the transaction through completion.
APPLICATION UNBLOCK
Unblocking the application reverses the APPLICATION BLOCK status.
Unblocking of an application occurs only at a special device as designated by
the issuer. The processing by this device is described in the Visa Integrated
Circuit Card Specification, Chapter 14, Issuer-to-Card Script Processing.
CARD BLOCK
The CARD BLOCK command is a post-issuance command that permanently
disables all applications on the card.
If the card is blocked during the processing of a transaction, the terminal shall
continue to process the transaction through completion.
31 Oct 2001
PIN CHANGE/UNBLOCK
The PIN CHANGE/UNBLOCK command provides the issuer the capability
either to unblock the offline PIN or to simultaneously change and unblock the
reference PIN.
PIN changes should only be performed within a secure environment controlled
by the issuer.
PUT DATA
The PUT DATA command allows specific primitive data objects in the card to
be updated.
UPDATE RECORD
The UPDATE RECORD command is used to update a record in a file with the
data provided in the command data field.
14.5 Processing
The terminal shall process Issuer Scripts as described in the following
sections.
14.5.1 Issuer Scripts

The Issuer Script shall be passed to the terminal if it is transmitted to the
acquirer in the response message. In this version of the Visa Integrated
Circuit Card Specification, at most only one Issuer Script is transmitted in the
response message. In a subsequent version, multiple Issuer Scripts may be
allowed in a response message.
An Issuer Script transmitted in the response message should always have
tag “72”, indicating that Issuer-to-Card Script Processing is to be performed
after the final GENERATE AC command.
If the online response message contains an Issuer Script, the terminal shall
set the Issuer Script processing was Performed bit to “1” in the Transaction
Status Information (TSI).
14.5.2 Multiple Commands

The Issuer Script may contain multiple commands. The terminal shall parse
out each Issuer Script command contained in the Issuer Script and transmit
the commands to the card one by one. For each command, the terminal shall
increment the sequence number in Issuer Script Results.
14–4
14.5.3 Script Errors

If the SW1 return code is not equal to “90” in the card’s response to the Issuer
Script command indicating that processing of the command failed, the
terminal shall:
● Terminate processing of that Issuer Script.
● Set the Issuer Script Processing Failed After Final GENERATE AC bit
to “1” in the Terminal Verification Results (TVR).
● Set Issuer Script Result Byte 1, bit 5, to 1.
● Proceed to the next Issuer Script, if present.
14.5.4 Multiple Scripts

The terminal should not receive multiple Issuer Scripts. If multiple scripts are
received, the terminal shall process the scripts as described in the EMV 4.0,
Book 4, Section 2.3.9.
14.5.5 Issuer Script with Tag “71”

The terminal should not receive an Issuer Script with tag “71” indicating that
Issuer Script processing is to be performed prior to the final GENERATE AC
command. If an Issuer Script with tag “71” is received, the terminal shall
process the script as described in the EMV 4.0, Book 4, Section 2.3.9.
14.5.6 Terminal Messages

The terminal shall not display a message indicating that the transaction has
been approved or declined until after the completion of Issuer Script
processing to ensure that the card is not removed from the terminal during
Issuer Script processing.
14.5.7 Issuer Notification

If Issuer Script processing was performed for the transaction, the terminal
should ensure that a message such as a clearing, next online authorization, or
advice message is transmitted that contains the results of Issuer Script
processing. The message may be transmitted for reasons other than Issuer
Script processing or may be transmitted solely for the purpose of conveying
the Issuer Script Results.
14.5.8 Process Flow

Issuer-to-Card Script Processing might be performed as shown in
Figure 14–1.
31 Oct 2001
Figure 14–1: Issuer-to-Card Script Processing
Card Terminal
Terminal completes
Online Processing
and Completion
Issuer Script N
present in online
response?
Terminal parses out

Issuer Script
command in
sequential order
Terminal increments Y
script command Y
sequence number
Card executes script Terminal sends

Script Command command to card
command N
Terminal receives
Script Command
command response
Response
from card
Another
SW1 W2 = 9000 Y command
present?
Terminal sets Script N

Processing Failed
after final GEN AC in
TVR
Another script
present?
Terminal sets Issuer

Script Processing
Performed in TSI
Terminal completes
transaction
processing
14–6

Online Processing
The terminal may receive an Issuer Script in the authorization response
message.
Completion
The Completion function will transfer to Issuer-to-Card Script Processing if
an Issuer Script was present in the online response.
31 Oct 2001
Terminal and Acquirer Data Elements A
This appendix defines those data elements that may be used for financial
transaction interchange and their mapping onto data objects. This includes all
terminal or acquirer data objects listed in the EMV 2000 Integrated Circuit
Card Specification for Payment Systems, Version 4.0, and the Visa proprietary
data elements. Also included is a list of terminal data element tags.
Card data and issuer data elements are listed in the Visa Integrated Circuit
Card, Card Specification.
NOTE: Although Visa does not support certain terminal-related data objects
listed in the EMV 2000 Integrated Circuit Card Specification for
Payment Systems, Version 4.0, in this version of the Visa Integrated
Circuit Card Specification (VIS), other payment systems may choose to
support these data objects. Therefore, the terminal shall support all
terminal-related data objects listed in those specifications.
A.1 Terminal and Acquirer Data Elements Table

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 zeros
●
A data element in format cn is left-justified and padded with trailing
hexadecimal Fs
● A data element in format an is left-justified and padded with trailing
hexadecimal zeros
●
A data element in format ans is left-justified and padded with trailing
hexadecimal zeros
31 Oct 2001
Draft 12/18/00 Visa Public A–1
Terminal and Acquirer Data Elements Visa Integrated Circuit Card
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 rules applies when
concatenating data.
Table A–1: Terminal and Acquirer Data Elements (1 of 20)
Name (Format;
Tag; Length) Requirement Description Values
Acquirer O Uniquely identifies the

Identifier acquirer within each
payment system.
F: n 6-11 For Visa, this is the BASE
T: 9F01 Identification Number
L: 6 (BIN).
Additional M Indicates the data input ● Byte 1 (Transaction Type Capability):

Terminal and output capabilities of
bit 8: 1 = Cash
Capabilities the terminal. bit 7: 1 = Goods
bit 6: 1 = Services
bit 5: 1 = Cashback
F: b 40 bit 4: 1 = Inquiry
T: 9F40 bit 3: 1 = Transfer
L: 5 bit 2: 1 = Payment
bit 1: 1 = Administrative
● Byte 2 (Transaction Type Capability,
cont.):
bits 8–1: Reserved for future use (RFU)
(“00”)·
● Byte 3 (Terminal Data Input Capability):
bit 8: 1 = Numeric keys
bit 7: 1 = Alphabetic and special
characters keys
bit 6: 1 = Command keys
bit 5: 1 = Function keys
bits 4–1: RFU (0000)
A–2
Visa Integrated Circuit Card A.1 Terminal and Acquirer Data Elements Table
Name (Format;
Additional ● Byte 4 (Terminal Data Output Capability):

Terminal
bit 8: 1 = Print, attendant
Capabilities bit 7: 1 = Print, cardholder
(continued) bit 6: 1 = Display, attendant
bit 5: 1 = Display, cardholder
bits 4–3: RFU (00)
bit 2: 1 = Code table 10
● Byte 5 (Terminal Data Output Capability,
cont.):
Amount, not applicable Authorized amount of the

Authorized transaction (excluding
adjustments).
(Binary)
This data object is not
used in this version of VIS.
F: b 32
T: 81
L: 4
Amount, M Authorized amount of the

Authorized transaction (excluding
adjustments).
(Numeric)
F: n 12
T: 9F02
L: 6
Amount, Other not applicable Secondary amount

associated with the
(Binary)
transaction representing a
cashback amount.
F: b 32
T: 9F04
L: 4
31 Oct 2001
Name (Format;
Amount, Other C Secondary amount

associated with the
(Numeric) If cashback
transaction representing a
supported
cashback amount.
F: n 12
T: 9F03
L: 6
Amount, not applicable Authorized amount

Reference expressed in the
Currency reference currency.
(Binary) This data object is not
F: b 32
T: 9F3A
L: 4
Amount, M Transaction amount

Transaction including tips and other
adjustments; the clearing
amount of the transaction.
F: n 12
T: –
L: 6
Application M Identifies the application The AID consists of two parts:

Identifier (AID) as described in
The Registered Application Provider
ISO/IEC 7816-5.
Identifier (RID), which identifies the
F: b 40-128 application provider (scheme); and the
T: 9F06 Proprietary Application Identifier Extension
L: 5–16 (PIX), which identifies the application within
the application provider.
A–4
Name (Format;
Application M Indicates whether the Format and content are at the discretion of
Selection associated AID in the the terminal vendor. For Visa applications,
Indicator terminal must match the must be set to allow partial selection.
AID in the card exactly
including the length of the
F: –
AID, or only up to the
T: –
length of the AID in the
L: –
terminal.
There is only one
Indicator per AID in the
terminal.
Application M Version number assigned The Application Version Number is the

Version Number by the payment system for version, release, and modification number in
the application. binary of VIS supported by the terminal. For
terminals supporting VIS 1.3.1, the value is
F: b 16
131, coded in binary. For terminals
T: 9F09
supporting VIS 1.3.2, the value is 132,
L: 2
coded in binary. For terminals supporting
VIS 1.4.0, the value is 140, coded in binary.
Authorization M Indicates the disposition Codes generated by the issuer are as

Response Code of the transaction received indicated in International Organisation for
from Issuer for online Standardisation (ISO) 8583:1987.
authorizations
F: an 2 The following codes are generated by the
T: 8A terminal for the following exception
L: 2 conditions:
Y1 = Offline approved
Z1 = Offline declined
Y2 = Approved (after card-initiated referral)
(not supported in this version of VIS)
Z2 = Declined (after card-initiated referral)
(not supported in this version of VIS)
Y3 = Unable to go online (offline approved)
Z3 = Unable to go online (offline declined)
31 Oct 2001
Name (Format;
Cardholder M Indicates the results of the ● Byte 1 (CVM Performed):

Verification last CVM performed.
Last CVM of the CVM List actually
Method (CVM) performed by the terminal. Coded as a
Results 1-byte CVM Code (as defined in the CVM
List) (“3F” if no CVM is performed).
F: b 24 ● Byte 2 (CVM Condition):
T: 9F34
Coded as a 1-byte CVM Condition Code
L: 3
(as defined in the CVM List)·
● Byte 3 (CVM Result):
Result of the (last) CVM performed as
know by the terminal:
00 = Unknown (for example, for

signature)
01 = Failed (for example, for offline PIN)
02 = Successful (for example, for offline
PIN)
Certificate C Payment system public Value generated by Visa and loaded to

Authority Public key used for offline static terminal by acquirer. Up to six Visa public
If SDA, DDA,
Key or dynamic data keys must be supported.
or Offline
authentication.
Enciphered
F: b PIN supported
T: –
L: –
Certificate C A check value calculated

Authority Public on the concatenation of all
If SDA, DDA,
Key Check Sum parts of the Certificate
or Offline
Authority Public Key (RID,
Enciphered
Certificate Authority Public
F: b PIN supported
Key Index, Certificate
T: –
Authority Public Key
L: 20
Modulus, Certificate
Authority Public Key
Exponent) using SHA-1.
A–6
Name (Format;
Certificate C Value of the exponent part

Authority Public of the Certificate Authority
If SDA, DDA,
Key Exponent Public Key.
or Offline
Enciphered
F: b PIN supported
T: –
L: 1 or 3
Certificate C Identifies the Certificate Values assigned by Visa.

Authority Public Authority’s public key in
If SDA, DDA,
Key Index (PKI) conjunction with the RID
or Offline
for use in offline static
Enciphered
data authentication.
F: b 8 PIN supported
T: 9F22
L: 1
Certificate C Value of the modulus part

Authority Public of the Certificate Authority
If SDA, DDA,
Key Modulus Public Key.
or Offline
Enciphered
F: b PIN supported
T: –
L: NCA (up to 248)
Command M Identifies the data field of

Template a command message.
F: b
T: 83
L: var.
Default Dynamic C DDOL to be used for Must contain tag for Unpredictable Number
Data constructing the (“9F37”) only.
If DDA is
Authentication INTERNAL
supported
Data Object List AUTHENTICATE
(DDOL) command if the DDOL in
the card is not present.
F: b
T: –
L: var.
31 Oct 2001
Name (Format;
Default O TDOL to be used to

Transaction generate the TC Hash
Certificate Data Value if the TDOL in the
Object List card is not present.
(TDOL)
Not currently used in any
VSDC cryptograms
F: b defined by Visa.
T: –
L: var.
Enciphered C Transaction PIN

Personal enciphered at the PIN pad
If online PIN
Identification for online verification or for
supported or if
Number (PIN) offline verification if the
PIN pad and
Data PIN pad and the interface
card reader
device (IFD) are not a
separate
single integrated device.
F: b 64
T: –
L: 8
Interface Device M Unique and permanent Value assigned by IFD manufacturer.

(IFD) Serial serial number assigned to
Number the IFD by the
manufacturer.
F: an 8
T: 9F1E
L: 8
A–8
Name (Format;
Issuer Script M Indicates the results of ● Byte 1(Issuer Script Result):

Results Issuer Script processing.
bits 8–5: Result of the Issuer Script
Note: When the terminal processing performed by the
F: b transmits this data terminal:
T: 9F5B element to the acquirer, in 0 = Issuer Script not performed
L: var. this version of VIS, it is 1 = Issuer Script processing failed
acceptable that only byte 2 = Issuer Script processing successful
1 is transmitted, although
it is preferable for all 5 bits 4–1: Sequence number of the Issuer
Script Command:
bytes to be transmitted.
0 = Not specified
1-E = Sequence number 1–14
F = Sequence number 15 or above
● Bytes 2–5 (Issuer Script Identifier):
Issuer Script Identifier received by the
terminal, if available; zero filled if not
available. Mandatory if more than one
Issuer Script was received by the
terminal.
Bytes 1–5 are repeated for each Issuer

Script processed by the terminal, although in
this version of VIS, only one Issuer Script
may be transmitted in the response
message.
Maximum Target C Value used in terminal risk

Percentage to be management for random
If offline
Used for Biased transaction selection.
capable
Random
terminal
Selection
F: –
T: –
L: –
Merchant M Classifies the type of

Category Code business being done by
the merchant, represented
according to ISO
F: n 4
8583:1993 for Card
T: 9F15
Acceptor Business Code.
L: 2
31 Oct 2001
Name (Format;
Merchant M When concatenated with

Identifier the Acquirer Identifier,
(at terminal or
uniquely identifies a given
acquirer)
merchant within a given
F: ans 15
country. May be located in
T: 9F16
the terminal or inserted
L: 15
into messages by the
acquirer.
Merchant Name M Indicates the name and

and Location location of the merchant.
(at terminal or
May be located in the
acquirer)
terminal or inserted into
F: ans
messages by the acquirer.
T: –
L: var.
Message Type C Indicates whether the

batch data capture record
If advices
is a financial record or
F: n 2 supported
advice.the terminal or
T: –
inserted into messages by
L: 1
the acquirer.
Personal C Secret key of a symmetric

Identification algorithm used by the PIN
If PIN pad and
Number (PIN) pad to encipher the PIN
card reader
Pad Secret Key and by the card reader to
not integrated
decipher the PIN if the
PIN pad and card reader
F: –
are not integrated.
T: –
L: – Note: This is not the key
used for Offline
Enciphered PIN.
A–10
Name (Format;
Point of Service M Indicates the method by Codes are as indicated in ISO 8583:1987
(POS) Entry which the PAN was with the following additions. If the magnetic
Mode Code entered, according to the stripe is read instead of the ICC, the terminal
first two digits of ISO may indicate this by generating the following
8583:1987. codes for transmission to the acquirer.
F: n 2
T: 9F39 90 = Magnetic stripe read; service code
L: 1 does not begin with “2”or “6”
91 = Magnetic stripe read; service code
begins with “2”or “6”; last transaction
was a successful IC read or was not an
IC transaction
92 = Magnetic stripe read; service code
begins with “2”or “6”; last transaction
was an unsuccessful IC read
Note: The new codes 91 and 92 are not
transmitted in the POS Entry Mode Code
from the acquirer to Visa.
Point of Service M See Terminal Entry

(POS) Terminal Capability.
(terminal or
Capability
acquirer)
Proprietary M As part of the Application The currently assigned Visa PIXs used for
Application Identifier (AID), identifies VSDC are:
Identifier the application within the
1010—Visa
Extension (PIX) application provider
(scheme). 2010—Electron
F: b 3010—Interlink
T: part of AID 999910—Proprietary ATM
L: 0–11
Registered M As part of the Application Visa’s RID is A000000003.

Application Identifier (AID), a
Provider uniquely-assigned
Identifier (RID) number that identifies the
application provider
(scheme).
F: b
T: part of AID
L: 5
31 Oct 2001
Name (Format;
Status of Last C V.I.P./BASE II data Values are:

Chip Attempt element indicating for a
Mag stripe 0 = Service code does not begin with “2”or
magnetic stripe initiated
initiated from a “6”
transaction whether the
F: n 1 IC reading
previous transaction at the 1 = Service code begins with “2”or “6”; last
T: – terminal
terminal was a successful transaction was a successful IC read or
L: –
IC read. was not an IC transaction
2 = Service code begins with “2”or “6”; last
transaction was an unsuccessful IC read
Target C Value used in terminal risk Visa may establish a range of values.
Percentage to be management for random
If online/offline
Used for transaction selection.
terminal
Random
Selection
F: –
T: –
L: –
Terminal Action C Specifies payment Bit assignments are identical to those for
Code—Default scheme conditions that Terminal Verification Results (TVR). The
If offline
cause a transaction to be permissible values for the TAC—Default in
capable
declined if it might have this version of VIS is are shown in
F: b 40 terminal
been approved online, but Chapter 10, Table 10–3.
T: –
the terminal is unable to
L: 5
process the transaction
online.
Code—Denial scheme conditions that Terminal Verification Results (TVR). The
If offline
cause the decline of a permissible values for the TAC—Denial in
capable
transaction without this version of VIS is are shown in
F: b 40 terminal
attempting to go online. Chapter 10, Table 10–3.
T: –
L: 5
Code–Online scheme conditions that Terminal Verification Results (TVR). The
If online/offline
cause a transaction to be permissible values for the TAC—Online in
terminal
transmitted online. this version of VIS is are shown in
F: b 40
Chapter 10, Table 10–3.
T: –
L: 5
A–12
Name (Format;
Terminal M Indicates the card data ● Byte 1 (Card Data Input Capability):
Capabilities input, CVM, and security
bit 8: 1 = Manual key entry
capabilities of the bit 7: 1 = Magnetic stripe
terminal. bit 6: 1 = IC with contacts
F: b 24
bits 5–1: RFU (00000)
T: 9F33
L: 3 ● Byte 2 (CVM Capability):
bit 8: 1 = Plaintext PIN for offline
CC verification
bit 7: 1 = Enciphered PIN for online
verification
bit 6: 1 = Signature (paper)
bit 5: 1 = Enciphered PIN for offline
verification
bits 4–1: RFU (00000)
● Byte 3 (Security Capability):
bit 8: 1 = Offline static data
authentication
bit 7: 1 = Offline dynamic data
authentication
bit 6: 1 = Card capture
bit 5: 1 = Combined dynamic data
authentication/application
cryptogram generation
bits 4–1: RFU (00000)
Terminal Country M Indicates the country of

Code the terminal represented
according to ISO 3166.
F: n 3
T: 9F1A
L: 2
Terminal Entry M V.I.P./BASE II data The ICC-related value is:

Capability element indicating
(terminal or 5 = ICC reading supported by terminal
whether the terminal
acquirer)
supports reading of the
F: n 1
IC, magnetic stripe, etc.
T: –
L: –
31 Oct 2001
Name (Format;
Terminal Floor C Indicates the floor limit in

Limit the terminal in conjunction
If offline
with the AID.
capable
F: b 32 terminal
T: 9F1B
L: 4
Terminal M Designates the unique

Identification location of a terminal at a
(at terminal or
merchant.
acquirer)
F: an 8
T: 9F1C
L: 8
Terminal Risk O Application-specific value

Management used by the card for risk
Data management purposes.
F: b 8–64
T: 9F1D
L: 1–8
A–14
Name (Format;
Terminal Type M Indicates the environment Values are:

of the terminal, its
11 = Attended, online only, operated by
communications financial institution
F: n 2
capability, and its 12 = Attended, offline with online capability,
T: 9F35
operational control. operated by financial institution
L: 1 13 = Attended, offline only, operated by
financial institution
14 = Unattended, online only, operated by
15 = Unattended, offline with online
capability, operated by financial
institution
16 = Unattended, offline only, operated by
21 = Attended, online only, operated by
merchant
22 = Attended, offline with online capability,
operated by merchant
23 = Attended, offline only, operated by
merchant
merchant
capability, operated by merchant
merchant
cardholder
capability, operated by cardholder
cardholder
31 Oct 2001
Name (Format;
Terminal M Status of the different ● Byte 1

Verification functions as seen from the
bit 8: 1 = Offline data authentication
Results (TVR) terminal. was not performed
Note: The issuer needs to bit 7: 1 = Offline static data
authentication failed
F: b 40 set the “Issuer Script bit 6: 1 = ICC data missing
T: 95 processing failed after bit 5: 1 = Card appears on terminal
L: 5 final GENERATE AC” bit exception file
to “0” prior to validating bit 4: 1 = Offline dynamic data
the TC. authentication failed
bit 3: 1 = Combined DDA/AC
Generation failed
bits 21: RFU (000)
● Byte 2
bit 8: 1 = ICC and terminal have
different application
versions
bit 7: 1 = Expired application
bit 6: 1 = Application not yet
effective
bit 5: 1 = Requested service not
allowed for card product
bit 4: 1 = New card
bits 3–1: RFU (000)
● Byte 3
bit 8: 1 = Cardholder verification was
not successful
bit 7: 1 = Unrecognized CVM
bit 6: 1 = PIN Try Limit exceeded
bit 5: 1 = PIN entry required and PIN
pad not present or not
working
bit 4: 1 = PIN entry required, PIN
pad present, but PIN was
not entered
bit 3: 1 = Online PIN entered
bits 2–1: RFU (00)
A–16
Name (Format;
Terminal ● Byte 4
Verification
bit 8: 1 = Transaction exceeds floor
Results (TVR) limit
(continued) bit 7: 1 = Lower consecutive offline
limit (“9F14”) exceeded
bit 6: 1 = Upper consecutive offline
limit (“9F23”) exceeded
bit 5: 1 = Transaction selected
randomly for online
processing
bit 4: 1 = Merchant forced
transaction online
bits 3–1: RFU (000)
● Byte 5
bit 8: 1 = Default TDOL used
bit 7: 1 = Issuer authentication was
unsuccessful
bit 6: 1 = Issuer Script processing
failed before final
GENERATE AC command
failed after final
GENERATE AC command
Note: bits 4–1: RFU (0000)
Threshold Value C Value used in terminal risk Visa may establish a range of values.
for Biased management for random
If online and
Random transaction selection.
offline terminal
Selection
F: –
T: –
L: –
Transaction R Clearing amount of the

Amount transaction, including tips
and other adjustments.
F: n12
T: –
L: – 6
31 Oct 2001
Name (Format;
Transaction O Result of a hash function

Certificate (TC) specified in the EMV 2000
Hash Value Integrated Circuit Card
Specification for Payment
Systems, Version 4.0,
F: b 160
T: 98
L: 20
Transaction M Indicates the currency

Currency Code code of the transaction
The implied exponent is
F: n 3
indicated by the minor unit
T: 5F2A
of currency associated
L: 2
with the Transaction
Currency Code in ISO
4217.
Transaction M Indicates the implied

Currency position of the decimal
Exponent point from the right of the
transaction amount
represented according to
F: n 1
ISO 4217.
T: 5F36
L: 1
Transaction Date M Local date that the

transaction was
authorized.
F: n 6 YYMMDD
T: 9A
L: 3
Transaction C Data entered by the

Personal cardholder for the purpose
If PIN
Identification of PIN verification.
supported
Number (PIN)
Data
F: b
T: 99
L: var.
A–18
Name (Format;
Transaction not applicable Code defining the

Reference common currency used by
Currency Code the terminal in case the
Transaction Currency
Code is different from the
F: n 3
Application Currency
T: 9F3C
Code.
L: 2
Transaction not applicable Factor used in the

Reference conversion from the
Currency Transaction Currency
Conversion Code to the Transaction
Reference Currency
Code.
F: n 8
T: – This data object is not
L: 4 used in this version of VIS.
Transaction not applicable Indicates the implied

Reference position of the decimal
Currency point from the right of the
Exponent Transaction Amount, with
the reference currency
code represented
F: n 1
T: 9F3D
L: 1 This data object is not
Transaction M Counter maintained by the

Sequence terminal that is
Counter incremented by one for
each transaction.
F: n 4-8
T: 9F41
L: 2–4
31 Oct 2001
Name (Format;
Transaction M Indicates the functions ● Byte 1:

Status performed in a terminal.
bit 8: 1 = Offline data authentication
Information (TSI) was performed
bit 7: 1 = Cardholder verification
was performed
F: b 16 bit 6: 1 = Card risk management
T: 9B was performed
L: 2 bit 5: 1 = Issuer authentication was
performed
bit 4: 1 = Terminal risk management
was performed
was performed
bits 2–1: RFU (00)
● Byte 2: 1
● RFU (“00”)
Transaction Time M Local time that the

transaction was
authorized.
F: n 6 HHMMSS
T: 9F21
L: 3
Transaction Type M Indicates the type of

financial transaction,
represented by the first
F: n 2
two digits of ISO
T: 9C
8583-1987 Processing
L: 1
Code.
Unpredictable M Value to provide variability

Number and uniqueness to the
generation of the
application cryptogram.
F: b 32
T: 9F37
L: 4
A–20
Name (Format;
VLP Terminal C A data element, which if 0 = VLP Not Supported

Support present in the terminal,
If VLP 1 = VLP Supported
Indicator indicates that the terminal
supported
supports VLP processing. 2 = Contactless – VLP Only
F: n 1
T: 9F7A
L: 1
VLP Terminal O If this data element is

Transaction Limit present it is used by the
terminal to determine
whether a transaction can
F: n 12
be processed as VLP.
T: 9F7B
L: 6 If it is not present, the
Terminal Floor Limit is
used. The transaction
amount must be below
either the VLP Terminal
Transaction Limit or the
Terminal Floor Limit.
31 Oct 2001
A.2 Terminal Data Element Tags

The tags allocated to the terminal data elements are shown in Table A–2.
Table A–2: Terminal Data Element Tags (1 of 2)
Tag Terminal Data Element Name
5F2A Transaction Currency Code
5F36 Transaction Currency Exponent
81 Amount, Authorized (binary)
83 Command Template
8A Authorization Response Code
95 Terminal Verification Results
98 Transaction Certificate (TC) Hash Value
99 Transaction PIN
9A Transaction Date
9B Transaction Status Information (TSI)
9C Transaction Type
9F01 Acquirer Identifier
9F02 Amount, Authorized (Numeric)
9F03 Amount, Other (Numeric)
9F04 Amount, Other (Binary)
9F06 Application Identifier (AID)
9F09 Application Version Number
9F15 Merchant Category Code
9F16 Merchant Identifier
A–22
Visa Integrated Circuit Card A.2 Terminal Data Element Tags
Table A–2: Terminal Data Element Tags (2 of 2)
Tag Terminal Data Element Name
9F1A Terminal Country Code
9F1B Terminal Floor Limit
9F1C Terminal Identification
9F1D Terminal Risk Management Data
9F1E Interface Device (IFD) Serial Number
9F21 Transaction Time
9F22 Certificate Authority Public Key Index (PKI)
9F33 Terminal Capabilities
9F34 Cardholder Verification Method (CVM) Results
9F35 Terminal Type
9F37 Unpredictable Number
9F39 Point of Service (POS) Entry Mode Code
9F3A Amount, Reference Currency (Binary)
9F3C Transaction Reference Currency Code
9F3D Transaction Reference Currency Exponent
9F40 Additional Terminal Capabilities
9F41 Transaction Sequence Counter
9F7AVLP Terminal Support Indicator
9F7B VLP Terminal Transaction Limit
31 Oct 2001
Commands for Financial Transactions B
This appendix lists the commands described in the functional chapters of this
document and in the EMV 2000 Integrated Circuit Card Specification for
Payment Systems, Version 4.0 (EMV 4.0), Book 2, Section 2.5. These
commands support transaction processing. Issuer Script Commands are not
included.
●
EXTERNAL AUTHENTICATE
● GENERATE APPLICATION CRYPTOGRAM
● GET CHALLENGE
●
GET DATA
●
GET PROCESSING OPTIONS
●
INTERNAL AUTHENTICATE
●
READ RECORD
● SELECT
●
VERIFY
These commands may be used for other purposes, such as for personalization
of cards. With the exception of the GET DATA command, this section does not
address requirements for the support of these commands for such purposes.
Issuer Script commands are generated by the issuer and included in the
authorization response message as part of issuer script. Because the
terminal’s only function is to parse the script and pass the commands to the
card, they are not described in this appendix. The Visa Integrated Circuit
Card, Appendix C, Commands for Financial Transactions, contains
information about these commands.
31 Oct 2001
Draft 12/18/00 Visa Public B–1
Commands for Financial Transactions Visa Integrated Circuit Card
All commands are issued by the terminal to the card. After processing the
command, the card returns a command response to the terminal. The
command formats are described in the EMV 4.0, Book 3, Section 2. Each
command includes class and instruction bytes that designate the type of
command. Parameter bytes (P1 and P2) provide additional processing
information. The command may include a data field.
The command response includes two status bytes (SW1 and SW2) that
describe the command results. SW1 SW2 equals “9000” when the command
process was completed successfully. Other values for SW1 SW2 are listed with
the individual commands. The command response may optionally include a
data field. The data fields returned from VSDC cards are coded according to
Format 1 as described in the EMV 4.0, Book 3, Section 2.5.
B.1 Basic Processing Rules for Issuer Script Commands

The recommended Issuer Script commands are used to perform the functions
described in Chapter 14, Issuer-to-Card Script Processing. These commands
are sent by the issuer in the authorization response message and passed to
the card by the terminal. Issuer Scripts for some functions such as Application
Unblock and PIN Change/Unblock may be sent in non-financial transactions
from special issuer-controlled devices.
NOTE: In the EMV 2000 Integrated Circuit Card Specification for Payment
Systems, Version 4.0, Le (the expected length of the response data field)
is not shown as being present in an Issuer Script Command because
only the status bytes are required in the response message. However,
the EMV 4.0 does not prohibit data from being transmitted in the
script command response message.
B.2 EXTERNAL AUTHENTICATE Command—Response APDUs

The EXTERNAL AUTHENTICATE command shall be performed as described
in the EMV 4.0, Book 3, Section 2.5.4. This command is used in performing
online Issuer Authentication.
The terminal transmits to the card a data object called the Issuer
Authentication Data in the EXTERNAL AUTHENTICATE command. The
Issuer Authentication Data was received from the issuer in the authorization
response.
The terminal shall issue at most one EXTERNAL AUTHENTICATE
command during a transaction.
B–2
Visa Integrated Circuit Card B.3 GENERATE APPLICATION CRYPTOGRAM (AC) Command
Terminal Specification, Version 1.4.0 Response APDUs
B.3 GENERATE APPLICATION CRYPTOGRAM (AC) Command

Response APDUs
The GENERATE APPLICATION CRYPTOGRAM (AC) command shall be
performed as described in the EMV 4.0, Book 3, Section 2.5.5. This command
is used in generating the Authorization Request Cryptogram (ARQC),
Transaction Certificate (TC), Application Authentication Cryptogram (AAC),
and Application Authorization Referral (AAR). In this version of the Visa
Integrated Circuit Card Specification, the card never initiates a referral, so an
AAR is never generated.
P1 of the GENERATE AC command may be used by the terminal to indicate
that Combined DDA/AC Generation is to be performed and the type of
cryptogram being requested.
If SW1 SW2 returned from the GENERATE APPLICATION CRYPTOGRAM
(AC) is not “9000”, the terminal shall terminate the transaction.
The data field returned in the response to the GENERATE AC command from
cards that do not support Combined DDA/AC Generation is coded according to
Format 1 as described in the EMV 4.0, Book 3, Section 2.5.5.4. This allows a
card to transmit to the terminal a variable-length data object called the Issuer
Application Data, which contains proprietary card data for online
transmission.
The data field returned in the response to the GENERATE AC command from
cards that do support Combined DDA/AC Generation is coded according to
Format 2, using BER-TLV encoding, as described in the EMV 4.0, Book 3,
Section 2.5.5.4. If the response is returned in an envelope, the data returned
by the card shall be formatted as shown in the EMV 4.0, Book 2, Table 16.
In this version of the Visa Integrated Circuit Card Specification, the Issuer
Application Data is a mandatory data object used to transmit Visa
discretionary data from the card to the terminal for input to the online request
message or clearing record. Issuer Application Data is described in
Chapter 12, Online Processing, and the Visa Integrated Circuit Card
Specification, Appendix A, Terminal and Acquirer Data Elements.
B.4 GET CHALLENGE Command—Response APDUs

The GET CHALLENGE command is optional in the card. The terminal shall
support it if the terminal supports Offline Enciphered PIN. The GET
CHALLENGE command shall be performed as described in the EMV 4.0,
31 Oct 2001
B.5 GET DATA Command—Response APDUs

The GET DATA command shall be performed as described in the EMV 4.0,
Data retrievable by financial terminals using the GET DATA command is
shown in Table B–1. If the issuer stores this data on the card as Visa
proprietary data elements, it is not accessible using GET DATA.
Table B–1: Data Retrieval Using GET DATA
Data Element
Application Transaction Counter (ATC)
Last Online ATC Register
PIN Try Counter (may be stored as a proprietary data element to prevent retrieval by
GET DATA)
If the data element requested in the GET DATA command is not present in
the card or is a proprietary data element, the card returns SW1 SW2 not
equal to “9000”.
Retrieval of the card life cycle data and the tagged Visa proprietary data is
performed by special devices. Terminals are not required to support the GET
DATA command to retrieve the card life cycle data. Terminals shall not use
the GET DATA command to retrieve the tagged Visa proprietary data.
B–4
Visa Integrated Circuit Card B.6 GET PROCESSING OPTIONS Command—Response APDUs
B.6 GET PROCESSING OPTIONS Command—Response APDUs

The GET PROCESSING OPTIONS command shall be performed as described
The data portion of the command is the data specified in the PDOL provided
by the card during Application Selection in the SELECT response. Data
retrievable by the GET PROCESSING OPTIONS command is shown in
Table B–2.
Table B–2: Data Retrieval With GET PROCESSING OPTIONS
Data Element
Application Interchange Profile
Application File Locator
The data field returned in the response to the GET PROCESSING OPTIONS
command is coded according to Format 1 as described in the EMV 4.0, Book 3,
Section 2.5.8.4.
B.7 INTERNAL AUTHENTICATE Command—Response APDUs

The INTERNAL AUTHENTICATE command shall be performed as described
The data field returned in the response to the INTERNAL AUTHENTICATE
commands coded according to Format 1 as described in the EMV 4.0, Book 3,
Section 2.5.9.4.
B.8 READ RECORD Command—Response APDUs

EMV 4.0, Book 3, Section 2.5.11.
31 Oct 2001
B.9 SELECT Command—Response APDUs

The SELECT command shall be performed as described in the EMV 4.0,
Book 1, Section 7.3.
As described in Part II, the following data objects are returned in the response
to the SELECT command when the Payment System Environment (PSE)
Directory is selected:
● File Control Information (FCI) Template
● Dedicated File (DF) Name (1PAY.SYS.DDF01)
● FCI Proprietary Template
– Short File Identifier (SFI) of directory elementary file
– Language Preference (optional)
– Issuer Code Table Index (optional)
– FCI Issuer Discretionary Data (optional)
The Issuer Code Table Index is present if the Application Preferred Name is
present in an Application Definition File (ADF) directory entry (see Chapter 3,
Application Selection)
The following data objects are returned when a Directory Definition File
(DDF) is selected:
● FCI Template
● DF Name
– SFI of directory elementary file
B–6
Visa Integrated Circuit Card B.10 VERIFY Command—Response APDUs
The following data objects are returned in the response to the SELECT
command when an ADF is selected, unless otherwise noted:
● FCI Template
●
DF Name
– Application Label
– Application Priority Indicator (if present in card)
– Processing Options Data Object List (PDOL) (optional)
– Language Preference (optional)
– Issuer Code Table Index (optional)
– Application Preferred Name (optional)
Additional data objects may be returned. The terminal shall ignore these data
objects.
B.10 VERIFY Command—Response APDUs

The VERIFY command shall be performed as described in the EMV 4.0,
The terminal shall support the VERIFY command if the terminal supports
offline PIN verification.
31 Oct 2001
General Terminal Requirements C
This appendix lists the requirements for Visa Smart Debit and Visa Smart
Credit (VSDC) terminals, which are in addition to the requirements listed in
the functional chapters. The general requirements shall be implemented as
described in the EMV 2000 Integrated Circuit Card Specification for Payment
Systems, Version 4.0 (EMV 4.0), Book 4, Part I.
C.1 Terminal Types and Capabilities

The terminal types and capabilities data objects shall be implemented as
described in the EMV 4.0, Book 4, Part I.
This document refers to the online/offline capabilities of terminals using the
following terminology:
●
Offline-capable—A terminal with non-zero floor limits which is able to
approve transactions offline
●
Offline-only—A terminal with non-zero floor limits which is not capable
of going online to the issuer for an authorization. All transactions at these
terminals are approved or declined offline
● Online-capable—A terminal which is capable of going online to the
issuer for an authorization
● Online-only—A terminal with zero floor limits which is not capable of
approving transactions offline. An online only terminal may decline a
transaction offline.
In this version of the specification, an ATM is considered to be an online-only
terminal. Therefore, any requirement in the EMV 2000 Integrated Circuit
Card Specification for Payment Systems, Version 4.0, for an online-only
terminal applies to ATMs. The functional requirements shall be performed as
described in the EMV 4.0, Book 4, Part I.
31 Oct 2001
Draft 12/18/00 Visa Public C–1
General Terminal Requirements Visa Integrated Circuit Card
C.1.1 Advice Creation

When the card sends an indicator to the terminal in the response to a
GENERATE APPLICATION CRYPTOGRAM (AC) command requesting the
creation of an advice, the terminal needs to determine whether an advice is
the appropriate message to transmit the necessary data to the acquirer.
If the terminal is required to transmit a data capture record or a reversal
message for that transaction, it is not necessary for the terminal to also
transmit an advice. If the terminal is required to transmit an advice, the
terminal shall determine whether to transmit an offline or online advice based
upon its capabilities.
ATMs are not required to support transmission of an advice when requested
by the card. Certain markets may require that POS terminals support the
transmission of advices, while other markets may choose not to support
advices.
C.1.2 Amount Entry and Management

During the transaction, the amount of the transaction (not including
adjustments) and the amount of a cashback (if present) shall be made
available to the card and terminal for card and terminal risk management
and for authorization and clearing.
The following features are dependent upon the environment and are
independent of whether a chip or a magnetic stripe is used to initiate a
transaction.
● When an amount is entered through the use of a key pad at an attended
terminal, the attendant should be able to edit the amount during entry.
● The attendant should be able to either correct the amount entered prior to
authorization and proceed with the transaction or abort the transaction if
the amount was entered incorrectly.
●
The attendant or cardholder should be able to validate the original or
corrected amount.
NOTE: When transmitted to the card or the acquirer, the amount fields should
be formatted so that the implied currency exponent is the default value
as designated in International Organisation for Standardisation
(ISO) 4217.
C–2
Visa Integrated Circuit Card C.1 Terminal Types and Capabilities
C.1.3 Card Reading

When a card is read at a terminal, the card-related data for the transaction
should be obtained from the chip. This data is obtained from the magnetic
stripe only if the chip is not readable. If the magnetic stripe is not readable,
the cardholder data may be manually entered. (These default procedures for
reading the card may be prohibited within specific countries.) If the terminal
allows the magnetic stripe to be read if the chip is not readable, the terminal
shall support a means to bypass the “Use Chip Reader” prompt to allow
magnetic stripe reading.
The EMV 2000 Integrated Circuit Card Specification for Payment Systems,
Version 4.0, requires that the request message indicate if the magnetic stripe
was read because the chip was unreadable. For this version of the Visa
Integrated Circuit Card Specification, this shall be performed as follows:
● The terminal shall maintain an internal flag that is set whenever a chip
read failure occurs. This flag is reset at the completion of a transaction if
any of the following conditions occur:
– Successful chip read
– Successful magnetic stripe read
● If the flag is set and a magnetic stripe card is read successfully, and the
service code indicates that a chip is present, the terminal sets the
“Magnetic stripe read, ICC service code begins with ‘2’ or ‘6’, last
transaction was an unsuccessful chip read” code.
● If the flag is not set, a magnetic stripe card is read successfully, and the
service code indicates that a chip is present, the terminal sets the
“Magnetic stripe read, service code begins with ‘2’ or ‘6’, last transaction
was a successful chip read or was not a chip transaction” code.
● If the magnetic stripe is read and the service code indicates magnetic
stripe only, regardless of the internal flag setting, the terminal sets the
“Magnetic stripe read, service code does not begin with ‘2’ or ‘6’” code.
The terminal shall convey this information to the acquirer for conversion to
the VisaNet Chip Condition Code field.
POS Entry Mode may be used to convey this information from the terminal to
the acquirer as follows:
●
02 or 90—Magnetic stripe read, service code does not begin with “2” or “6”
code.
●
91—Magnetic stripe read, service code begins with “2” or “6”; last
transaction was a successful chip read or was not a chip transaction.
●
92—Magnetic stripe read; service code begins with “2” or “6”; last
transaction was an unsuccessful chip read.
31 Oct 2001
General Terminal Requirements Visa Integrated Circuit Card
The POS Entry Mode Codes of “91” and “92” are not valid in messages from
the acquirer to VisaNet and, if used from the terminal to the acquirer, shall be
converted, by the acquirer, to “02” or “90” as appropriate.
C.2 Physical Characteristics

The physical requirements shall be performed as described in the EMV 4.0,
Book 4, Part I.
The terminal shall support a magnetic stripe reader (either track 1 or 2 or
both) and manual entry capability. If manual entry of the PAN is supported,
the terminal shall support a PAN of up to 19 digits in length. (Support of
manual entry for PANs may be prohibited with specific countries or may not
be allowed for specific types of terminals, such as ATMs.)
The terminal shall support ICCs conforming to the EMV 2000 Integrated
Circuit Card Specification for Payment Systems, Version 4.0, and shall support
magnetic stripe cards conforming to ISO/IEC 7810, ISO/IEC 7811,
ISO/IEC 7812, and ISO/IEC 7813.
C.3 Security Requirements

The security requirements shall be performed as described in the EMV 4.0,
Book 4, Part I.
C.4 Data Management

To ensure the accuracy of the data elements Transaction Date (local date) and
Transaction Time (local time), the terminal shall ensure that it is able to
accurately calculate, store, and display date-dependent fields representing the
year 2000 and subsequent years without compromising the integrity of dates
or their use, including calculations for leap year. This requirement applies to
terminals supporting clocks as well as those that update the date and time
based upon online messages.
C–4
Visa Integrated Circuit Card C.5 Cardholder and Attendant Interface
C.5 Cardholder and Attendant Interface

The cardholder and attendant interface requirements shall be performed as
described in the EMV 4.0, Book 4, and in chapters 3 to 14 of this document.
C.5.1 Receipt
National requirements for data printed on the receipt will be developed for
each country, although each country shall comply with the Visa International
Operating Regulations. The receipt shall comply with the requirements in the
EMV 4.0, Book 4.
C.6 Acquirer Interface

The acquirer interface requirements shall be performed as described in the
EMV 4.0, Book 4, with the restrictions for this version of the Visa Integrated
Circuit Card Specification described in Chapters 3 to 14 of this document and
as described in the Visa Smart Debit/Visa Smart Credit System Technical
Manual.
31 Oct 2001
Terminal Requirements for Visa
Low-Value Payment Feature D
The Visa Low-value Payment (VLP) feature of VSDC provides Members with
an optional source of pre-authorized spending power that is reserved for rapid
processing of offline low-value payments.
Risk management features may differ from those supported for non-VLP
VSDC and are selected by the issuer. VLP supports a total amount limit (VLP
Funds Limit) and a per transaction amount limit (VLP Single Transaction
Limit). Since VLP consists of many low-value transactions, adding these
transactions to standard VSDC velocity checking counters could cause VSDC
transactions to be processed online more frequently than intended by issuers.
Therefore, standard VSDC velocity checking counters are not incremented by
VLP transactions.
VLP transactions are either approved or declined offline by the card and
terminal. They are never sent online for authorization. Any request requiring
online authorization is processed subject to VSDC requirements and
Visa/Visa Electron program rules.
The amount of spending power (VLP Available Funds) on the card is reset to
the spending limit (VLP Funds Limit) at any online capable VSDC terminal if
an online authorization or an online status check message (single unit of
currency) is approved by the issuer and the card. A reset without a financial
transaction can also take place at a dedicated online unattended device,
identified by Merchant Category Code “5999”, which performs an online
status check. If the response to the status check is an approval by the issuer
and the card, the amount of VLP spending power is reset to the VLP spending
limit.
The general requirements shall be implemented as described in the EMV
(EMV 4.0), Book 4, Part I.
31 Oct 2001
Draft 12/18/00 Visa Public D–1
Terminal Requirements for Visa Low-Value Payment Feature Visa Integrated Circuit Card
D.1 Card Data

Card data elements are described in Table D–1.
Table D–1: Initiate Application Processing—Card Data (1 of 2)
Application Currency Visa proprietary data element indicating the currency in

Code “9F51” which the account is managed according to International
Organisation for Standardisation (ISO) 4217.
Application File Locator Indicates the location (SFI, range of records) of the AEFs
(AFL) for VLP related to a given application.
Application Interchange The AIP indicates the capabilities of the card to support
Profile (AIP) for VLP specific functions in the application. These may differ for
VLP.
CVM List for VLP Identifies a prioritized list of methods of verification of the
cardholder supported by the card application for VLP
transactions.
Issuer Action Codes (IACs) The IACs specify the Issuer’s conditions for VLP
for VLP transactions for offline decline or online processing or
offline decline if online processing requested and the
terminal is unable to go online.
Issuer Application Data Contains proprietary application data for transmission to

the issuer in an online transaction. The first 16 bytes
contain Visa Discretionary Data. The remaining 16 bytes
contain Issuer Discretionary Data.
PDOL List of terminal-related data objects (tags and lengths)

requested by the card to be transmitted in the GET
PROCESSING OPTIONS command.
VLP Available Funds A counter that is decremented by the transaction amount

when a VLP transaction is approved (VLP transactions are
either approved or declined offline).
VLP Funds Limit Issuer Limit for VLP available funds that may be used by
the card to reset VLP Available Funds after an online
approved transaction.
D–2
Visa Integrated Circuit Card D.2 Terminal Data
Table D–1: Initiate Application Processing—Card Data (2 of 2)
VLP Issuer Authorization Code on the card that indicates that the transaction is
Code approved for VLP. It is placed in the Authorization Code in
the clearing message if the transaction is approved (VLP
transactions are either approved or declined offline).
VLP Single Transaction Maximum amount allowed for a single VLP transaction.
Limit
D.2 Terminal Data

Terminal data elements are described in Table D–2.
Table D–2: Initiate Application Processing—Terminal Data
Amount, Authorized Authorized amount of the transaction (excluding

adjustments)
Terminal Action Codes Payment scheme conditions that cause VLP transactions
(TACs) for VLP to be approved or declined offline.
Transaction Currency Code Indicates the currency code of the transaction according to
ISO 4217.
VLP Terminal Support A data element, which if present in the terminal, indicates
Indicator that the terminal supports VLP processing.
VLP Terminal Transaction The terminal uses this data element, if present, to
Limit determine whether a transaction can be processed as VLP.
If it is not present, the Terminal Floor Limit is used. The
transaction amount must be below either the VLP Terminal
Transaction Limit or the Terminal Floor Limit.
31 Oct 2001
D.3 Terminal Requirements

The terminal must meet the following requirements:
●
The terminal is EMV compliant
● The terminal contains Visa AID or Visa Electron AID, or both
● The terminal contains enhancements to the VSDC application to support
VLP
●
New terminal data elements include the VLP Terminal Support Indicator
● The terminal may optionally support display of VLP Available Funds or
printing of VLP Available Funds on the receipt
D.4 VLP Purchase Transaction Process
D.4.1 VLP Transaction With VLP-Capable Card at a VLP-Capable

Terminal
The terminal selects the VSDC application using the Visa or the Visa Electron
AID and the card response contains a PDOL, in the FCI, requesting the “VLP
Terminal Support Indicator”, “Amount, Authorized”, and “Transaction
Currency Code.”
The terminal provides the VLP Terminal Support Indicator in the GET
PROCESSING OPTIONS command if:
● VLP Terminal Support Indicator is present in the terminal.
● The transaction is under the terminal VLP Terminal Transaction Limit or
under the Terminal Floor Limit if no separate VLP Terminal Transaction
Limit is present.
● The Transaction Type is purchase (does not indicate cash or cashback).
●
A random selection process prior to Get Processing Options is not
supported or is supported and transaction is not eligible for VLP because
it was randomly selected.
If all card conditions for a VLP transaction are met, the terminal receives an
AFL that includes a file and record containing the VLP Issuer Authorization
Code and VLP Available Funds (after transaction amount is deducted).
VLP transactions are offline only; no Issuer Script processing takes place.
D–4
Visa Integrated Circuit Card D.4 VLP Purchase Transaction Process
If any card or terminal conditions are not met, the transaction is processed as
a standard VSDC transaction.
NOTE: If terminal requirements for VLP are not met, the terminal does not
provide the VLP Terminal Support Indicator to the card in GPO. If
card requirements are not met, the card provides VSDC AIP and AFL
(does not include VLP Issuer Authorization Code) rather than VLP.
AIP and AFL and standard VSDC processing takes place.
31 Oct 2001
A second set of TACs unique for VLP means that processing results differ
from those for standard VSDC. The required TACs for VLP are listed in
Table D–3.
Table D–3: Terminal TACs for VLP (1 of 2)
Card or Terminal Conditions Default Online Denial
Offline Data Authentication not performed 0 0 0
SDA Failure 1 0 1
Chip Data Missing 1 0 1
PAN on terminal exception file 1 0 1
Standard DDA failure 1 0 1
Combined DDA/AC Generation Failure 1 0 1
Chip and terminal are different versions 0 0 0
Expired Application 1 0 1
Application not yet active 1 0 1
Service not allowed for card product 1 0 1
New Card 0 0 0
Cardholder verification failed 1 0 1
CVM not recognized 0 0 0
PIN try limit exceeded 1 0 1
Offline PIN required and pin pad not working 1 0 1
Offline PIN required and no pin entered 1 0 1
Online PIN entered 0 0 0
Transaction exceeds floor limit 0 0 0
D–6
Visa Integrated Circuit Card D.4 VLP Purchase Transaction Process
Table D–3: Terminal TACs for VLP (2 of 2)
Card or Terminal Conditions Default Online Denial
Lower offline limit exceeded 0 0 0
Upper offline limit exceeded 0 0 0
Transaction selected randomly for online 0 0 0
Merchant forced transaction online 1 0 1
Default TDOL used 0 0 0
Issuer Authentication failed 0 0 0
Script Processing failed prior to final AC 0 0 0
Script Processing failed after final AC 0 0 0
According to regional or market rules, terminal exception files or use of a

terminal transaction log (for checking for excessive transactions on a single
card) may be implemented to reduce risk.
The terminal provides the VLP Issuer Authorization Code in the clearing
message in the Authorization Code in TCR 0. The receipt may include VLP
Available Funds, provided by the card to the terminal.
31 Oct 2001
Figure D–1: VLP Transaction Flow
Terminal Card
SELECT command
Card responds to
Terminal selects the SELECT
SELECT response
VIS AID command
(includes PDOL requesting VLP
Terminal Support Indicator,
Amount Authorized, and
Transaction Currency Code)
Terminal provides VLP

All are true?
Terminal Support
Txn Type is Purchase
Under txn limit for VLP Y Indicator greater than 0
VLP is supported in GET PROCESSING
OPTIONS command
Terminal provides VLP

Terminal Support Indicator
equal to 0 in GET
PROCESSING OPTIONS
command
GET PROCESSING OPTIONS command Card receives GET

VLP
(includes VLP Terminal Support Indicatior, PROCESSING Terminal Support
Terminal initiates N
Amount Authorized, and OPTIONS Indicator > 0?
processing by by issuing Transaction Currency Code) command
the GET PROCESSING
OPTIONS command Y
GET PROCESSING OPTIONS
response Txn
Currency Code = Application N
Currency Code?
AIP and AFL

N
Terminal terminates Y
received? initiate processing
Txn amount < or
Y N = to VLP Available N
Funds?
Terminal reads Terminal is Y

records from card VSDC capable?
Txn amount <
or = to VLP Single Transaction N
Limit?
VLP Issuer
Authorization Code N Y
present?
Last Online
Y ATC Register > 0 and PIN Try N
Counter > 0?
Terminal uses VLP Y

TACs and normal
processing continues
Issuer Authentication Failure N
Indicator = 0?
Card deducts the amount of txn from the VLP

Available Funds
Card responds to GET PROCESSING Options

with VLP AIP and VLP AFL (pointing to a file and
record containing the VLP Issuer Authorization
Code and the VLP Available Funds
Card responds with
VSDC AIP and AFL
D–8
Visa Integrated Circuit Card D.5 VLP Reset Transaction Processing
D.4.2 VSDC Transaction With a Non-VLP-Capable Card at a

VLP-Capable Terminal
The terminal selects the VSDC application using the Visa AID or Visa
Electron AID. In the card’s response, the PDOL if present in the FCI does not
request the VLP Terminal Support Indicator.
The terminal does not receive the request for the VLP Terminal Support
Indicator from the card and does not provide the VLP Terminal Support
Indicator to the card. The transaction is processed as standard VSDC.
For online transactions, the terminal processes any Issuer Script received on
the authorization response message.
D.5 VLP Reset Transaction Processing

The VLP card requests the VLP Terminal Support Indicator, Amount,
Authorized, and the Transaction Currency Code from the terminal in the
PDOL.
D.5.1 VSDC Online-Capable Terminal

The transaction is a VSDC transaction that is sent online for processing. The
terminal may permit display of VLP Available Funds, which is received from
the card in the Issuer Discretionary Data portion of the Issuer Application
Data.
The terminal processes any Issuer Script received on the authorization
response message.
D.5.2 Dedicated Online Unattended Terminal—VLP Reset-Capable

This online only terminal selects the VSDC application and extracts the
PDOL from the File Control Information received in the card response to the
SELECT command. This terminal does not contain the VLP Terminal Support
Indicator and cannot provide it in the response even if requested by the card.
The terminal processes the transaction as a standard VSDC transaction. The
message is an online status check, which is a special type of authorization that
will not impact the cardholder’s open to buy. The transaction amount is a
single unit of currency and the merchant type is “5999”.
The VLP Available Funds is received by the terminal in the Issuer
Discretionary Data portion of the Issuer Application data and sent in the
online authorization request to the Issuer.
31 Oct 2001
If the issuer approves the transaction, the terminal requests an approval from
the card and if the card approves, the VLP Available Funds is reset to the VLP
Funds Limit.
The terminal processes any Issuer Script received in the authorization
response message.
D–10
Acronyms E
Acronym Meaning
a alpha
AAC Application Authentication Cryptogram
AAR Application Authentication Referral
AC Application Cryptogram
ADA Application Default Action
ADF Application Definition File
AEF Application Elementary File
AFL Application File Locator
AID Application Identifier
AIP Application Interchange Profile
AMD Application Management Data
an alphanumeric
ans alphanumeric special
31 Oct 2001
Draft 12/18/00Visa Public E–1
Acronyms Visa Integrated Circuit Card
Acronym Meaning
APDU Application Protocol Data Unit
ARPC Authorization Response Cryptogram
ARQC Authorization Request Cryptogram
ATC Application Transaction Counter
ATM Automated Teller Machine
AUC Application Usage Control
Auth. authentication
b binary
BIN BASE Identification Number
C conditional
CA Certificate Authority
CAM Card Authentication Method
CDOL Card Risk Management Data Object List
Cert. certificate
CID Cryptogram Information Data
CLA Class Byte of the Command Message
cn compressed numeric
Cons. consecutive
CPLC Card Production Life Cycle Data
Cum. cumulative
CVM Cardholder Verification Method
E–2
Visa Integrated Circuit Card Acronyms
Acronym Meaning
CVR Card Verification Results
CVV Card Verification Value
DDA Dynamic Data Authentication
DDF Directory Definition File
DDOL Dynamic Data Authentication Data Object List
DEA Data Encryption Algorithm
DES Data Encryption Standard
DF dedicated file
EEPROM Electronically Erasable Programmable Read-Only Memory
EMV Europay, MasterCard, Visa
ENC MDK Master Data Encipherment DEA Key
ENC UDK Unique Data Encipherment DEA Key
FCI File Control Information
FCP File Control Parameters
FMD File Management Data
GPO GET PROCESSING OPTIONS
hex. hexadecimal
HHMMSS hours, minutes, seconds
HSM host security module
IA Issuer Authentication
IAC Issuer Action Code
31 Oct 2001
Draft 12/18/00 Visa Public E–3
Acronym Meaning
IC integrated circuit
ICC integrated circuit card
IEC International Electrotechnical Commission
IFD interface device
INS Instruction Byte of the Command Message
Int’l international
ISO International Organisation for Standardisation
Lc Length of the Command Data Field
Le Expected Length of the Response Data Field
LD Length of the plaintext data in the Command Data Field
LRC Longitudinal Redundancy Check
M mandatory
MAC Message Authentication Code
MAC MDK Master Message Authentication Code DEA Key
MAC UDK Unique Message Authentication Code DEA Key
MCC Merchant Category Code
MDK Master DEA Key
n numeric
N/A not applicable
NCA Length of the Certification Authority Public Key Modulus
NI Length of the Issuer Public Key Modulus
E–4
Visa Integrated Circuit Card Acronyms
Acronym Meaning
NIC Length of the ICC Public Key Modulus
No. number
O optional
P1 Parameter 1
P2 Parameter 2
PAN Primary Account Number
PDOL Processing Options Data Object List
PIN Personal Identification Number
PIX Proprietary Application Identifier Extension
PK public key
PKI Certificate Authority Public Key Index
POS point of service
PSE payment system environment
PVV PIN Verification Value
R required
RFU Reserved for Future Use
RID Registered Application Provider Identifier
ROM Read-Only Memory
RSA Rivest, Shamir, Adleman
SAD Signed Static Application Data
SAM Secure Access Module
31 Oct 2001
Draft 12/18/00 Visa Public E–5
Acronym Meaning
SDA Static Data Authentication
SFI Short File Identifier
SW1, SW2 Status Words
TC Transaction Certificate
TDOL Transaction Certificate Data Object List
TLV tag-length-value
Txn. transaction
TSI Transaction Status Information
TVR Terminal Verification Results
UDK Unique DEA Key
var. variable
V.I.P. VisaNet Integrated Payment
VLP Visa Low-value Payment
YDDD year, day where Y = right-most digit of the year (0–9) and DDD = Julian
day of the year (001–366)
YYMM year, month where YY = year (00–99) and MM = month (01–12)
YYMMDD year, month, day where DD = day (01–31)
E–6
Glossary
This is a glossary of terms used in this specification; it is not intended as a data dictionary.
For descriptions of terminal and acquirer data elements, refer to Appendix A of the Card
and Terminal volumes of this specification.
acquirer
A Visa member that signs a merchant or disburses currency to a cardholder in a cash
disbursement, and directly or indirectly enters the resulting transaction into interchange.
ANSI
American National Standards Institute. A U.S. standards accreditation organization.
application
A computer program and associated data that reside on an integrated circuit chip and
satisfy a business function. Examples of applications include payment, stored value, and
loyalty.
Application Authentication Cryptogram (AAC)

A cryptogram generated by the card for offline and online declined transactions.
application block
Instructions sent to the card by the issuer, to shut down the selected application on a card
to prevent further use of that application. This process does not preclude the use of other
applications on the card.
ATM
An unattended terminal that has electronic capability, accepts PINs, and disburses
currency or checks.
31 Oct 2001
Draft 12/18/00 Visa Public Glossary–1
Glossary Visa Integrated Circuit Card
ATM cash disbursement

A cash disbursement obtained at an ATM displaying the Visa, PLUS, or Visa Electron
acceptance mark, for which the cardholder’s PIN is accepted.
authentication
A cryptographic process that validates the identity and integrity of data.
authorization
A process where an issuer or a representative of the issuer approves a transaction.
authorization controls
Information in the chip application enabling the card to act on the issuer’s behalf at the
point of transaction. The controls help issuers manage their below-floor-limit exposure to
fraud and credit losses. Also known as offline authorization controls.
authorization request
A merchant’s or acquirer’s request for an authorization.
Authorization Request Cryptogram (ARQC)

The cryptogram generated by the card for transactions requiring online authorization and
sent to the issuer in the authorization request. The issuer validates the ARQC during the
Online Card Authentication (CAM) process to ensure that the card is authentic and was
not created using skimmed data.
authorization response
The issuer’s reply to an authorization request. Types of authorization responses are:
● approval
● decline
● pickup
●
referral
Authorization Response Cryptogram (ARPC)

A cryptogram generated by the issuer and sent to the card in the authorization response.
This cryptogram is the result of the Authorization Request Cryptogram (ARQC) and the
Issuer’s authorization response encrypted with the Unique Derivation Key (UDK). It is
validated by the card during Issuer Authentication to ensure that the response came from
a valid issuer.
Bank Identification Number (BIN)

A 6-digit number assigned by Visa and used to identify a member or processor for
authorization, clearing, or settlement processing.
Glossary–2
Visa Integrated Circuit Card BASE I Authorization System
BASE I Authorization System

The V.I.P. System component that performs message routing, cardholder and card
verification, and related functions such as reporting and file maintenance.
BASE II
The VisaNet system that provides deferred clearing and settlement services to members.
byte
8 bits of data.
card acceptance device

A device capable of reading and/or processing a magnetic stripe or chip on a card for the
purpose of performing a service such as obtaining an authorization or processing a
payment.
card authentication
A means of validating whether a card used in a transaction is the genuine card issued by
the issuer.
Card Authentication Method (CAM)

See Online Card Authentication.
card block
Instructions, sent to the card by the Issuer, which shut down all proprietary and
non-proprietary applications that reside on a card to prevent further use of the card.
Card Verification Value (CVV)

A unique check value encoded on a card’s magnetic stripe and chip to validate card
information during an online authorization.
cardholder
An individual to whom a card is issued or who is authorized to use that card.
cardholder verification
The process of determining that the presenter of the card is the valid cardholder.
Cardholder Verification Method (CVM)

A method used to confirm the identity of a cardholder.
cash disbursement
Currency, including travelers cheques, paid to a cardholder using a card.
31 Oct 2001
cashback
Cash obtained in conjunction with, and processed as, a purchase transaction.
CCPS
Chip Card Payment Service, the former name for Visa Smart Debit and Visa Smart Credit
(VSDC).
Certificate Authority (CA)

A trusted central administration that issues and revokes certificates.
chargeback
A transaction that an issuer returns to an acquirer.
chip
An electronic component designed to perform processing or memory functions.
chip-capable
A card acceptance device that is designed and constructed to facilitate the addition of a
chip reader/writer.
chip card
A card embedded with a chip that communicates information to a point-of-transaction
terminal.
clearing
The collection and delivery to the issuer of a completed transaction record from an
acquirer.
cleartext
See plaintext.
cryptogram
A numeric value that is the result of data elements entered into an algorithm and then
encrypted. Commonly used to validate data integrity.
cryptographic key
The numeric value entered into a cryptographic algorithm that allows the algorithm to
encrypt or decrypt a message.
cryptography
The art or science of keeping messages secret or secure, or both.
Glossary–4
Visa Integrated Circuit Card CVM List
CVM List
An issuer-defined list contained within a chip application establishing the hierarchy of
methods for verifying the authenticity of a cardholder.
data authentication
Validation that data stored in the integrated circuit card has not been altered since card
issuance. See also Offline Data Authentication.
Data Encryption Algorithm (DEA)

An encipherment operation and an inverse decipherment operation in a cryptographic
system.
Data Encryption Standard (DES)

The public domain symmetric key cryptography algorithm of the National Institute for
Standards and Technology.
decryption
The process of transforming ciphertext into cleartext.
DES key
A secret parameter of the Data Encryption Standard algorithm.
digital signature
A cryptogram generated by encrypting a message digest (or hash) with a private key that
allows the message content and the sender of the message to be verified.
double-length DES Key

Two secret 64-bit input parameters each of the Data Encryption Standard algorithm,
consisting of 56 bits that must be independent and random, and 8 error-detecting bits set
to make the parity of each 8-bit byte of the key odd.
Dynamic Data Authentication (DDA)

A type of Offline Data Authentication where the card generates a cryptographic value
using transaction-specific data elements for validation by the terminal to protect against
skimming.
Easy Entry
A replication of the magnetic stripe information on the chip to facilitate payment as part of
multi-application programs. Easy Entry is not EMV-compliant and is being phased out.
31 Oct 2001
EMV specifications
Technical specifications developed jointly by Europay International, MasterCard
International, and Visa International to create standards and ensure global
interoperability for use of chip technology in the payment industry.
encryption
The process of transforming cleartext into ciphertext.
expired card
A card on which the embossed, encoded, or printed expiration date has passed.
floor limit
A currency amount that Visa has established for single transactions at specific types of
merchants, above which online authorization is required.
Hardware Security Module (HSM)

A secure module used to store cryptographic keys and perform cryptographic functions.
hash
The result of a non-cryptographic operation, which produces a unique value from a data
stream.
host data capture system

An acquirer authorization system that retains authorized transactions for settlement
without notification from the terminal that the transaction was completed.
Integrated Circuit Card (ICC)

See chip card.
Integrated Circuit Chip

See chip.
interchange
The exchange of clearing records between members.
International Organisation for Standardisation (ISO)

The specialized international agency that establishes and publishes international
technical standards.
interoperability
The ability of all card acceptance devices and terminals to accept and read all chip cards
that are properly programmed.
Glossary–6
Visa Integrated Circuit Card issuer
issuer
A Visa member that issues Visa or Electron cards, or proprietary cards bearing the PLUS
or Visa Electron Symbol.
Issuer Action Codes (IACs)

Card-based rules which the terminal uses to determine whether a transaction should be
declined offline, sent online for an authorization, or declined if online is not available.
Validation of the issuer by the card to ensure the integrity of the authorization response.
See Authorization Response Cryptogram (ARPC).
key generation
The creation of a new key for subsequent use.
key management
The handling of cryptographic keys and other related security parameters during the
entire life cycle of the keys, including their generation, storage, distribution, entry and use,
deletion or destruction, and archiving.
magnetic stripe
The stripe on the back of the card that contains the magnetically coded account
information necessary to complete a non-chip electronic transaction.
Magnetic Stripe Image

The minimum chip payment service data replicating information in the magnetic stripe
required to process a transaction that is compliant with EMV.
Master Derivation Keys (MDK)

Master DES keys stored in the issuer host system. These keys are used to generate Unique
Derivation Keys (UDKs) for personalization, to validate ARQCs, and to generate ARPCs.
merchant category code (MCC)

A code designating the principal trade, profession, or line of business in which a merchant
is engaged.
message authentication code (MAC)

A digital code generated using a cryptographic algorithm which establishes that the
contents of a message have not been changed and that the message was generated by an
authorized entity.
31 Oct 2001
multi-application
The presence of multiple applications on a chip card (for example, payment, loyalty, and
identification).
nibble
The four most significant or least significant bits of a byte of data.
offline approval
A transaction that is positively completed at the point of transaction between the card and
terminal without an authorization request to the issuer.
offline authorization
A method of processing a transaction without sending the transaction online to the issuer
for authorization.
offline-capable
A card acceptance device that is able to perform offline approvals.

A process whereby the card is validated at the point of transaction using RSA public key
technology to protect against counterfeit or skimming. VIS includes two forms: Static Data
Authentication (SDA) and Dynamic Data Authentication (DDA).
offline decline
A transaction that is negatively completed at the point of transaction between the card
and terminal without an authorization request to the issuer.
offline-only terminal
A card acceptance device that is not capable of sending transactions online for issuer
authorization.
offline PIN
A PIN value stored on the card that is validated at the point of transaction between the
card and the terminal.
offline PIN verification

The process whereby a cardholder-entered PIN is passed to the card for comparison to a
PIN value stored secretly on the card.
online authorization
A method of requesting an authorization through a communications network other than
voice to an issuer or issuer representative.
Glossary–8
Visa Integrated Circuit Card online-capable terminal
online-capable terminal
A card acceptance device that is able to send transactions online to the issuer for
authorization.
Online Card Authentication (CAM)

Validation of the card by the issuer to protect against data manipulation and skimming.
See Authorization Request Cryptogram (ARQC).
online PIN
A method of PIN verification where the PIN entered by the cardholder into the terminal
PIN pad is DES-encrypted and included in the online authorization request message sent
to the issuer.
personalization
The process of populating a card with the application data that makes it ready for use.
plaintext
Data in its original unencrypted form.
point of transaction (POT)

The physical location where a merchant or acquirer (in a face-to-face environment) or an
unattended terminal (in an unattended environment) completes a transaction.
point-of-transaction terminal
A device used at the point of transaction that has a corresponding point-of-transaction
capability. See also Card Acceptance Device.
post-issuance update
A command sent by the issuer through the terminal via an authorization response to
update the electronically stored contents of a chip card.
private key
As part of an asymmetric cryptographic system, the key that is kept secret and known only
to the owner.
public key
As part of an asymmetric cryptographic system, the key known to all parties.
public key cryptographic algorithm

A cryptographic algorithm that allows the secure exchange of information, but does not
require a shared secret key, through the use of two related keys—a public key which may
be distributed in the clear and a private key which is kept secret.
31 Oct 2001
public key pair

The two mathematically related keys, a public key and a private key which, when used
with the appropriate public key cryptographic algorithm, can allow the secure exchange of
information, without the secure exchange of a secret.
purchase transaction
A retail purchase of goods or services; a point-of-sale transaction.
quasi-cash transaction
A transaction representing a merchant’s sale of items, such as gaming chips or money
orders, that are directly convertible to cash.
random selection
An EMV online-capable terminal function that allows for the selection of transactions for
online processing. Part of Terminal Risk Management.
receipt
A paper record of a transaction generated for the cardholder at the point of transaction.
referral response
An authorization response where the merchant or acquirer is instructed to contact the
issuer for further instructions before completing the transaction.
reversal
A BASE II or online financial transaction used to negate or cancel a transaction that has
been sent through interchange.
ROM (Read-Only Memory)

Permanent memory that cannot be changed once it is created. It is used to store chip
operating systems and permanent data.
RSA (Rivest, Shamir, Adleman)

A public key cryptosystem developed by Rivest, Shamir, and Adleman, used for data
encryption and authentication.
secret key
A key that is used in a symmetric cryptographic algorithm (that is, DES), and cannot be
disclosed publicly without compromising the security of the system. This is not the same as
the private key in a public/private key pair.
secure messaging
A process that enables messages to be sent from one entity to another, and protects against
unauthorized modification or viewing.
Glossary–10
Visa Integrated Circuit Card session key
session key
A temporary cryptographic key computed in volatile memory and not valid after a session
is ended.
settlement
The reporting of settlement amounts owed by one member to another or to Visa, as a result
of clearing.
Single Message System

A component of the V.I.P. System that processes Online Financial and Deferred Clearing
transactions.
smart card
A commonly used term for a chip card.
Static Data Authentication (SDA)

A type of Offline Data Authentication where the terminal validates a cryptographic value
placed on the card during personalization. This validation protects against some types of
counterfeit, but does not protect against skimming.
Terminal Action Codes (TACs)

Visa-defined rules in the terminal which the terminal uses to determine whether a
transaction should be declined offline, sent online for an authorization, or declined if
online is not available.
transaction
An exchange of information between a cardholder and a merchant or an acquirer that
results in the completion of a financial transaction.
Triple DES
The data encryption algorithm used with a double-length DES key.
V.I.P. System
VisaNet Integrated Payment System, the online processing component of VisaNet.
Visa Certificate Authority (CA)

A Visa-approved organization certified to issue certificates to participants in a Visa
payment service.
Visa Low-value Payment (VLP)

VLP is a feature of VSDC designed to provide an optional source of pre-authorized
spending power that is reserved for rapid processing of offline low-value payments.
31 Oct 2001
Visa Smart Debit and Visa Smart Credit (VSDC)

The Visa service offerings for chip-based debit and credit programs. These services, based
on EMV and VIS specifications, are supported by VisaNet processing, as well as by Visa
rules and regulations.
VisaNet
The systems and services, including the V.I.P. and BASE II systems, through which Visa
delivers online financial processing, authorization, clearing, and settlement services to
members.
Glossary–12
Index
A ARPC, 12–5
ARQC, 10–8, 11–2, 11–4, 12–2, 12–6 to 12–7, 13–1,
AAC, 10–8 to 10–9, 11–2, 11–4, 12–7, 13–1, 13–5, B–3
13–5 to 13–11, B–3
ATC, 9–3, 9–5, 9–7, 11–2, 12–2, 12–4, 13–3, B–4
AAR, B–3
ATM, 1–7, 6–3, 7–4 to 7–5, 13–7, C–1 to C–2, C–4
account transfer, 13–7
Authorization Response Code, 10–3, 10–8, 12–5, 13–4,
advice message, 13–6, 14–2, 14–5, C–2 13–6
AFL. See Application File Locator
AID, 3–2, 9–3, D–4, D–9 B
AID matching example, 3–9 balance inquiry, 13–7
Amount entry, C–2 biometrics, 8–1
Amount X, 8–4 bypass PIN entry, 8–13, 8–21
Amount Y, 8–4
Amount, Authorized, 8–7, 9–4 to 9–5, 12–4, C
D–3 to D–4, D–9 candidate list, building the, 3–6
Amount, Other, 12–4 Card Action Analysis, 2–4, 2–8, 11–1 to 11–5, 12–10,
APPLICATION BLOCK command, 14–3 13–11
Application Cryptogram, 11–2, 12–2, 12–4, 13–3 card data, 11–2
Application Currency Code, 8–3, D–2 processing, 11–4
Application Definition File, 3–2, 3–7, B–6 to B–7 terminal data, 11–3
Application Effective Date, 7–2 CARD BLOCK command, 14–3
Application Elementary Files, 3–2, 5–2 card data
Application Expiration Date, 7–2 for Application Selection, 3–2
Application File Locator, 4–1 to 4–6, 5–2, 6–10, B–5, for Card Action Analysis, 11–2
D–2, D–4 for Cardholder Verification, 8–3
Application Interchange Profile, 4–1 to 4–6, 6–5, 8–3, for Completion, 13–2
8–9, 9–1, 12–3 to 12–4, 12–8, B–5, D–2 for Dynamic Data Authentication, 6–12
Application Label, 3–2, B–7 for Initiate Application Processing, 4–2
Application PAN Sequence Number, 12–4 for Issuer-to-Card Script Processing, 14–2
Application Preferred Name, 3–3, B–6 to B–7 for Online Processing, 12–2
Application Priority Indicator, 3–3, B–7 for Processing Restrictions, 7–2
Application Selection, 1–7, 2–1, 2–7, 3–1 to 3–15, 4–6 for Static Data Authentication, 6–7
card data, 3–2 for Terminal Action Analysis, 10–2
identifying and selecting the application, 3–10 for Terminal Risk Management, 9–3
processing flow, 3–12 to 3–14 card life cycle data, B–4
terminal data, 3–4 card override of terminal decision, 11–4
Application Selection Indicator, 1–7, 3–4 card reader, 8–7, 8–15
APPLICATION UNBLOCK command, 14–3, B–2 Card Risk Management checks, 11–4
Application Usage Control, 7–2, 7–4 to 7–6 card velocity checking. See velocity checking, card
Application Version Number (“9F08”), 7–2 cardholder confirmation, 3–10
Application Version Number (“9F09”), 7–3
31 Oct 2001
Draft 12/18/00 Visa Public Index–1
D Visa Integrated Circuit Card
cardholder selection, 3–10 to 3–11 counters, 13–1

Cardholder Verification, 2–3, 2–7, 4–2, 4–6, credit, 12–1
8–1 to 8–22, 10–11 cryptogram, 10–1
card data, 8–3 Cryptogram Information Data, 11–2, 12–2, 12–10,
CVM List Processing, 8–9 13–3, 13–5, 13–9
CVM Processing, 8–13 cryptogram type, 10–5, 13–9
processing, 8–9 cryptogram version 10, 12–4
terminal requirements, 8–3 cryptogram version 14, 1–8, 12–4
Cardholder Verification Method List. See CVM List Cumulative Total Transaction Amount Upper Limit,
Cardholder Verification Method. See CVM 1–9
cash, 7–5, 8–4 CVM Code, 8–4, 8–10 to 8–22
cash disbursement, 13–7 CVM Conditions, 8–4, 8–10
cashback, 7–5, C–2 CVM Entry, 8–10
CDOL1, 10–3, 10–5, 11–2 to 11–3 CVM List, 1–7 to 1–8, 2–3, 8–1, 8–4, 8–9 to 8–10, D–2
CDOL2, 13–2, 13–4, 13–8 CVM List processing, 8–3, 8–9
Certificate Authority Public Key Index, 6–7 to 6–11, card data, 8–3
6–15, 6–18, 8–5, 8–8 processing flow, 8–12
Certificate Serial Number, 6–9, 6–15, 6–18 CVM results, 8–7
Chip Condition Code, C–3 CVM Type, 8–4
chip read, C–3 CVR, 8–6, 11–2, 13–3
CID. See Cryptogram Information Data
clearing message, 13–1, 13–6, 14–2, 14–5, B–3
D
Combined DDA/AC Generation, 1–7 to 1–8, 2–2, 2–7, Data Authentication Code (DAC), 1–7
6–1, 6–18 to 6–19, 6–23 to 6–24, 10–9 DDA, 2–2, 4–2, 5–1 to 5–2, 6–1, 6–12 to 6–22, 8–5,
online processing, 12–6 8–19
Combined DDA/AC Generation failure, 12–7, card data, 6–12
12–10 to 13–1, 13–5 terminal data, 6–13
command response, B–2 DDOL, 6–12 to 6–22
command support requirements, 2–9 Dedicated File Name, B–6
commands, 14–3 default CVM, 2–3
APPLICATION BLOCK, 14–3 Default DDOL, 6–13 to 6–22
APPLICATION UNBLOCK, 14–3 DES, 11–5
CARD BLOCK, 14–3 DES keys, 8–7
EXTERNAL AUTHENTICATE, 12–6, B–2 Directory Definition File, 3–3, 3–7, B–6
GENERATE AC, 10–5, 11–2 to 11–5, 12–6, Directory File, 3–3
13–4 to 13–11, B–3 Directory Selection Method, 1–7, 3–6 to 3–8,
GET CHALLENGE, 8–8, 8–19, B–3 3–10 to 3–11
GET DATA, 8–8, 9–5, B–4 domestic, 7–5
GET PROCESSING OPTIONS, 4–3, B–5 dynamic signature, 6–14, 6–17, 12–6
INTERNAL AUTHENTICATE, 6–14, B–5
PIN CHANGE/UNBLOCK, 14–4
E
PUT DATA, 14–4 effective date checking, 7–6
READ RECORD, 3–5, B–5 EMV, 1–3, 1–6 to 1–7, D–4
SELECT, 3–5, B–5 to B–6 EMV documentation, 1–11
UPDATE RECORD, 14–4 Enciphered PIN data, 8–7
VERIFY, 8–9, B–7 Enter PIN, 8–14, 8–17
Completion, 2–5, 2–8, 6–23, 12–7 to 13–11, 14–7 expiration date checking, 7–6
card data, 13–2 expired application, 7–6, 10–4
processing flow, 13–10 EXTERNAL AUTHENTICATE command, 2–9, 12–6,
12–8, B–1 to B–2
Index–2
Visa Integrated Circuit Card F
F ICC Private Key, 6–16

ICC Public Key, 1–8, 2–2, 6–17, 8–19, 12–6
Fail CVM, 8–22
ICC Public Key Exponent, 6–12
FCI Issuer Discretionary Data, B–6
ICC Public Key Modulus, 6–17
FCI Proprietary Template, B–6
ICC Public Key Remainder, 6–12
FCI Template, B–6 to B–7
incorrect PIN, 8–17
File Control Information, 3–3, 3–7, 4–2, 4–4, D–4, D–9
indicators, 13–1
final approval by card, D–10
Initiate Application Processing, 2–2, 2–7, 3–5, 3–15,
floor limits, 9–5 4–1, 5–2, 5–5, 6–23, 8–23
fraud risk, 6–7, 12–1, D–1 card data, 4–2
functional overview, 2–1 processing, 4–4
functions processing flow, 4–5
Application Selection, 3–1 to 3–15 terminal data, 4–3
Card Action Analysis, 11–1 Interface Device (IFD) Serial Number, 12–4
Cardholder Verification, 8–1 INTERNAL AUTHENTICATE command, 2–9,
Completion, 13–1 to 13–11 6–13 to 6–16, B–1, B–5
Initiate Application Processing, 4–1 international, 7–5
Issuer-to-Card Script Processing, 14–1 to 14–7 ISO documentation, 1–10
Offline Data Authentication, 6–1 Issuer Application Data, 11–2, 12–2, 12–4, B–3, D–2,
Online Processing, 12–1 D–9 to D–10
Processing Restrictions, 7–1 issuer approval, D–10
Read Application Data, 5–1 Issuer Authentication, 2–5, 4–2, 12–1, 12–6 to 13–1
Terminal Action Analysis, 10–1 Issuer Authentication Data, 12–5 to 12–6, 12–8, B–2
Terminal Risk Management, 9–1 Issuer Code Table Index, 3–3, B–6 to B–7
functions, mandatory and optional, 2–7 Issuer Country Code “5F28”, 7–2, 7–4
Issuer Discretionary Data, D–9 to D–10
G issuer host, 12–1, 12–5
GENERATE AC command, 2–9, 12–6 to 12–7, Issuer Identification Number, 6–9
13–4 to 13–11, 14–2, 14–4, B–1, B–3, C–2 Issuer PK Certificate, 6–7, 6–9, 6–15, 6–18, 8–5
Completion, 13–1 Issuer Private Key, 8–5
Terminal Action Analysis, 10–5 to 10–10, Issuer Public Key, 1–8, 2–2, 6–9, 6–15, 6–18
11–3 to 11–5
Issuer Public Key Certificate. See Issuer PK Certificate
GET CHALLENGE command, 2–9, 8–8, 8–19, B–1,
Issuer Public Key Exponent, 6–7, 6–15, 6–18, 8–6
B–3
Issuer Public Key Modulus, 6–9, 6–15, 6–18
GET DATA command, 2–9, 8–8, 8–13 to 8–15, 9–5,
9–7 to 9–8, B–1, B–4 Issuer Public Key Remainder, 6–7, 6–9, 6–15, 6–18,
8–5
GET PROCESSING OPTIONS command, 2–9, 3–15,
4–1, 4–3 to 4–6, B–1, B–5, D–4 issuer script, 12–5, 14–3 to 14–4, D–9 to D–10
issuer script commands, B–1 to B–2
H Issuer Script Identifier, 14–2
hash, 6–10, 6–13, 6–15, 6–18, 12–7 Issuer Script Results, 13–6, 14–2, 14–5
host-data-capture system, 13–7 issuer scripts. See Issuer-to-Card Script processing
Issuer-to-Card Script Processing, 2–5, 12–1, 13–6,
I 14–1 to 14–7
IACs, 10–1 to 10–11, 13–2, 13–8, D–2 card data, 14–2
ICC Dynamic Data, 6–13 commands, 14–3
ICC Dynamic Number, 1–7 online response data, 14–3
ICC PIN Encipherment key data, 8–19 processing, 14–4
ICC PIN Encipherment Private Key, 8–5 processing flow, 14–6
ICC PK Certificate, 6–12, 6–16, 6–19 terminal data, 14–2
31 Oct 2001
K Visa Integrated Circuit Card
K Online Authorization Indicator, 1–8 to 1–9

online authorization message, 12–4 to 12–5, 14–2,
key entered, 12–1 14–5, B–3
L Online Card Authentication, 2–5, 12–1
online PIN, 8–1, 8–21, 10–4
Language Preference, B–6 to B–7
Online Processing, 2–4, 2–8, 4–6, 6–23, 12–1, 13–11,
Last Online ATC Register, 9–3, 9–5, 9–7 to 9–8, B–4 14–7
Last PIN Try, 8–3, 8–14, 8–17 card data, 12–2
List of AIDs Method, 1–7, 3–6 to 3–7, 3–9 commands, 12–6
Lower Consecutive Offline Limit “9F14”, 9–3, new response data elements, 12–5
9–7 to 9–8, 10–4
Processing, 12–6
M processing flow, 12–9
terminal data, 12–2 to 12–3
magnetic stripe read, 12–1, C–3
Online Processing Requested, Online Authorization
magnetic stripe reader, C–4
Not Completed, 13–8
mandatory, 1–3
online request, 10–1, 11–4, 12–6, C–3
manual entry, C–4
online response, 12–5 to 12–6
Maximum Target Percentage to be used for Biased
online-capable terminal, 9–5, C–1, D–9
Random Selection, 9–4, 9–6
online-only terminal, 6–3, C–1, D–9
merchant floor limit. See floor limits
optional, 1–3
Merchant Forced Transaction Online, 9–5, 10–4
Merchant type, D–1, D–9 P
multiple commands, 14–4
PAN, 6–9, 6–16, 6–19, 9–3, 9–5, C–4
N Payment Systems Directory, 3–7
Payment Systems Environment, 3–3, 3–5, 3–7
new card, 9–8, 11–4
PDOL, 3–3, 3–5, 4–1 to 4–6, B–5, B–7, D–2, D–4, D–9
No CVM Required, 8–23
PIN block, 8–19
O PIN CHANGE/UNBLOCK command, 14–4, B–2
offline approval, 10–1, 11–4, 13–4 to 13–5, 13–8, D–1 PIN encipherment, 8–15
Offline Data Authentication, 2–2, 2–7, 4–2, 4–6, 5–5, PIN OK, 8–17
6–1, 10–4, 10–11 PIN pad, 8–3, 8–7, 8–13 to 8–20
terminal requirements, 6–3 PIN Pad Secret Key, 8–7, 8–13, 8–15
offline decline, 10–1, 11–4, 13–1, 13–4 to 13–5, 13–8, PIN Try Counter, 8–5, 8–8, 8–13, 8–16, B–4
D–1 PIN Try Counter checking, 8–15
Offline Enciphered PIN, 1–7, 8–1, 8–7, 8–16, 8–19 PIN Try Limit, 8–6 to 8–9, 8–16 to 8–18, 8–21
card data, 8–5 PIX, 3–2
Offline Enciphered PIN processing flow, 8–20 POS device, 13–7
offline low-value payments, D–1 POS Entry Mode, C–3
Offline PIN, B–7 post-issuance updates. See Issuer-to-Card Script
Offline PIN Processing Processing
card data, 8–5 processing overview, 2–1
Offline PIN processing Processing Restrictions, 2–3, 2–7, 7–1, 10–11
card data, 8–6 Application Effective Date, 7–6
Offline PIN Processing flow, 8–18 Application Expiration Date, 7–6
Offline Plaintext PIN, 8–1, 8–9, 8–13, 8–15 Application Usage Control, 7–4
offline-capable terminal, 9–7, C–1 Application Version Number, 7–3
offline-only terminal, 13–1, C–1 card data, 7–2
offline-only transaction, D–4 processing flow, 7–7
online approval, 13–1 terminal data, 7–3
online authorization, 13–1, 13–4, 13–6, D–1, D–9
Index–4
Visa Integrated Circuit Card Q
PSE File Name, 3–4 Subsequent Related Processing

PUT DATA command, 14–4 Card Action Analysis, 8–24, 10–11
Completion, 8–24, 11–5, 12–10
Q Issuer-to-Card Script Processing, 8–24, 12–10
quasi-cash, 8–4 Online Processing, 11–5
Terminal Action Analysis, 8–24, 9–11
R
Random Transaction Selection, 9–6, 10–4 T
Read Application Data, 2–2, 4–6 to 5–1, 6–23, 7–8, TACs, 10–1 to 10–11, 13–4, 13–8, D–3, D–6
8–23, 9–11, 10–11, 11–5 tamper-evident device, 8–7
card data, 5–2 Target Percentage to be used for Random Selection,
card files, 5–2 9–4, 9–6
processing, 5–3 TC, 10–9, 11–2, 11–4, 12–6 to 12–7, 13–1,
processing flow, 5–4 13–5 to 13–11, B–3
READ RECORD command, 2–9, 3–5, 3–7, 5–2 to 5–3, TC Hash Value, 10–5
B–1, B–5 Terminal Action Analysis, 2–4, 2–8, 6–23, 7–8,
receipt, 8–21, 13–1, C–5 10–1 to 10–11, 11–5, 13–8
recommended, 1–3 card data, 10–2
Reference PIN, 8–5 to 8–6, 8–9, 8–16, 14–4 processing, 10–6
referrals, 13–6, B–3 processing flow, 10–10
required, 1–3 terminal data, 10–3
reversals, 13–7, 14–2, C–2 Terminal Capabilities, 6–4 to 6–5, 8–7, 8–10, 12–4
RID, 3–2, 6–7 to 6–9, 6–15, 6–18, 8–6, 8–8 Terminal Country Code, 4–3, 7–3, 12–4
RSA, 6–3 terminal data
RSA key management, 6–4 for Application Selection, 3–4
for Card Action Analysis, 11–3
S for Cardholder Verification, 8–7
script errors, 14–5 for Completion, 13–4
scripts, multiple, 14–5 for Initiate Application Processing, 4–3
SDA, 2–2, 2–7, 4–2, 5–1 to 5–2, 6–1, 6–7 for Issuer-to-Card Script Processing, 14–2
SDA or DDA, determining which to perform Offline for Online Processing, 12–3
Data Authentication, 6–4 to 6–6 for Processing Restrictions, 7–3
SDA Tag List, 1–7 to 1–8 for Terminal Action Analysis, 10–3
SELECT command, 2–9, 3–5, 3–7 to 3–15, B–1, B–6, for Terminal Risk Management, 9–4
D–9
Terminal Exception File, 9–5, 10–4, D–7
Service Code, C–3
terminal floor limit, 9–4 to 9–6, 10–4, D–3 to D–4
services, 7–5
terminal messages, 3–10, 8–3, 8–14 to 8–18,
Session Key Generation, 1–8 13–6 to 13–7, 13–9, 14–5, C–3
Short File Identifier, 3–3, 3–5, 5–2, B–6 terminal random number, 9–6
signature and offline PIN, 8–1, 8–21 to 8–22 Terminal Risk Management, 2–3, 2–8, 9–1, 10–6,
signature, cardholder, 13–1 10–11
Signed Dynamic Application Data, 6–13 to 6–22, 12–6 card data, 9–3
Signed Static Application Data, 6–7, 6–10, 6–12 processing flow, 9–8
skimming, 6–1 terminal data, 9–4
Standard DDA, 2–2, 2–7, 6–15, 6–18 terminal velocity checking, 9–7
Standard Online Processing, 12–6 to 12–7 terminated transactions, 1–3
Standard VSDC, D–5, D–9 Threshold Value for Biased Random Selection, 9–4,
Static Data Authentication Tag List, 6–8, 6–10, 6–16, 9–6
6–19 transaction authorized offline, Completion, 13–5
static data to be authenticated, 6–8 transaction authorized online, Completion, 13–6
31 Oct 2001
U Visa Integrated Circuit Card
Transaction Currency Code, 8–7, 8–10, 12–4, VLP Terminal Support Indicator, D–3 to D–4, D–9
D–3 to D–4, D–9 VLP Terminal Transaction Limit, D–3 to D–4
Transaction Date, 7–3, 7–6, 12–4, C–4
transaction flow, sample, 2–6 Y
Transaction Log, 9–4 to 9–5, D–7 Y1 Authorization Response Code, 10–9, 13–4 to 13–5
Transaction PIN, 8–5, 8–7, 8–9, 8–13, 8–15 to 8–16, Y3 Authorization Response Code, 13–4, 13–8
8–19
Transaction Status Information (TSI), 4–3 to 4–4, 6–4, Z
6–10, 6–17, 8–7, 8–11, 9–4, 9–8, 12–3, 12–7 to 12–8, Z1 Authorization Response Code, 10–8, 12–10,
14–2, 14–4 13–4 to 13–5
Transaction Time, C–4 Z3 Authorization Response Code, 10–9, 13–4, 13–8
Transaction Type, 7–3, 12–4, D–4
TVR, 4–3 to 4–4, 6–4 to 6–5, 6–8, 6–10, 6–13, 6–17,
7–3, 8–7, 8–9, 8–16 to 8–17, 8–21, 9–4 to 9–8,
10–2 to 10–11, 12–3 to 12–4, 12–7 to 12–8, 13–4, 14–2,
14–5
U
unable to go online, 13–4, 13–8
Unpredictable Number, 6–13, 6–16, 8–8, 12–4
unrecognized CVM, 8–7, 8–10 to 8–12
UPDATE RECORD command, 14–4
Upper Consecutive Offline Limit “9F23”, 9–3,
9–7 to 9–8, 10–4
Use Chip Reader, C–3
V
velocity checking, card, 11–1, 11–4
velocity checking, terminal, 9–7
VERIFY command, 2–9, 8–5, 8–9, 8–16 to 8–20, B–1,
B–7
Visa Certificate Authority, 6–3
Visa documentation, 1–11
Visa Integrated Circuit Card Specification, 1–1
impact summary, 1–7
revisions, 1–6
update, 1–2
Visa Low-value Payment, 1–7, 1–9, D–1
Visa Private Key, 8–5
Visa Public Key, 6–9, 6–15, 6–18, 8–8 to 8–9
Visa Public Key Modulus, 6–9, 6–15, 6–18
VLP
duplicate data elements, D–1 to D–2, D–4, D–6
reset transaction, D–1, D–9
VLP Available Funds, D–1 to D–2, D–4, D–7,
D–9 to D–10
VLP capable, card, D–4, D–9
VLP capable, terminal, D–4, D–9
VLP Funds Limit, D–1 to D–2, D–10
VLP Issuer Authorization Code, D–3 to D–4, D–7
VLP processing, D–4
Index–6
Draft 12/18/00
VLP Single Transaction Limit, D–1, D–3
Visa Public 31 Oct 2001

Visa Integrated Circuit Card Terminal Specification

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Visa Integrated Circuit Card Terminal Specification

Diunggah oleh

Hak Cipta:

Format Tersedia

Welcome to

This document is the final copy of the Visa ICC Specification

If you have any comments regarding this manual, please

Effective: 31 October 2001

 Visa International 1998, 1999, 2001 5103-03

Printed on recycled paper.

Chapter 1 • About This Specification

1.2 VIS Update . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2

1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–3

1.3.1 Mandatory/Required/Recommended/Optional . . . . . . . . . . . 1–3

1.3.2 Card/Integrated Circuit . . . . . . . . . . . . . . . . . . . . 1–3

1.3.3 Terminated Transactions . . . . . . . . . . . . . . . . . . . . 1–3

1.4 Document Structure . . . . . . . . . . . . . . . . . . . . . . . . 1–4

1.4.1 Volume Overview . . . . . . . . . . . . . . . . . . . . . . 1–4

1.4.2 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . 1–4

1.4.3 Subheading Overview . . . . . . . . . . . . . . . . . . . . . 1–6

1.5 Revisions to This Specification . . . . . . . . . . . . . . . . . . . . 1–6

1.6 Impact Summary . . . . . . . . . . . . . . . . . . . . . . . . . 1–7

1.6.1 Terminal . . . . . . . . . . . . . . . . . . . . . . . . . . 1–7

1.6.1.1 Mandatory . . . . . . . . . . . . . . . . . . . . . . . 1–7

1.6.1.2 Optional . . . . . . . . . . . . . . . . . . . . . . . . 1–7

1.6.2 Card . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–8

1.6.2.1 Mandatory . . . . . . . . . . . . . . . . . . . . . . . 1–8

1.6.2.2 Optional . . . . . . . . . . . . . . . . . . . . . . . . 1–8

1.7 Reference Materials . . . . . . . . . . . . . . . . . . . . . . . 1–10

1.7.1 International Organisation for Standardisation (ISO) Documents . . . . 1–10

1.7.2 EMV Documents . . . . . . . . . . . . . . . . . . . . . . 1–11

1.7.3 Visa Documents . . . . . . . . . . . . . . . . . . . . . . 1–11

Chapter 2 • Processing Overview

2.1.1 Application Selection (mandatory) . . . . . . . . . . . . . . . . . 2–1

2.1.2 Initiate Application Processing/Read Application Data (mandatory) . . . . 2–2

2.1.3 Offline Data Authentication . . . . . . . . . . . . . . . . . . . 2–2

2.1.4 Processing Restrictions (mandatory) . . . . . . . . . . . . . . . . 2–3

2.1.5 Cardholder Verification (mandatory) . . . . . . . . . . . . . . . . 2–3

2.1.6 Terminal Risk Management (mandatory) . . . . . . . . . . . . . . 2–3

2.1.7 Terminal Action Analysis (mandatory) . . . . . . . . . . . . . . . 2–4

2.1.8 Card Action Analysis (mandatory) . . . . . . . . . . . . . . . . . 2–4

2.1.9 Online Processing . . . . . . . . . . . . . . . . . . . . . . . 2–4

2.1.10 Issuer-to-Card Script Processing . . . . . . . . . . . . . . . . . 2–5

2.1.11 Completion (mandatory) . . . . . . . . . . . . . . . . . . . . 2–5

2.2 Terminal Mandatory and Optional Functionality . . . . . . . . . . . . . . 2–7

2.2.1 Command Support Requirements . . . . . . . . . . . . . . . . . 2–9

Chapter 3 • Application Selection

3.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4

3.3 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–5

3.4 Building the Candidate List . . . . . . . . . . . . . . . . . . . . . . 3–6

3.4.1 Directory Selection Method . . . . . . . . . . . . . . . . . . . 3–7

3.4.2 List of AIDs Method . . . . . . . . . . . . . . . . . . . . . . 3–9

3.5 Identifying and Selecting the Application . . . . . . . . . . . . . . . . 3–10

3.5.1 Terminal Makes Application Selection Decision . . . . . . . . . . . 3–10

3.5.2 Cardholder Makes Account Selection Decision . . . . . . . . . . . 3–10

3.5.2.1 Terminal Supports Cardholder Confirmation . . . . . . . . . . 3–10

3.5.2.2 Terminal Supports Cardholder Selection . . . . . . . . . . . 3–11

3.6 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–12

3.7 Subsequent Related Processing . . . . . . . . . . . . . . . . . . . 3–15

Chapter 4 • Initiate Application Processing

4.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . 4–3

4.3 GET PROCESSING OPTIONS Command . . . . . . . . . . . . . . . 4–3

4.4 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4

4.5 Prior Related Processing . . . . . . . . . . . . . . . . . . . . . . 4–6

4.6 Subsequent Related Processing . . . . . . . . . . . . . . . . . . . 4–6

Chapter 5 • Read Application Data

5.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2