Visa Integrated Circuit Card Application Overview

Welcome to
Visa Integrated Circuit

Card Application
Overview
The Visa Integrated Circuit Card (ICC) Application
Overview 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
Application Overview
Version 1.4.0
Effective: 31 October 2001
 Visa International 1998, 1999, 2001 5101-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
Application Overview, 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 Mandatory and Optional Functionality . . . . . . . . . . . . . . . . . 2–7
2.2.1 Card Functional Requirements . . . . . . . . . . . . . . . . . . 2–7
2.2.2 Terminal Functional Requirements . . . . . . . . . . . . . . . . 2–9
2.2.3 Command Support Requirements . . . . . . . . . . . . . . . . 2–11
2.3 Visa Low-Value Payment (VLP) Feature . . . . . . . . . . . . . . . . 2–12
2.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 2–12
Chapter 3 • Application Selection

3.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2
3.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–3
3.3 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–3
ii
Draft 12/18/00 Visa Public 31 Oct 2001
Visa Integrated Circuit Card Contents
3.4 Building the Candidate List . . . . . . . . . . . . . . . . . . . . . 3–4
3.5 Identifying and Selecting the Application . . . . . . . . . . . . . . . . 3–4
3.5.1 Terminal Makes Application Decision . . . . . . . . . . . . . . . 3–4
3.5.2 Cardholder Makes Account Decision . . . . . . . . . . . . . . . 3–5
3.5.2.1 Terminal Supports Cardholder Confirmation . . . . . . . . . . 3–5
3.5.2.2 Terminal Supports Cardholder Selection . . . . . . . . . . . 3–5
3.6 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
3.7 Subsequent Related Processing . . . . . . . . . . . . . . . . . . . 3–7
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 Terminal Processing . . . . . . . . . . . . . . . . . . . . . . . . 4–3
4.5 Card Processing . . . . . . . . . . . . . . . . . . . . . . . . . 4–4
4.6 Terminal Processing . . . . . . . . . . . . . . . . . . . . . . . . 4–4
4.7 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–5
4.8 Prior Related Processing . . . . . . . . . . . . . . . . . . . . . . 4–6
Chapter 5 • Read Application Data

5.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2
5.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . 5–3
5.3 READ RECORD Command . . . . . . . . . . . . . . . . . . . . . 5–3
5.4 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–3
5.5 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–4
31 Oct 2001
Draft 12/18/00 Visa Public iii
Chapter 6 • Offline Data Authentication

6.1 Keys and Certificates . . . . . . . . . . . . . . . . . . . . . . . . 6–3
6.1.1 Visa Certificate Authority (CA) . . . . . . . . . . . . . . . . . . 6–3
6.1.2 RSA Key Pairs . . . . . . . . . . . . . . . . . . . . . . . . 6–3
6.1.2.1 Visa Public/Private Keys . . . . . . . . . . . . . . . . . . 6–3
6.1.2.2 Issuer Public/Private Keys . . . . . . . . . . . . . . . . . 6–3
6.1.2.3 ICC Public/Private Keys . . . . . . . . . . . . . . . . . . 6–4
6.1.3 SDA Key, Certificate, and Signature Relationships . . . . . . . . . . 6–4
6.1.4 DDA Key, Certificate, and Signature Relationships . . . . . . . . . . 6–5
6.2 Determining Whether to Perform SDA or DDA . . . . . . . . . . . . . . 6–7
6.3 Static Data Authentication (SDA) . . . . . . . . . . . . . . . . . . . 6–8
6.3.1 SDA Processing . . . . . . . . . . . . . . . . . . . . . . . . 6–9
6.4 Dynamic Data Authentication (DDA) . . . . . . . . . . . . . . . . . 6–11
6.4.1 Data Elements for DDA Processing . . . . . . . . . . . . . . . 6–11
6.4.2 Standard DDA Processing . . . . . . . . . . . . . . . . . . . 6–13
6.4.3 Combined DDA/AC Generation Processing . . . . . . . . . . . . 6–14
6.5 Prior Related Processing . . . . . . . . . . . . . . . . . . . . . 6–16
Chapter 7 • Processing Restrictions

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

8.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–3
8.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . 8–6
8.3 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–7
8.4 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–8
8.4.1 CVM List Processing . . . . . . . . . . . . . . . . . . . . . 8–8
8.4.2 CVM Processing . . . . . . . . . . . . . . . . . . . . . . . 8–10
8.4.2.1 Offline Plaintext PIN . . . . . . . . . . . . . . . . . . . 8–10
8.4.2.2 Offline Enciphered PIN . . . . . . . . . . . . . . . . . . 8–10
8.4.2.3 Online PIN . . . . . . . . . . . . . . . . . . . . . . . 8–11
8.4.2.4 Signature . . . . . . . . . . . . . . . . . . . . . . . 8–11
8.4.2.5 No CVM Required . . . . . . . . . . . . . . . . . . . . 8–11
8.4.2.6 Fail CVM . . . . . . . . . . . . . . . . . . . . . . . 8–11
Chapter 9 • Terminal Risk Management

9.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–2
9.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . 9–3
9.3 GET DATA Command . . . . . . . . . . . . . . . . . . . . . . . 9–4
9.4 Terminal Exception File . . . . . . . . . . . . . . . . . . . . . . 9–4
9.5 Merchant Forced Transaction Online . . . . . . . . . . . . . . . . . 9–4
9.6 Floor Limit Checking . . . . . . . . . . . . . . . . . . . . . . . . 9–4
9.7 Random Transaction Selection . . . . . . . . . . . . . . . . . . . . 9–4
9.8 Terminal Velocity Checking . . . . . . . . . . . . . . . . . . . . . 9–5
9.9 New Card Checking . . . . . . . . . . . . . . . . . . . . . . . . 9–5
9.11 Subsequent Related Processing . . . . . . . . . . . . . . . . . . 9–8
31 Oct 2001
Draft 12/18/00 Visa Public v
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–4
10.4 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 10–4
10.4.1 Review Offline Processing Results . . . . . . . . . . . . . . . 10–4
10.4.2 Request Application Cryptogram . . . . . . . . . . . . . . . . 10–5
10.4.3 Processing Flow . . . . . . . . . . . . . . . . . . . . . . 10–6
Chapter 11 • Card Action Analysis

11.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–2
11.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . 11–2
11.3 GENERATE APPLICATION CRYPTOGRAM (AC) Command . . . . . . . 11–2
11.4 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 11–3
11.4.1 Card Risk Management . . . . . . . . . . . . . . . . . . . 11–3
11.4.2 Card Response Decision . . . . . . . . . . . . . . . . . . . 11–4
11.4.2.1 Standard Response to GENERATE AC . . . . . . . . . . . 11–4
11.4.2.2 Response to GENERATE AC for Combined DDA/AC

Generation . . . . . . . . . . . . . . . . . . . . . . 11–5
11.5 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–6
Chapter 12 • Online Processing

12.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–2
12.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . 12–3
12.3 Online Request and Response Data . . . . . . . . . . . . . . . . . 12–3
vi
12.4 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–4
12.5 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–5
12.5.1 Online Request . . . . . . . . . . . . . . . . . . . . . . . 12–5
12.5.1.1 Combined DDA/AC Generation Processing . . . . . . . . . 12–5
12.5.1.2 Standard Online Processing . . . . . . . . . . . . . . . 12–5
12.5.2 Online Response . . . . . . . . . . . . . . . . . . . . . . 12–5
12.5.3 Issuer Authentication . . . . . . . . . . . . . . . . . . . . . 12–6
12.5.4 Processing Flow . . . . . . . . . . . . . . . . . . . . . . 12–7
Chapter 13 • Completion
13.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–3
13.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . 13–4
13.3 GENERATE Application Cryptogram (AC) Command . . . . . . . . . . 13–4
13.4 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–5
13.4.1 Terminal Determines Transaction Disposition . . . . . . . . . . . 13–5
13.4.1.1 Transaction Authorized Offline . . . . . . . . . . . . . . . 13–5
13.4.1.2 Online Authorization Completed Successfully . . . . . . . . . 13–6
13.4.1.3 Online Authorization Unable to Complete . . . . . . . . . . 13–6
13.4.2 Card Responds to Final GENERATE AC Command . . . . . . . . . 13–7
13.4.2.1 Online Authorization Completed . . . . . . . . . . . . . . 13–7
13.4.2.2 Online Authorization Unable to Complete . . . . . . . . . . 13–8
13.4.3 Terminal Completes Transaction . . . . . . . . . . . . . . . . 13–9
13.5 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–10
13.6 Prior Related Processing . . . . . . . . . . . . . . . . . . . . 13–11
31 Oct 2001
Draft 12/18/00 Visa Public vii
Chapter 14 • Issuer-to-Card Script Processing

14.1 Script-Related Keys . . . . . . . . . . . . . . . . . . . . . . . 14–3
14.1.1 Message Authentication Code Keys . . . . . . . . . . . . . . 14–3
14.1.2 Data Encipherment Keys . . . . . . . . . . . . . . . . . . . 14–3
14.2 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–4
14.3 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . 14–5
14.4 Online Response Data . . . . . . . . . . . . . . . . . . . . . . 14–5
14.5 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 14–6
14.6 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 14–8
14.6.1 Issuer Scripts . . . . . . . . . . . . . . . . . . . . . . . 14–8
14.6.2 Command Processing . . . . . . . . . . . . . . . . . . . . 14–8
14.6.3 Secure Messaging . . . . . . . . . . . . . . . . . . . . . 14–9
14.7 Processing Flow . . . . . . . . . . . . . . . . . . . . . . . . 14–10
Appendix A • Acronyms
Glossary
Index
viii
Figures
2–1: Sample Transaction Flow . . . . . . . . . . . . . . . . . . . 2–6

3–1: Application Selection . . . . . . . . . . . . . . . . . . . . . 3–6
4–1: Initiate Application Processing Flow . . . . . . . . . . . . . . . . 4–5
5–1: Read Application Data Processing Flow . . . . . . . . . . . . . . . 5–4
6–1: SDA Key Relationships . . . . . . . . . . . . . . . . . . . . 6–5
6–2: DDA Data—Key Relationships . . . . . . . . . . . . . . . . . . 6–6
6–3: Processing Flow for SDA. . . . . . . . . . . . . . . . . . . 6–10
6–4: Processing Flow for DDA. . . . . . . . . . . . . . . . . . . 6–15
7–1: Processing Restrictions . . . . . . . . . . . . . . . . . . . . 7–6
8–1: CVM List Processing Flow . . . . . . . . . . . . . . . . . . . 8–9
8–2: PIN Processing Flow (1 of 2) . . . . . . . . . . . . . . . . . 8–12
8–3: PIN Processing Flow (2 of 2) . . . . . . . . . . . . . . . . . 8–13
9–1: Terminal Risk Management Processing Flow (1 of 2) . . . . . . . . . . . 9–6
9–2: Terminal Risk Management Processing Flow (2 of 2) . . . . . . . . . . . 9–7
10–1: Terminal Action Analysis Flow . . . . . . . . . . . . . . . . . 10–6
11–1: Card Action Analysis . . . . . . . . . . . . . . . . . . . . 11–6
12–1: Online Processing Flow . . . . . . . . . . . . . . . . . . . 12–7
13–1: Completion . . . . . . . . . . . . . . . . . . . . . . . 13–10
14–1: Issuer-to-Card Script Processing . . . . . . . . . . . . . . . . 14–10
31 Oct 2001
Draft 12/18/00 Visa Public ix
Figures Visa Integrated Circuit Card
x
Draft 12/18/00
Visa Public 31 Oct 2001
Tables
2–1: Card Functional Requirements . . . . . . . . . . . . . . . . . . 2–7

2–2: Terminal Functional Requirements . . . . . . . . . . . . . . . . 2–9
2–3: Command Support Requirements . . . . . . . . . . . . . . . . 2–11
3–1: Application Selection—Card Data . . . . . . . . . . . . . . . . . 3–2
3–2: Application Selection—Terminal Data . . . . . . . . . . . . . . . 3–3
4–1: Initiate Application Processing—Card Data . . . . . . . . . . . . . . 4–2
4–2: Initiate Application Processing—Terminal Data . . . . . . . . . . . . . 4–3
5–1: Read Application Data—Previously Sent Card Data . . . . . . . . . . . 5–2
5–2: Read Application Data—Card Data . . . . . . . . . . . . . . . . 5–2
6–1: Offline Data Authentication Processing Priority . . . . . . . . . . . . . 6–7
6–2: Terminal Data Used in SDA . . . . . . . . . . . . . . . . . . . 6–8
6–3: Card Data Used in SDA . . . . . . . . . . . . . . . . . . . . 6–8
6–4: Terminal Data Used in DDA . . . . . . . . . . . . . . . . . 6–11
6–5: Card Data Used in DDA . . . . . . . . . . . . . . . . . . . 6–12
6–6: Card Data Used in Combined DDA/AC Generation . . . . . . . . . . 6–12
7–1: Processing Restrictions—Card Data . . . . . . . . . . . . . . . . 7–2
7–2: Processing Restrictions—Terminal Data . . . . . . . . . . . . . . . 7–3
8–1: CVM List Processing—Card Data . . . . . . . . . . . . . . . . . 8–3
8–2: Offline PIN Processing—Card Data . . . . . . . . . . . . . . . . 8–4
8–3: Offline Enciphered PIN—Card Data . . . . . . . . . . . . . . . . 8–5
8–4: CVM Processing—Terminal Data . . . . . . . . . . . . . . . . . 8–6
9–1: Terminal Risk Management—Card Data . . . . . . . . . . . . . . . 9–2
9–2: Terminal Risk Management—Terminal Data . . . . . . . . . . . . . 9–3
10–1: Review Offline Processing Results—Card Data . . . . . . . . . . . 10–2
10–2: Request Cryptogram Processing—Card Data . . . . . . . . . . . . 10–2
31 Oct 2001
Draft 12/18/00 Visa Public xi
Tables Visa Integrated Circuit Card
10–3: Review Offline Processing Results—Terminal Data . . . . . . . . . . 10–3

10–4: Request Cryptogram Processing—Terminal Data . . . . . . . . . . . 10–3
11–1: Card Action Analysis—Card Data . . . . . . . . . . . . . . . . 11–2
11–2: Card Response to GENERATE AC Command . . . . . . . . . . . . 11–4
12–1: Online Processing—Card Data . . . . . . . . . . . . . . . . . 12–2
12–2: Online Processing Issuer Authentication—Card Data . . . . . . . . . . 12–2
12–3: Online Processing—Terminal Data . . . . . . . . . . . . . . . . 12–3
12–4: Online Processing—Online Response Data . . . . . . . . . . . . . 12–3
13–1: GENERATE AC Response . . . . . . . . . . . . . . . . . . 13–3
13–2: Completion—Card Data (Partial List) . . . . . . . . . . . . . . . 13–4
13–3: Completion—Terminal Data . . . . . . . . . . . . . . . . . . 13–4
13–4: Authorization Response Code for Offline Action Taken . . . . . . . . . 13–7
14–1: Issuer-to-Card Script Processing—Card Data . . . . . . . . . . . . 14–4
14–2: Issuer-to-Card Script Processing—Terminal Data . . . . . . . . . . . 14–5
14–3: Issuer-to-Card Script Processing—Online Response Data . . . . . . . . 14–5
xii
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 impact 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 subheading
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.
31 Oct 2001
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 utilized. 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.
●
An Application Default Action bit has been added to allow issuers to
decline the transaction and block the application if the PIN Try Limit was
exceeded on a previous transaction.
NOTE: Cryptogram Version 14 is not currently supported in VisaNet
systems and Issuer’s 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.
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, though some steps
within the 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)
When a VSDC application is selected, the terminal requests that the card
indicate the data and functions supported 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 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), like SDA, validates that the
card data has not been fraudulently altered and additionally validates that
the card is genuine. DDA has two forms: Standard DDA and Combined
DDA/Generate AC. 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/AC Generation, 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 has 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 is 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 method of cardholder
verification. 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 other methods of cardholder verification, such as online PIN,
signature, or no cardholder verification required. Under certain conditions,
the terminal may use a default CVM as defined by Visa International
Operating Regulations.
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 Europay, MasterCard, and Visa (EMV) specifications.
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 set 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 an online request, and an Application Authentication
Cryptogram (AAC) for a decline.
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 having been 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. The card cannot override a
terminal decision to decline a transaction.
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
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.
2–4
Visa Integrated Circuit Card 2.1 Functional Overview
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 card counters and
indicators. If Issuer Authentication fails, subsequent transactions for the card
will be sent online for authorization until Issuer Authentication is successful.
The Issuer has the option to set up the card to decline the transaction if Issuer
Authentication fails.
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
process SELECT
List of Supported Command/Response
Application Selection
Applications READ RECORD
Mandatory Command/Response
process w/
optional Supported Functions
GET PROCESSING OPTIONS Initiate Application
steps & Pointers to
Command/Response Processing
Application Data
Optional Provide Application READ RECORD Read Application

process Records Commands/Responses Data
1 Offline Data
Generate Dynamic INTERNAL AUTHENTICATE Authentication
Cryptogram Command/Response
1 - If DDA SDA or DDA
2 - If Offline
Enciphered PIN
3 - Optional for
Offline PIN Processing
4 - If Offline PIN Restrictions
Generate Unpred.
Number GET CHALLENGE Command/Response2
3 Cardholder
PIN Try Counter GET DATA Command/Response Verification
Validate PIN VERIFY Command/Response4
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
Perform Final Check GENERATE APPLICATION

& Generate Final CRYPTOGRAM Completion
Issuer-to-Card Script Issuer-to-Card Script

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

VSDC cards must support the mandatory functions shown in Table 2–1.
Optional functions may be supported at the issuer’s discretion or may be
required by market, regional, or Visa rules. Support for conditional functions
is required if the associated condition is true.
Table 2–1: Card Functional Requirements (1 of 2)
Function Card Support
Application Selection Mandatory

● Directory Method Optional (EMV)
● Explicit Selection Method Mandatory (EMV)
Initiate Application Processing Mandatory (EMV)
Read Application Data Mandatory (EMV)
Offline Data Authentication Optional (EMV)

● SDA Optional (EMV) Conditional—If DDA supported (VIS)
● Standard DDA Optional (EMV) Conditional—If Combined DDA/AC Generation supported (VIS)
● Combined DDA/AC Generation Optional (EMV)
Processing Restrictions Mandatory (EMV)

● Application Version Number Mandatory (EMV)
●
Application Usage Control Optional (EMV)
● Effective Date Check Optional (EMV)
●
Expiration Date Check Mandatory (EMV)
Cardholder Verification Optional (EMV) Required (VIS)

● Individual CVMs Optional (EMV) Required (VIS)
31 Oct 2001
Table 2–1: Card Functional Requirements (2 of 2)
Function Card Support
Terminal Risk Management Optional (EMV) Mandatory (VIS)

● Terminal Exception File n/a (Card plays no role)
●
Merchant Force Online n/a (Card plays no role)
● Floor Limits n/a (Card plays no role)
● Transaction Log n/a (Card plays no role)
● Random Selection n/a (Card plays no role)
● Velocity Checking Optional (EMV) Not supported but not precluded (VIS)
● New Card Optional (VIS)
Terminal Action Analysis IACs optional (EMV); IACs required (VIS)
Card Action Analysis Mandatory (EMV)

● Online/offline decision Mandatory (EMV)
● Offline referrals Optional (EMV), Not supported (VIS)
● Card Risk Management Optional (EMV) Mandatory (VIS) Some Card Risk Management steps are
optional in VIS (refer to the Visa Integrated Circuit Card Specification,
Chapter 11, Card Action Analysis)
● Advice Messages Optional (EMV)
● Application Cryptogram Algorithm option provided (EMV)
Multiple algorithm options provided (VIS)
Online Processing
● Online Capability Mandatory (EMV)
● Issuer Authentication Optional (EMV)
Completion Mandatory (EMV)
Issuer-to-Card Script Processing Optional (EMV)

●
Secure Messaging Some form is mandatory if scripts supported (EMV)
Recommended form (VIS)
2–8
2.2.2 Terminal Functional Requirements

VSDC terminals are required to support the mandatory functions shown in
Table 2–2. 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.
Table 2–2: 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)
Read Application Data Mandatory (EMV)
Offline Data Authentication Conditional—If offline capable (EMV)

● SDA Conditional—If offline capable terminal (EMV) or if DDA supported (EMV)
● Standard DDA Optional (EMV) Conditional—If DDA/AC Generation supported (VIS)
(VIS recommends 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) with Operating Regulation exceptions (VIS)
Online PIN, signature, etc.)
31 Oct 2001
Table 2–2: 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
●
New Card Mandatory
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
Issuer-to-Card Script Processing Conditional—If online capable
Miscellaneous Functions
●
Cardholder amount validation Recommended (EMV)
● Voice Referrals Recommended
●
Card initiated referrals Not supported (VIS)
● Merchant forced acceptance Optional (EMV)
● Prompt for chip read Mandatory (EMV)
2–10
2.2.3 Command Support Requirements

Card and terminal support for the VSDC commands is shown in Table 2–3.
Table 2–3: Command Support Requirements (1 of 2)
Command Card Support Terminal Support
APPLICATION BLOCK Application blocking capability is Pass through from Issuer

optional. If supported, using mandatory (VIS)
APPLICATION BLOCK is
recommended (VIS)
APPLICATION UNBLOCK Application unblocking capability is Pass through from Issuer

optional. If supported, using mandatory (VIS)
APPLICATION UNBLOCK is
recommended (VIS)
CARD BLOCK Card blocking capability is Pass through from Issuer

recommended. CARD BLOCK mandatory (VIS)
command is one method (VIS)
EXTERNAL AUTHENTICATE Conditional—If Issuer Conditional—If online-capable

Authentication supported (EMV) (EMV)
GENERATE APPLICATION Mandatory (EMV) Mandatory (EMV)

CRYPTOGRAM (AC)
GET CHALLENGE Conditional—If Offline Enciphered Conditional—If Offline Enciphered

PIN supported (EMV) PIN supported (EMV)
GET DATA Optional (EMV) Conditional—If ATM or merchant

controlled device (EMV)
Mandatory (VIS)
GET PROCESSING OPTIONS Mandatory (EMV) Mandatory (EMV)
INTERNAL AUTHENTICATE Conditional—If DDA supported Conditional—If DDA supported

(EMV) (EMV)
PIN CHANGE/UNBLOCK Unblocking PIN—Conditional if Performed at special

Offline PIN supported. Method used issuer-controlled devices
may be PIN CHANGE/UNBLOCK
(VIS)
PIN Change—Optional, must be in
issuer controlled environment (VIS)
31 Oct 2001
Table 2–3: Command Support Requirements (2 of 2)
Command Card Support Terminal Support
PUT DATA Optional (VIS) Pass through from Issuer

mandatory (VIS)
READ RECORD Mandatory (EMV) Mandatory (EMV)
SELECT Mandatory (EMV) Mandatory (EMV)
UPDATE RECORD Optional (VIS) Pass through from Issuer

mandatory (VIS)
VERIFY Conditional—If Offline PIN Conditional—If Offline PIN

supported (EMV) supported (EMV)
2.3 Visa Low-Value Payment (VLP) Feature

The Visa Low-value Payment (VLP) feature of VSDC offers an optional source
of pre-authorized spending power that is reserved for rapid processing of
offline low-value payments.
2.3.1 Overview
Risk management features may differ from those supported for non-VLP
VSDC and are selected by the issuer. VLP supports a cumulative amount limit
and a per transaction amount 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.
The amount of spending power is reset to the spending limit at any online
capable VSDC terminal if an online authorization or status check transaction
is approved by the issuer and the card.
A reset without a financial transaction can also take place at a dedicated
online unattended device, which performs an online status check.
For details on VLP, refer to Appendix G of the Card Volume and Appendix D of
the Terminal Volume of this specification.
2–12
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.
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 briefly
described in Table 3–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 Elements Table.
Table 3–1: Application Selection—Card Data
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 contains information
about the application such as the name of the application, language preferred and
the priority of the application relative to other applications on the card.
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). The AID identifying the Visa
Debit Credit application is “A0000000031010”.
Directory Definition File (DDF) A DDF is a file that designates the structure of files beneath it.
Directory File A directory file is a file listing files contained within the directory. The terminal uses
a READ RECORD command to access directory files.
File Control Information (FCI) The FCI is information from the card about the application that is provided in
response to the SELECT command issued by the terminal.
Payment Systems Directory The Payment Systems Directory is a directory file containing entries for
applications that conform to Europay, MasterCard, and Visa (EMV) specifications.
Payment Systems Environment The PSE is a DDF named “1PAY.SYS.DDF01”. The directory file designating the
(PSE) structure of the files beneath the PSE is known as the Payment Systems
Directory.
Processing Options Data Object The PDOL is a list of tags and lengths for terminal data needed by the card. It is
List (PDOL) obtained from the card by the terminal using the SELECT command. The terminal
provides the data requested in the list to the card in the GET PROCESSING
OPTIONS command.
Short File Identifier (SFI) The SFI is a pointer to Elementary Files (EF)
3–2
Visa Integrated Circuit Card 3.2 Terminal Data
3.2 Terminal Data

The terminal data elements used in Application Selection are listed and
usage, refer to the Visa Integrated Circuit Card Terminal Specification,
Appendix A, Card and Issuer Data Elements Table.
Table 3–2: Application Selection—Terminal Data
Application Identifier (AID) The AID is composed of the Registered Application Provider Identifier (RID) and
the Proprietary Application Identifier Extension (PIX). The AID identifying the Visa
Debit Credit application is “A0000000031010”.
Application Selection Indicator Indicates whether the associated AID in the terminal must exactly match the AID
in the card including the length of the AID, or only up to the length of the AID in the
terminal. There is only one Application Selection Indicator per AID in the terminal
and its format is at the discretion of the terminal vendor.
List of supported applications The terminal shall maintain a list of application AIDs supported by the terminal.
3.3 Commands
SELECT
The terminal sends the SELECT command to the card to obtain information
from the card about an application supported by the card. This information
may be issuer preferences as to the priority in which the application is
selected, the name of the application, and the language in which information
is displayed to the cardholder.
In the card response to the SELECT command, response codes are used to
indicate processing results. The card’s response contains the Processing
Options Data Object List (PDOL), if present on the card. The PDOL is used
during Initiate Application Processing.
READ RECORD
The terminal sends the READ RECORD command to the card to read the
records in the PSE (if Directory Selection is supported) or other DDFs in the
List of AIDs Selection Method. The command includes the Short File
Identifier (SFI) of the file to be read and the record number of the record
within the file.
In response to the READ RECORD command, the card provides the requested
record to the terminal.
31 Oct 2001
3.4 Building the Candidate List

There are two approaches used by the terminal to build a list of mutually
supported applications.
●
Directory Selection Method is optional for cards and terminals, but if
supported by the terminal, it is attempted first. If the Directory Selection
Method is attempted and fails, the terminal uses the List of AIDs Method.
In the Directory Selection Method, the terminal reads a file from the card.
This file is a list of the applications supported by the card. The terminal
includes any applications listed on both the card list and the terminal list
on the candidate list.
● List of AIDs Selection Method is mandatory for cards and terminals. In
the List of AIDs Selection Method, the terminal issues a SELECT
command for each terminal-supported application in a list contained in
the terminal. If the card response indicates that the card also supports the
application, the terminal adds the application to the candidate list.
NOTE: Terminals may eliminate applications from the final candidate list
under conditions specified in Visa Operating Principles and
Regulations.
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 described in the following sections.
3.5.1 Terminal Makes Application Decision

A terminal that does not support cardholder selection or confirmation shall
issue a SELECT command to the highest priority application that 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’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 of
available applications, the terminal should issue a SELECT command for the
application with the next highest priority.
3–4
Visa Integrated Circuit Card 3.5 Identifying and Selecting the Application
3.5.2 Cardholder Makes Account Decision
3.5.2.1 Terminal Supports Cardholder Confirmation

A terminal that does not support cardholder selection from a list of displayed
applications, but supports cardholder confirmation of an application shall first
request cardholder confirmation for the highest priority application. 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.
blocked. 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.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 is given the same priority, the terminal may display them to the
cardholder in the order encountered or decide the priority. The cardholder
selects the application from the list and the terminal uses the SELECT
command to select the application.
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 applications.
If the cardholder does not select an application, the terminal terminates the
transaction.
31 Oct 2001
3.6 Flow
Figure 3–1: Application Selection
Card Terminal checks for Terminal

card applications
supported and builds
candidate list
T
Any mutually Terminal

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

Terminal issues
requested AID and “9000” SELECT SELECT command
(selection successful) or command with the identified
“6283” (application blocked)
application
or other SW1SW2
SELECT Successful Terminal removes application

SELECT N
response from list
“9000”?
Terminal proceeds to
B
Initiate Application
Processing
3–6
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 elements specified in the PDOL. If supported, the
PDOL was included in the SELECT 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 issues the GET

PROCESSING OPTIONS command to the card to signal that transaction
processing is beginning. When issuing this command, the terminal supplies
the card with any recognized data elements requested by the card in a
Processing Options Data Objects List (PDOL). The PDOL is a list of tags and
lengths of data elements, 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 that 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.
4.1 Card Data
4.2 Terminal Data
4.3 GET PROCESSING OPTIONS Command
4.4 Terminal Processing
4.5 Card Processing
4.7 Flow
4.8 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
Table 4–1: Initiate Application Processing—Card Data
Application File Locator (AFL) Indicates the file location and range of records that contain card data to be read
by the terminal for use in transaction processing.
Application Interchange Profile A list that indicates the capability of the card to support specific functions in the
(AIP) application (Static Data Authentication (SDA), Dynamic Data Authentication
(Standard DDA), Cardholder Verification, Issuer Authentication, and Combined
DDA/AC Generation.
File Control Information (FCI) The FCI is information from the card about the application that is provided in
response to the SELECT command issued by the terminal.
Geographic Indicator Visa proprietary data element indicating whether a card supports domestic
transactions, international transactions or both.
Issuer Country Code Visa proprietary data element indicating the issuer’s country code. Used in the
Geographic Restrictions check if this check is supported by the card. It may also
be used to determine which records from the card should be read by the terminal
based on whether a transaction is domestic or international.
Processing Options Data Object The PDOL is an optional list of tags and lengths for terminal data requested by the
List (PDOL) card. It is part of the FCI obtained from the card by the terminal using the SELECT
command. The terminal provides the data requested in the list to the card in the
GET PROCESSING OPTIONS command.
4–2
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, refer to the Visa Integrated Circuit Card Terminal
Specification, Appendix A, Card and Issuer Data Elements Table.
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.
4.3 GET PROCESSING OPTIONS Command

The GET PROCESSING OPTIONS command from the terminal signals the
card that transaction processing is beginning. The terminal also uses a list (if
present), called the Processing Options Data Objects List or PDOL, which was
provided by the card during Application Selection. The terminal includes the
data specified in the PDOL in the GET PROCESSING OPTIONS command.

To Initiate Application Processing, the terminal:
1. Extracts the Processing Options Data Objects List (if present) from the
File Control Information (FCI) provided by the card in response to the
SELECT command.
2. Sends the GET PROCESSING OPTIONS command to the card. Any data
elements requested in the PDOL and recognized by the terminal are
passed to the card in this command.
31 Oct 2001
4.5 Card Processing

Upon receiving the GET PROCESSING OPTIONS command, the card
performs the following actions:
1. Compares Terminal Country Code (if requested in the PDOL and returned
by the terminal) to Issuer Country Code to determine if the transaction is
domestic or international.
2. Determines the files and records that are to be read (they may differ for
domestic/international) and locates or builds the AFL. The terminal may
return a different AIP in the response to GET PROCESSING OPTIONS.
3. Performs Geographic Restrictions Check, if supported, to determine if
restrictions apply. If Geographic Restrictions are checked and apply, the
card responds to the GET PROCESSING OPTIONS command with an
error code “Conditions of use not satisfied”.
4. If geographic restrictions are not checked, or are checked and do not apply,
the card increments the Application Transaction Counter (ATC) by 1 and
responds to the GET PROCESSING OPTIONS command with the AIP
and AFL.

The terminal processes the response to the GET PROCESSING OPTIONS
command from the card as follows:
1. Receives the card response to the GET PROCESSING OPTIONS
command
2. If the card responds with “Conditions of use not satisfied”, the terminal:
a. Removes the application from the list of available applications
b. Returns to Application Selection
3. If the card responds with the AFL and the AIP, the terminal:
a. Proceeds to Read Application Data
4–4
Visa Integrated Circuit Card 4.7 Flow
4.7 Flow
Figure 4–1: Initiate Application Processing Flow
Card Terminal
Terminal reads PDOL

for terminal data to be
provided to the card
Terminal issues GET

Card Supports GET PROCESSING PROCESSING
Geographical Restrictions OPTIONS OPTIONS (includes
Check? command data requested by card
in PDOL)
Terminal Country Card responds

International Transactions to GET PROCESSING
Code = Issuer Country N Allowed?
Code? OPTIONS with “Conditions
of use not
satisfied”?
N Y
N GET PROCESSING
OPTIONS response N
Card responds to GET
PROCESSING
Domestic Transactions
N OPTIONS with
Allowed
“Conditions of use not
satisfied” Terminal
receives AFL and AIP
Y
Y
Y
Card determines which

Card returns AFL Terminal proceeds
records and files are to be
and AIP to Read Application
read by the terminal
Data
(Chapter 5)
Terminal eliminates this

application from the list
of available applications
and returns to
(Chapter 3)
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.

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 to be used in Offline Data
Authentication.
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).
5.1 Card Data
5.2 Terminal Data
5.3 READ RECORD Command
5.4 Processing
5.5 Flow
31 Oct 2001
Read Application Data Visa Integrated Circuit Card
5.1 Card Data

A detailed description of these card data elements and their usage is found in
the Visa Integrated Circuit Card Specification, Appendix A, Card and Issuer
Data Elements Table. The data element described in Table 5–1 was previously
sent from the card to the terminal in the response to GET PROCESSING
OPTIONS and is used during Read Application Data.
Table 5–1: Read Application Data—Previously Sent Card Data
Application File Locator (AFL) Indicates the file location and range of records containing card data to be read by
the terminal for use in transaction processing.
Each entry designates the first record and last record numbers to read from the
file and which records are to be used for authentication during Offline Data
Authentication.
The terminal uses the card data structures described in Table 5–2 during
Read Application Data.
Table 5–2: Read Application Data—Card Data
Application Elementary Files Card data files containing data used for application processing. An AEF consists
(AEF) of a sequence of records that are addressed by record number. The terminal
reads these records using the READ RECORD command. The READ RECORD
command contains a designation of the SFI and record number to be read, which
the terminal obtains from the AFL.
Short File Identifier (SFI) The SFI is a number used to uniquely identify application data files. It is listed in
the AFL and used by the terminal to identify the files to be read.
5–2
5.2 Terminal Data

No terminal data is used in the Read Application Data function.
5.3 READ RECORD Command

The terminal sends the card a READ RECORD command for each record to be
read. The command includes a Short File Identifier (SFI) that identifies the
file and a record number to identify the record within the file.
The card’s response to the READ RECORD command contains the requested
record.
5.4 Processing
The terminal uses the Application File Locator (AFL) from the card to
determine which records to read from the card.
For each AFL entry, the terminal uses the READ RECORD command to
request the first record designated to be read. When the requested record is
received from the card, the terminal saves the data objects from the record for
subsequent processing. If the AFL entry has specified that the record is
needed in authentication of static data during Offline Data Authentication,
the terminal puts the record data into the static data authentication input
list. The terminal continues reading records from the file until it reads the last
record designated to be read.
The terminal processes subsequent AFL entries in the same manner until all
AFL entries have been processed. At this point, the terminal proceeds to
Offline Data Authentication.
31 Oct 2001
Read Application Data Visa Integrated Circuit Card
5.5 Flow
Figure 5–1 shows how Read Application Data might be performed.
Figure 5–1: Read Application Data Processing Flow
Card Terminal
Terminal completes
Initiate Application
Processing
Terminal selects first

entry from AFL
Terminal requests
Card passes record READ RECORD
record using READ
to terminal. command
RECORD command
Requested record in
READ RECORD
response
Record
to be used for offline data
authentication?
Terminal
concatenates data
N into SDA input list
Record read
= last record number N
in AFL entry?
Terminal selects next

More AFL entries? Y
AFL entry
Offline Data
Authentication
(see Chapter 6)
5–4
Visa Integrated Circuit Card 5.6 Prior Related Processing

The terminal receives the AFL from the card for use in Read Application Data.

SDA and DDA use the static data authentication list built during Read
Application Data to validate the signed static data.
Other Functions
Other functions use the data read during Read Application Data for
processing.
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 altered since the card was personalized.
During DDA processing, the terminal authenticates the static card data and
also authenticates a signature, 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 performed using 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.
Support for SDA is mandatory for all offline capable terminals and support for
DDA is recommended for all offline capable terminals. Offline Data
Authentication support is optional for cards.
31 Oct 2001
Offline Data Authentication Visa Integrated Circuit Card

6.1 Keys and Certificates
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 Keys and Certificates
6.1 Keys and Certificates

The terminal performs Offline Data Authentication using RSA public key
technology to validate digital certificates and signatures from the card. RSA
public key technology uses private keys to generate enciphered values
(certificates or signatures) of data elements, which are later deciphered
(unlocked) for validation and data recovery.
6.1.1 Visa Certificate Authority (CA)

Offline Data Authentication requires a Certificate Authority (CA), which is a
highly secure cryptographic facility that signs the issuer’s Public Keys with
the Visa CA Private Keys to create an Issuer Public Key (PK) Certificate.
Terminals contain the CA’s public keys for every application supported by the
terminal. Visa is the CA for Visa Smart Debit and Visa Smart Credit (VSDC)
applications.
6.1.2 RSA Key Pairs
6.1.2.1 Visa Public/Private Keys

Visa, as a Certificate Authority (CA), generates up to six RSA public/private
key pairs. Visa assigns a unique Public Key Index (PKI) to each key pair. The
Visa CA Public Keys and their indexes are loaded into terminals by acquirers.
The Visa CA Private Keys are kept secret and used to sign Issuer Public Key
Certificates.
Terminals supporting SDA, DDA, or Offline Enciphered PIN contain the Visa
CA Public Keys with their corresponding Registered Application Identifier
(RID) and Certificate Authority Public Key Indexes (PKI) assigned by Visa.
6.1.2.2 Issuer Public/Private Keys

Both SDA and DDA require that the issuer generate an RSA public/private
key pair and obtain Issuer Public Key (PK) Certificates from the Visa CA. To
do this, the issuer sends its RSA public key to Visa CA, which generates and
returns one or more Issuer PK Certificates to the issuer. The Visa CA returns
an Issuer PK Certificate for each Visa CA Public Key that is longer than the
Issuer Public Key and expires after the expiration date of the Issuer PK
Certificate.
The Issuer PK Certificate contains the Issuer Public Key enciphered with the
Visa Private Key. All cards that support SDA or DDA must contain an Issuer
PK Certificate and related data including the index to identify the Visa Public
Key the terminal should use to decipher the certificate. The Issuer Private
Key is kept in a secure device by the issuer and used to sign cards’ static data
(for SDA) and ICC certificates (for DDA) prior to card personalization.
31 Oct 2001
6.1.2.3 ICC Public/Private Keys

DDA requires that the issuer generate a unique public/private key pair for
each card. The ICC Private Key is stored in a secure card location. The ICC
Public Key is enciphered with the Issuer Private Key to form an ICC Public
Key Certificate that is stored on the card.
The ICC public/private keys may also be used during Offline Enciphered PIN
processing. See Chapter 8, Cardholder Verification, for details.
6.1.3 SDA Key, Certificate, and Signature Relationships

The following SDA key-related data is personalized on the card:
● Certificate Authority Public Key Index (PKI) is used with the RID portion
of the AID to identify the Certification Authority Public Key used for
offline data authentication.
● The Issuer Public Key Certificate containing the Issuer Public Key signed
with the Visa CA Private Key
● The Issuer Public Key Exponent
● The Issuer Public Key Remainder, if required, contains the portion of the
Issuer Public Key which does not fit into the Issuer Public Key Certificate
● The Signed Static Application Data (SAD) which is a signature enciphered
with the Issuer Private Key and which contains a hash of important card
data
6–4
Visa Integrated Circuit Card 6.1 Keys and Certificates
The relationship between keys, certificates, and signatures for SDA is shown
in Figure 6–1.
Figure 6–1: SDA Key Relationships
Issuer Certification Authority (Visa) Acquirer
Initial Visa CA Visa CA Visa CA

Issuer Private Issuer Public
Setup Key - SK I Key - PK I
Private Key - Public Key - Public Key -
SKCA PKCA PKCA
Issuer PK Terminal
Certificate
(PKI signed w/
SKCA )
Personalized Signed Applic.

Issuer PK
Data (signed)
on each Certificate
with SKI)
Card
ICC Card
Application
READ RECORD response

containing
ICC Card
Transaction Issuer CA PK Index Terminal
Application
Issuer PK Certificate
Signed Applic. Data
- Uses PKCA to recover PKI
from Issuer PK Cert.
- Uses PKI to recover
Signed Applic. Data
6.1.4 DDA Key, Certificate, and Signature Relationships

The same issuer public/private key pair and Issuer PK Certificate are used for
DDA and SDA.
For DDA, a unique ICC public/private key pair is required for each card. The
ICC Public Key and a hash of static data is signed with the Issuer Private Key
to form an ICC Public Key (PK) Certificate, which is personalized on the card.
The ICC Private Key is also personalized in a secure card location.
31 Oct 2001
The relationship between the data and the cryptographic keys for DDA is
shown in Figure 6–2.
Figure 6–2: DDA Data—Key Relationships
Certificate Authority
Issuer Acquirer
(Visa)
Initial Issuer Private Issuer Public
Visa CA Visa CA Visa CA
Private Key - Public Key - Public Key -
Setup Key - SK I Key - PK I
SKCA PKCA PKCA
Terminal
Issuer PK
Certificate
(PKI signed w/
SKCA )
Personalized ICC Private ICC Public Issuer PK

on Key - SK ICC Key - PK ICC Certificate
each card
ICC Public
Key Cert
(PKICC signed
w/ SKI)
Card
READ RECORD response

Transaction with CA PK Index,
Card Issuer PK Certificate, Terminal
& ICC PK Certtificate
INTERNAL AUTHENTICATE*
Card or first GENERATE AC**
command - Uses PKCA to get PKI
from Issr PK Cert.
- Calculates Dynamic - Uses PKI to get PKICC
Signature using SK ICC from ICC PK Cert.
- Validates static data
hash in ICC PK Cert.
INTERNAL AUTHENTICATE* or
GENERATE AC** response Terminal
with Dynamic Signature
- Validates Dynamic
* INTERNAL AUTHENTICATE Signature using PK ICC
fcommand for Standard DDA
** GENERATE AC command for
Combined DDA/AC Generation
6–6
Visa Integrated Circuit Card 6.2 Determining Whether to Perform SDA or DDA
6.2 Determining Whether to Perform SDA or DDA

Only one method of Offline Data Authentication is performed during any
transaction with Combined DDA/AC Generation given highest priority,
Standard DDA next, and SDA next. Table 6–1 indicates the method of offline
data authentication to be performed based on card and terminal support.
Table 6–1: Offline Data Authentication Processing Priority
Card Application Terminal Supports

Interchange Profile Terminal Supports SDA, Standard DDA,
indicates card Terminal Supports SDA and Standard and Combined
support for: SDA DDA DDA/AC Generation
SDA SDA SDA SDA
SDA SDA Standard DDA Standard DDA

Standard DDA
SDA SDA Standard DDA Combined

DDA/AC Generation
Standard DDA
Combined DDA/AC
Generation
31 Oct 2001
6.3 Static Data Authentication (SDA)

When SDA is performed, the terminal validates important card data described
in Table 6–2 and Table 6–3 to assure that this card data has not been altered.
Table 6–2: Terminal Data Used in SDA
Certificate Authority (CA) Public The Payment System public keys stored in the terminal and used to recover the
Keys Issuer PK Certificate from the card, which has been signed, with the Certificate
Authority Private Key.
Certificate Authority (CA) Public Used with the RID to designate which Visa CA Public Key to use for offline data
Key Index (PKI) authentication.
Registered Application Identifier A portion of the Application Identifier that identifies the Payment System.
(RID)
Terminal Verification Results Status of processing functions as seen from the terminal perspective.
(TVR)
Table 6–3: Card Data Used in SDA
Certificate Authority Public Key Each Visa Public Key used for offline data authentication in SDA is identified by
Index (PKI) the Certificate Authority Public Key Index (PKI) in conjunction with the RID portion
of the AID.
Issuer Public Key Certificate The Issuer Public Key Certificate contains the Issuer Public Key signed with the
Visa CA Private Key.
Issuer Public Key Exponent The exponent used in the RSA algorithm to recover the PK Certificate.
Issuer Public Key Remainder If required, the Issuer Public Key Remainder contains the portion of the Issuer
Public Key, which does not fit into the Issuer Public Key Certificate.
SDA Failure Indicator An internal indicator set and saved by the card if SDA fails and the transaction is
declined offline.
Signed Static Application Data The SAD is a signature enciphered with the Issuer Private Key, which contains a
(SAD) hash of important card data.
6–8
Visa Integrated Circuit Card 6.3 Static Data Authentication (SDA)
6.3.1 SDA Processing

The card performs no processing during SDA. The following summarizes the
processing by the terminal.
1. Retrieval of the Certification Authority Public Key
The terminal uses the Certification Authority Public Key Index (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 uses the Visa CA Public Key to recover the Issuer Public Key
from the Issuer PK Certificate. The format of the Issuer PK Certificate is
validated.
3. Verification of the Signed Static Application Data
The terminal uses the Issuer Public Key to recover the Signed Static
Application Data that contains the hash of card data calculated at
personalization. The terminal calculates a hash of the actual data
elements. This hash is compared to the hash in the recovered data. If the
hashes are not equal, the data may have been altered and SDA has failed.
4. SDA Results
If all of steps above are executed successfully, SDA passes.
If SDA fails, the terminal sets indicators in the TVR to show SDA results
and to use in later processing to determine the disposition of the
transaction.
31 Oct 2001
Figure 6–3: Processing Flow for SDA
Card Terminal
Response to Read Record

Retrieve Visa CA Public
contains Visa CA Public READ RECORD
Key using RID and Public
Key Index, Issuer Public response Key Index
Key Certificate, and SAD
Recover Issuer Public Key

from Issuer PK Certificate
using Visa CA Public Key
Use Issuer Public Key to

recover a hash of static
application data from the
SAD
Calculate hash from Static

data used for signing and
compare to recovered hash
Set SDA failed in the TVR if

any of the above steps are
not successful
6–10
Visa Integrated Circuit Card 6.4 Dynamic Data Authentication (DDA)
6.4 Dynamic Data Authentication (DDA)

If offline DDA is to be performed, the terminal validates static data from the
card using the Issuer’s Public Key and the Visa CA Public Key in a process
similar to SDA. After validating the static data, the terminal requests a
dynamic signature from the card. This request uses the INTERNAL
AUTHENTICATE command for Standard DDA and the first GENERATE AC
command for Combined DDA/AC Generation.
The card signs the terminal challenge data and dynamic data from the card
with the ICC Private Key to generate a digital signature called the Signed
Dynamic Application Data. With Combined DDA/AC Generation, the signed
data includes the Application Cryptogram. The card sends this dynamic
signature to the terminal.
The terminal deciphers the signature from the card using the ICC Public Key,
which has been recovered from the ICC PK Certificate. Recovered data is
compared to actual data to determine whether DDA passes. Successful DDA
means that card data has not been altered and that the card is not counterfeit.
6.4.1 Data Elements for DDA Processing

The terminal uses the SDA terminal data and the additional data for DDA
described in Table 6–4.
Table 6–4: Terminal Data Used in DDA
Default Dynamic Data If the card does not provide a DDOL, the terminal uses a default DDOL containing
Authentication Data Object List the tag for the terminal unpredictable number.
(default DDOL)
Unpredictable Number An unpredictable, transaction-unique number generated by the terminal and sent
to the card in the INTERNAL AUTHENTICATE command.
31 Oct 2001
All of the SDA data except for the Signed Static Application Data is also used
for DDA. In addition, the data described in Table 6–5 is used for DDA.
Table 6–5: Card Data Used in DDA
DDA Failure Indicator An internal indicator set and saved by the card if Standard DDA fails and the
transaction is declined offline.
Dynamic Data Authentication List of tags for terminal data objects to be passed to the card in DDA processing.
Data Object List (DDOL)
ICC Dynamic Number A unique number generated by the card and validated by the terminal as part of
the dynamic signature in Combined DDA/AC Generation.
ICC Private Key Used by the card to generate a dynamic signature.
ICC Public Key Certificate The ICC Public Key Certificate contains the ICC Public Key signed with the Issuer
Private Key.
ICC Public Key Exponent The exponent used in the RSA algorithm to recover the ICC PK Certificate.
ICC Public Key Remainder If required, the ICC Public Key Remainder contains the portion of the ICC Public
Key that does not fit into the ICC Public Key Certificate.
All of the data elements used in Standard DDA data except for the DDOL are
also used for Combined DDA/AC Generation. In addition, the data described
in Table 6–6 is used.
Table 6–6: Card Data Used in Combined DDA/AC Generation
Application Cryptogram A 3DES cryptogram returned by the card in the GENERATE AC response. With
Combined DDA/AC Generation if an ARQC or TC is returned, it is validated as
part of the dynamic signature.
Cryptogram Information Data Information on the type of cryptogram provided by the card and validated by
terminal in Combined DDA/AC Generation.
6–12
6.4.2 Standard DDA Processing

This processing is performed by the terminal except for the card generation of
the dynamic signature. The following summarizes this processing.
1. Retrieval of the Certification Authority Public Key
The terminal uses the Certification Authority Public Key Index (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 uses the Visa CA Public Key to recover the Issuer Public Key
from the Issuer PK Certificate. The format of the Issuer PK Certificate is
validated.
Validation of the Certificate Serial Number, which is listed as optional in
Europay, MasterCard, and Visa (EMV) specifications, is not supported in
this version of the Visa Integrated Circuit Card Specification.
3. Retrieval of the ICC Public Key
The terminal uses the Issuer Public Key to decrypt the ICC PK Certificate
that contains the ICC Public Key and a hash of static application data.
The terminal validates the hash by comparing it to a hash of the actual
data. If the hashes are not equal, DDA fails.
4. Dynamic Signature Generation (Standard DDA only)
The terminal passes the card an INTERNAL AUTHENTICATE command
that includes dynamic challenge data.
Upon receiving the INTERNAL AUTHENTICATE command, the card
generates a dynamic signature by encrypting a hash of the terminal and
card dynamic data with the ICC Private Key. The card passes the
dynamic signature to the terminal.
5. Dynamic Signature Verification (Standard DDA only)
The terminal decrypts the dynamic signature using the ICC Public Key,
which was recovered from the ICC PK Certificate. If a terminal-generated
hash of the actual dynamic data does not match the recovered hash, DDA
fails.
31 Oct 2001
6.4.3 Combined DDA/AC Generation Processing

For Combined DDA/AC Generation, the terminal performs Standard DDA
Steps 1 through 3. The terminal requests the dynamic cryptogram using the
first GENERATE AC command. The INTERNAL AUTHENTICATE command
is not used. The requesting and validation of this cryptogram involves the
following steps:
1. Dynamic Signature Generation (Combined DDA/AC Generation only)
If the terminal is requesting an online cryptogram (ARQC) or offline
approval cryptogram (TC) during Terminal Action Analysis, the first
GENERATE AC command indicates that Combined DDA/AC Generation
is to be performed. If the card decides that the Application Cryptogram is
a TC or ARQC, the card signs the Application Cryptogram and related
data with the ICC Private Key and returns this dynamic signature in the
GENERATE AC response.
2. Dynamic Signature Verification (Combined DDA/AC Generation only)
During Card Action Analysis if the first GENERATE AC response
contains a TC or ARQC, the terminal deciphers the dynamic signature
using the ICC Public Key recovered in Step 3. If the signature is
successfully recovered, processing continues based upon the type of
cryptogram received. If the signature recovery fails, the transaction is
declined offline.
6–14
Figure 6–4: Processing Flow for DDA
Card Terminal
Retrieve Visa CA Public

Key using RID and CA
Public Key Index
Recover Issuer Public Key

from Issuer PK Certificate
using Visa CA Public Key
Recover hash and ICC

Public Key from ICC PK
Certificate using Issuer
Public Key
Calculate hash from Static

data used for signing and
compare to recovered hash
Standard DDA Only

Calculate dynamic INTERNAL Send INTERNAL
signature using ICC AUTHENTICATE AUTHENTICATE and
Private Key command dynamic data to card
INTERNAL AUTHENTICATE
response with
dynamic signature
Validate dynamic signature

using ICC Public Key
Set DDA results in the TVR

if DDA fails
31 Oct 2001

The terminal reads application data from the card. This data includes the
data required for the supported Offline Data Authentication methods. The
AFL and the Static Data Authentication Tag List designate the data to be
used to validate the static data hash in the Signed Static Application Data
during SDA and in the ICC PK Certificate during DDA.

Terminal Action Analysis
The terminal uses the Offline Data Authentication results and card and
terminal parameters to determine whether the transaction should be declined
offline, sent online for authorization, or approved offline. When Combined
DDA/AC Generation is to be performed and the transaction is to be sent online
or approved offline, the terminal sets the Combined DDA/AC Generation
indicator in the GENERATE AC command.
Card Action Analysis
SDA and Standard DDA
The card sets an indicator in the CVR if SDA failed on a previous transaction
and the transaction was declined offline. A similar CVR indicator is set if DDA
failed on a previous transaction and the transaction was declined offline.
If SDA or DDA failed and the transaction is to be declined offline, the SDA
Failure Indicator or DDA Failure Indicator is set.
If the GENERATE AC command received from the terminal indicates that
Combined DDA/AC Generation is to be performed, the card returns ARQC
and TC Application Cryptograms in a dynamic signature signed with the ICC
Private Key.
Online Processing
When the returned Application Cryptogram is in a dynamic signature, the
terminal deciphers the signature using the ICC Private Key. If the
decipherment is successful, the terminal continues processing based upon the
Application Cryptogram. If the decipherment fails, the transaction is declined
offline.
6–16
Visa Integrated Circuit Card 6.6 Subsequent Related Processing
Completion
After an online authorization, the card may reset the SDA Failure Indicator
and DDA Failure Indicator 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.
If Combined DDA/AC Generation failed and the Application Cryptogram
returned was an ARQC, a second GENERATE AC command requesting an
AAC is sent to the card. If Combined DDA/AC Generation failed and the
Application Cryptogram returned was a TC, the transaction is declined offline
with no second GENERATE AC requested.
31 Oct 2001
Processing Restrictions 7
The Processing Restrictions function is performed by the terminal using data

elements from the terminal and the card. The terminal shall support checks
on application versions, effective and expiration dates, and conditions at the
point of transaction.
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
Table 7–1: Processing Restrictions—Card Data
Application Version Number This data element (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 the value of 140
Application Usage Control AUC is an optional data element. This data element indicates any restrictions set
(AUC) forth by the issuer on the geographic usage and services permitted for the card
application. It is used in Application Usage Control checking by the terminal.
Issuer Country Code The Issuer Country Code is a Europay, MasterCard, and Visa (EMV) specification
data element indicating the country of the card issuance. It is used in Application
Usage Control checking by the terminal.
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 use of the application is no
longer permitted.
7–2
7.2 Terminal Data

The card data elements used in Processing Restrictions are listed and
usage, refer to the Visa Integrated Circuit Card Terminal Specification,
Table 7–2: Processing Restrictions—Terminal Data
Application Version Number This data element (terminal tag ‘9F09’) indicates the version of the application In
the terminal. Terminals complying with this specification should use the value of
140.
Terminal Capabilities Indicates the capabilities of the terminal in regard to card data input, verification of
the cardholder, and security. It is used in Application Usage Control checking by
the terminal.
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.
Transaction Date This is the local date (in the terminal) on which the transaction processing is
taking place. It is used in application effective and expiration date checks by the
terminal.
Transaction Type This data element indicates the type of financial transaction. It is used in
Application Usage Control checking by the terminal.
31 Oct 2001
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.
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. These checks are similar to service code checks performed for
magnetic stripe transactions and include checks for restrictions on the
following transactions:
●
Domestic
– Cash
– Goods
– Services
– Cashback
● International
– Cash
– Goods
– Services
– Cashback
● ATM
● Other than ATM
7.5 Application Effective Date

Application Effective Date checking ensures that the application is active by
validating that the card’s Application Effective Date if present is less than or
equal to the terminal’s local Transaction Date. If the effective date is greater
than the Transaction Date, the terminal indicates in the TVR that the
application is not yet effective.
Presence of the Application Effective Data is optional for the card. Application
Effective Data checking is mandatory for the terminal if the data element is
present in the card.
7–4
Visa Integrated Circuit Card 7.6 Application Expiration Date
7.6 Application Expiration Date

Application Expiration Date checking validates that the application has not
expired by ensuring that the card’s Application Expiration Date is greater
than or equal to the terminal’s local Transaction Date. If the Application
Expiration Date is less than the Transaction Date, the terminal indicates in
the TVR that the application has expired.
31 Oct 2001
Figure 7–1: Processing Restrictions
Card Application Terminal

Version Number for
card and terminal
present?
Y N
Application
Version Numbers Y
Identical?
Terminal sets ICC and

terminal have different
application versions bit to
“1” in TVR
Terminal sets
Application
Do any requested service not
Usage Control and
Y restrictions Y allowed for card
Issuer Country Code
apply? product bit to “1” in
present?
TVR
N
N
Application
Terminal sets application not yet
Effective Date < N effective bit to “1” in TVR
Current Date?
Application
Terminal sets expired aplication
Expiration Date > N bit to “1” in TVR
Current Date?
cardholder verification
7–6

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

During Terminal Action Analysis, the terminal checks the Issuer Action Codes
and Terminal Action Codes to see what action should be taken if application
versions differ, cards are not yet effective or expired, or the requested service
is not allowed for the card product.
31 Oct 2001
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. Offline PIN results are included in the online
authorization message and should be considered in the issuer’s authorization
decision.
The terminal uses rules in the card’s CVM List to select the CVM to be used.
The selection criteria in the CVM List may 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.
31 Oct 2001
Cardholder Verification Visa Integrated Circuit Card
This chapter is separated into the following sections:

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

The terminal uses the card data described in Table 8–1 and Table 8–2 for
CVM List processing. A detailed description of these card data elements and
their usage is in the Visa Integrated Circuit Card Specification, Appendix A,
Table 8–1: CVM List Processing—Card Data
Application Interchange Profile Contains an indicator showing whether the card supports cardholder verification.
(AIP) This indicator must be set to “1”.
Cardholder Verification Method A prioritized list of methods of cardholder verification for the card application. A
(CVM) List card may contain multiple CVM Lists for use in different circumstances such as
international and domestic transactions. A CVM List contains the following:
● Amount X—An amount that may be used in CVM usage conditions
● Amount Y—A second amount that may be used in CVM usage conditions
● CVM entries—The CVM List may contain more than one entry, with each entry
containing the following subfields:
Subfield Description
CVM Code Designates the action to take if the CVM fails. Choices are to
process the next CVM entry or to fail CVM processing.
CVM Type The type of CVM to perform, for example, offline PIN.
CVM Conditions when this CVM entry should be used, for example,
Conditions if the terminal supports the CVM Type (offline PIN).
Refer to the Visa Integrated Circuit Card Specification, Chapter 8, Cardholder
Verification, for an example showing how issuers might define a CVM List.
31 Oct 2001
Table 8–2: Offline PIN Processing—Card Data
Application Default Action A data element used by the card to determine what action, if any, to take if offline
(ADA) PIN tries are exceeded.
Card Verification Results (CVR) Contains indicators, which the card sets for the following conditions:
● Offline PIN verification performed
● Offline PIN verification failed
● PIN Try Limit exceeded
● Application blocked because PIN Try Limit exceeded
PIN Try Counter Number of offline PIN tries remaining. The card decrements the PIN Try Counter
each time a cardholder-entered offline PIN fails verification. The card resets the
PIN Try Counter to the PIN Try Limit when the cardholder-entered PIN matches
the Reference PIN stored in the card or when a script command to reset the
counter is successfully processed. The terminal may request the PIN Try Counter
from the card prior to PIN entry so the terminal may determine whether the PIN
tries have already been exceeded and notify the cardholder if only one PIN try
remains.
PIN Try Limit Issuer-specified maximum number of consecutive incorrect PIN tries allowed for a
single application.
Reference PIN The cardholder PIN, which is stored in a secure location on the card.
8–4
Support for Offline Enciphered PIN requires card-level RSA public/private

key data. The issuer may either generate an ICC PIN Encipherment
public/private key pair to use solely for PIN encipherment or, if the card
supports DDA, use the same ICC public/private key pair used for DDA. The
card shall contain the data elements described in Table 8–3 for whichever key
pair is used.
Table 8–3: Offline Enciphered PIN—Card Data
Certificate Authority Public Key With the RID, designates the Visa CA Public Key to use to recover the Issuer PK
Index (PKI) Certificate.
ICC PIN Encipherment or ICC Used to decipher the enciphered PIN after it is received at the card. Stored in a
Private Key secret location on the card.
ICC PIN Encipherment or ICC Encrypted with the Issuer Private Key. Contains the card’s public key to be used in
Public Key (PK) Certificate PIN encipherment.
ICC PIN Encipherment or ICC Used in the algorithm that deciphers the enciphered PIN.
Public Key Exponent
ICC PIN Encipherment or ICC Contains the portion, if necessary, of the public key that does not fit into the public
Public Key Remainder key certificate.
Issuer Public Key Data Used to decipher the ICC PIN Encipherment or ICC PK Certificate. This is the
same certificate and other Issuer Public Key data used for DDA and SDA (see
Chapter 6, Offline Data Authentication).
Registered Application Provider Used by the terminal with the Certificate Authority Public Key Index to identify the
Identifier (RID) Visa CA Public Key to be used to recover the Issuer PK Certificate.
31 Oct 2001
8.2 Terminal Data

The terminal data described in Table 8–4 is used during CVM processing. A
detailed description of these data elements and their usage is in the Visa
Integrated Circuit Card Terminal Specification, Appendix A, Card and Issuer
Data Elements Table.
Table 8–4: CVM Processing—Terminal Data
Enciphered Personal Transaction PIN enciphered at the PIN pad for online verification or for offline
Identification Number (PIN) verification.
Data
Personal Identification Number Secret key used by the PIN pad to encipher the entered offline PIN and by the
(PIN) Pad Secret Key card reader to decipher the enciphered PIN. This key is required when the PIN
pad and card reader are not integrated into a single tamper-evident device. This
key is different from the key used for Offline Enciphered PIN.
Terminal Capabilities Indicates the CVMs 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
● 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 Personal Contains data entered by the cardholder for PIN verification.
Identification Number (PIN)
Visa CA Public Keys Must be present if the terminal supports Offline Enciphered PIN.
8–6
Visa Integrated Circuit Card 8.3 Commands
8.3 Commands
The following commands are used for offline PIN processing:
GET DATA
Used by the terminal 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.
The GET DATA command contains the tag of the PIN Try Counter.
The GET DATA response contains the PIN Try Counter. If the PIN Try
Counter is in a proprietary data file, the card returns an error response to
GET DATA and the terminal bypasses the checking of the PIN Try Counter
and continues with Offline PIN processing.
GET CHALLENGE
Used by the terminal to obtain an unpredictable number from the card for use
in Offline Enciphered PIN. The card and terminal support the GET
CHALLENGE command if they support Offline Enciphered PIN.
The GET CHALLENGE response contains a card-generated unpredictable
number.
VERIFY
Used for Offline Enciphered PIN and Offline Plaintext PIN.
The VERIFY command contains the cardholder-entered PIN and initiates the
card comparison of this PIN with the Reference PIN stored on the card.
The card response indicates one of the following conditions:
● The PINs match
●
The PINs do not match and the number of PIN tries remaining is “n”. If
“n” is equal to “0”, PIN tries have been exceeded on the current
transaction
●
The PIN tries were exceeded on a previous transaction
The card and terminal support the VERIFY command if they support Offline
PIN processing.
31 Oct 2001
8.4 Processing
Cardholder Verification processing is divided into two parts: the processing of
the card’s CVM List and the execution of the CVMs specified in the CVM List.
8.4.1 CVM List Processing

The card has no role in CVM List processing beyond providing the CVM List
and other required data to the terminal.
The terminal performs the following steps:
1. Determines whether to perform Cardholder Verification—If the
card supports Cardholder Verification (as indicated in the AIP and if the
card provided a CVM List during Read Application Data, the terminal
continues with Cardholder Verification. If not, the terminal shall perform
the Visa-specified method of cardholder verification for the terminal. If
none is specified, the terminal proceeds to Terminal Risk Management.
2. Processes the CVM List entries—Starting with the first entry in the
CVM List, the terminal performs the following actions:
a. Checks whether the CVM Condition is satisfied. If the condition is not
satisfied, the terminal proceeds to the next CVM List entry.
b. If the CVM is not recognized or is not supported, the terminal sets
Unrecognized CVM to “1” in the TVR. The CVM is considered not
successful.
c. Performs the CVM specified.
d. If the CVM is not successful (for example, Offline PIN verification
failure), the terminal proceeds with the action specified in the CVM
Code in the CVM entry. If CVM Code is “proceed to next CVM,” the
terminal processes the next CVM List entry. If it is “fail CVM,” the
terminal sets the Cardholder Verification Not Successful flag to “1” in
the TVR and proceeds to Terminal Risk Management.
e. If the CVM is successful, the terminal proceeds to Terminal Risk
Management.
3. If the terminal reaches the end of the CVM List without a
successful CVM, CVM processing fails—The terminal sets the
Cardholder Verification Not Successful flag in the TVR to “1” and proceeds
to Terminal Risk Management.
8–8
Visa Integrated Circuit Card 8.4 Processing
Figure 8–1: CVM List Processing Flow
Card Terminal C
Terminal uses default

Card supports CVM according to
cardholder N Visa Operating Y CVM = No CVM
verification? Regulations Required?
Card
Terminal sets chip
provided CVM N D N
data missing in TVR
List?
Y
A
Terminal selects first Y CVM = Fail

CVM in CVM List CVM?
CVM
Code = go to N
next CVM?
B N
CVM List CVM is signature.

Y
condition N Terminal prints
satisfied? receipt w/ signature
line
Y
Any more CVM N
entries?
Terminal
recognizes &
supports Y
CVM?
Terminal selects next

N CVM in CVM List
Terminal sets
Y unrecognized CVM
code in TVR B
Terminal sets
“cardholder
A
verification not
successful” in TVR
Perform PIN
Processing
CVM = PIN? Y (Figure 8-2)
D Terminal Risk
Management
N
31 Oct 2001
8.4.2 CVM Processing
8.4.2.1 Offline Plaintext PIN

In Offline PIN processing, the card checks a Transaction PIN entered by the
cardholder against a Reference PIN stored in the card. Unlike Online PIN, the
Offline PIN is not included in the online authorization message. The Offline
PIN results are included in the online authorization message, if the
transaction is processed online. With Offline Plaintext PIN, the terminal may
issue a GET DATA command to the card requesting the PIN Try Counter. If
the card does not support transmitting the PIN Try Counter, the terminal
proceeds to PIN entry. If the PIN Try Counter returned is zero (no more PIN
tries left), Offline PIN processing fails. If the PIN Try Counter returned is one,
the terminal displays “Last PIN Try”.
If there are PIN tries remaining, the terminal requests the cardholder to enter
a PIN at the PIN pad. If the PIN pad and card reader are not integrated into a
single tamper-evident device, the PIN is enciphered with the PIN Pad Secret
Key and deciphered by the card reader. The cardholder-entered Transaction
PIN is passed in the clear from the card reader to the card using the VERIFY
command.
The card compares the Transaction PIN to the Reference PIN stored on the
card.
● If they match, the card returns an indicator that the Offline PIN has been
verified, and cardholder verification is complete.
● If they do not match, the card decrements the PIN Try Counter and
returns an indicator of the number of PIN tries remaining.
– If no PIN tries remain, Offline PIN fails.
– If PIN tries remain, the terminal requests that the cardholder enter
the PIN again and repeats the verification process.
8.4.2.2 Offline Enciphered PIN

Offline Enciphered PIN processing works the same as Offline Plaintext PIN
processing except that the cardholder-entered Transaction PIN is enciphered
at the PIN pad or terminal and remains enciphered until the card receives it.
To encipher the PIN, the terminal issues a GET CHALLENGE command to
the card. The card returns an unpredictable number, which the terminal uses
in an RSA algorithm to encipher the PIN. The enciphered PIN is included in
the VERIFY command to the card.
The card recovers the plaintext PIN from the enciphered PIN using a secret
RSA key stored on the card. Verification of the deciphered PIN is the same as
with Offline Plaintext PIN processing.
8–10
In support of this process, the issuer may either generate a card-unique ICC
PIN Encipherment key pair or may use the same ICC key pair used for DDA.
8.4.2.3 Online PIN

With Online PIN processing, the PIN is enciphered after entry and is included
in the online authorization message for verification by the issuer’s online
system.
Online PIN processing follows current procedures, which are outside the scope
of this document.
8.4.2.4 Signature
When signature is the CVM, the terminal prints a receipt with a line for the
cardholder to sign.
8.4.2.5 No CVM Required

When the CVM is “No CVM Required”, CVM processing is considered to be
successful.
8.4.2.6 Fail CVM

When the CVM is “Fail CVM”, CVM processing is considered to have failed.
31 Oct 2001
The following flow gives an overview of the steps in PIN processing.
Figure 8–2: PIN Processing Flow (1 of 2)
Card Terminal
Perform PIN
Processing
CVM is online or
offline PIN
Perform CVM
Is PIN PAD Code action
N
operable? (see A in
Figure 8-1)
Type of PIN?
Offline or
Online PIN?
Online
Offline PIN PIN Offline
PIN
Card allows GET GET Issue GET DATA

DATA of PIN Try DATA command requesting
PIN Try Counter Offline PIN
Counter? command Processing
(optional step)
Online
Y PIN
N return
from A on
next page)
Response to GET
Y DATA is “Not
Supported”
PIN Try
Get Data
Counter returned N Prompt for PIN Entry
response
and = 0?
Response to GET Encipher PIN and
DATA is PIN Try include in
Y authorization request
Counter
Perform CVM PIN entered?

Code action
(see A in Terminal proceeds to
Figure 8-1) Terminal Risk
N Management
(Chapter 9)
Perform CVM
Code action
(see A in
Figure 8-1)
8–12
Figure 8–3: PIN Processing Flow (2 of 2)
Card Terminal
Offline PIN
Processing
GET Offline
Card generates Y
CHALLENGE Enciphered
unpredictable number
command PIN?
Encipher PIN using

GET CHALLENGE unpred. number &
N
response ICC PIN
(Plaintext
w/ unpred. number Encipherment (or
PIN)
ICC) Public Key
PIN Try VERIFY

Issue VERIFY
Enciphered PIN? N Limit Already command
command with PIN
Exceeded? w/ PIN
Y
Decipher PIN using
ICC PIN
N
Encipherment (or
ICC) Private Key VERIFY
successful?
B N
Entered
Decrement PIN Try Y
N PIN = Reference
Counter by 1.
PIN? PIN Try Limit
Exeeded?
Y
N
PIN Try Limit
Exceeded? Reset PIN Try VERIFY Return to
Counter to PIN Try response PIN Prompt
Limit Figure 8-2
Y Y A Y
Set VERIFY return
code to Fail with no
retries remaining
ADA Set VERIFY return
N code to Successful
“If PIN Try Limit
exceeded, block Completion Perform
applic” = 1? CVM Code
action
Y Set VERIFY return Return VERIFY

code to Fail with command response
N retries remaining to terminal Terminal proceeds to
Card blocks
Terminal Risk
application
Management
(Chapter 9)
31 Oct 2001

The Application Interchange Profile (AIP), which indicates whether the card
supports cardholder verification, is retrieved from the card.
The terminal reads the CVM List and other data used in CVM processing
from the card.

The terminal uses cardholder verification results and card and terminal
parameters called IACs and TACs to determine whether the transaction
should be declined offline, sent online, or approved offline.
The card uses cardholder verification results and parameters in Application
Default Action to determine whether to decline the transaction or go online for
authorization when the PIN Try Limit is exceeded.
Online Processing
CVM results including Offline PIN verification results are included in the
authorization request and should be considered in the Issuer’s authorization
decision. The Offline PIN is not included in the online authorization message.
Completion
After a failed attempt to go online for an authorization, the card uses
cardholder verification results and parameters in Application Default Action
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 and to change the Reference PIN.
The APPLICATION UNBLOCK command can be used to unblock an
application that was blocked during CVM processing.
8–14
Terminal Risk Management 9
Terminal Risk Management provides issuer authorization for higher-value

transactions and ensures that chip-read transactions 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.
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 Limit Checking
9.7 Random Transaction Selection
9.8 Terminal Velocity Checking
9.9 New Card Checking
31 Oct 2001
Terminal Risk Management Visa Integrated Circuit Card
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 Primary Account Valid cardholder account number used in terminal exception file checking.
Number (PAN)
Application Transaction Counter A count of the number of transactions processed by the card since
(ATC) personalization. It is used in terminal velocity checking.
Last Online ATC Register The ATC value of the last transaction that went online. If terminal velocity checking
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.
9–2
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
their usage, refer to the Visa Integrated Circuit Card Terminal Specification,
Table 9–2: Terminal Risk Management—Terminal Data
Amount, Authorized This numeric data element stores the amount (excluding adjustments) for the
current transaction. It is used in floor limit checking.
Maximum Target Percentage to Value used for random selection of transactions for online processing.
be used for Biased Random
Selection
Target Percentage to be used Value used for random selection of transactions for online processing.
for Random Selection
Terminal Floor Limit This data element (tag ‘9F1B’) indicates the floor limit in the terminal associated
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 for random selection of transactions for online processing.
Random selection
Transaction Log To prevent split sales, 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 functions performed by the terminal. This data element is not
(TSI) provided in the online authorization and clearing messages but is used by the
terminal to indicate that terminal risk management was performed.
31 Oct 2001
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
previously read by the terminal, from the card.
9.4 Terminal Exception File

If a terminal exception file is present, the terminal checks whether the
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 Terminal Verification Results
(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 Limit Checking

Floor limit checking is performed so that transactions of 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 contains a transaction log, the terminal checks whether the
amounts from a previous transaction from the same card combined with the
current amount put the transaction over the floor limit.
9.7 Random Transaction Selection

Terminals capable of supporting both offline and online transactions shall
randomly select transactions for online processing.
The terminal indicates in the TVR if a transaction is randomly selected.
Examples of this processing are provided in the Visa Integrated Circuit Card
Terminal Specification, Chapter 9, Terminal Risk Management.
9–4
Visa Integrated Circuit Card 9.8 Terminal Velocity Checking
9.8 Terminal Velocity Checking

Velocity checking permits issuers to request online processing after a pre-
specified number of consecutive offline transactions. Offline-capable terminals
shall support Terminal Velocity Checking. Issuers may elect not to support
velocity checking by the terminal.
The terminal shall perform Terminal Velocity Checking if both the Lower
Consecutive Offline Limit (tag “9F14”) and Upper Consecutive Offline Limit
(tag “9F23”) are provided by the card in Read Application Data processing. 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.
● 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: The card may also perform similar velocity checks during Card Action
Analysis. Velocity checking by the card does not result in the setting of
the TVR bits.
9.9 New Card Checking

In new card checking by the terminal, if the Upper and Lower Consecutive
Offline Limits are present, the terminal checks the Last Online ATC Register
if provided by the card. 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: The card may also perform a similar new card check during Card
Action Analysis
31 Oct 2001
Figure 9–1: Terminal Risk Management Processing Flow (1 of 2)
Card Terminal
Transaction
Terminal exception
log present
file present?
in terminal?
Y Y
Log Entry Amount,

Card appears on N
Present that authorized + amount in
N Y
exception file? matches current log > terminal
transaction? floor limit?
Y N N Y
Terminal sets card appears Terminal sets transaction

Transaction amount >
on terminal exception file bit Y exceeds floor limit bit to “1”
terminal floor limit?
to “1” in TVR in TVR
N N
Merchant
Terminal Terminal sets transaction
elected to force
randomly selects selected randomly for
transaction Y
transaction for online online processsing bit
online?
processing? to “1” in TVR
Y
N
Terminal sets merchant
forced transaction online bit N
to “1” in TVR B
9–6
Visa Integrated Circuit Card 9.9 New Card Checking
Figure 9–2: Terminal Risk Management Processing Flow (2 of 2)
Card B Terminal
Lower and Upper

Consecutive Offline Limits
read by terminal?
Card responds to GET GET DATA

Terminal issues GET
command
DATA DATA to obtain ATC
command with ATC and GET DATA and Last Online ATC
Last Online ATC Register response 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 minus Exceeded bits to “1” in TVR
Last Online ATC Register
> Lower Consecutive
Offline Limit?
Terminal sets Lower

Consecutive Offline Limit N
Exceeded bit to “1”
in TVR
ATC
minus Last Online
ATC Register > Upper N
Consecutive Offline
Limit
Y
Terminal sets Upper
Exceeded bit to “1”
in TVR
Last Terminal proceeds to

Online ATC Register N Terminal Action Analysis
=0 (Chapter 10)
Terminal sets New Card

bit in TVR
31 Oct 2001

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

Based on card and terminal settings, the terminal determines what action to
take if:
● The card was on terminal exception file
● The merchant forced the transaction online
● The floor limit is exceeded
● The transaction is randomly selected for online processing
● Velocity checking amounts or counters are exceeded
● New card
9–8
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 by the terminal in the Terminal Verification
Results, 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.
A decision for an offline approval or request for online processing made during
Terminal Action Analysis is not final. As a result of Card Action Analysis (see
Chapter 11, Card Action Analysis), the card may override the terminal’s
decision. Decisions to decline offline may not be overridden.
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. The Visa Integrated
Circuit Card Specification, Appendix A, Card and Issuer Data Elements
Table, contains detailed descriptions of these elements and their usage.
Table 10–1: Review Offline Processing Results—Card Data
Issuer Action Codes (IACs) The IACs are three data elements called IAC Denial, IAC Online, and IAC Default.
Each IAC consists of a series of bits, which correspond to the bits in the Terminal
Verification Results (TVR).
● IAC Denial bits set to “1” reflect the TVR conditions for which the transaction is
to be declined offline
● IAC Online bits set to “1” represent online authorization conditions
● IAC Default bits set to “1” are the conditions for an offline decline if online
processing is not available
Similar codes called Terminal Action Codes (TACs) are defined in the terminal.
The card data element shown in Table 10–2 is used in cryptogram processing.
Table 10–2: Request Cryptogram Processing—Card Data
Card Risk Management Data The CDOL1 contains the tags and lengths of the terminal data objects that are
Object List 1 (CDOL1) needed by the card to generate the first application cryptogram and for other
processing.
10–2
10.2 Terminal Data

The Visa Integrated Circuit Card Terminal Specification, Appendix A, Card
and Issuer Data Elements Table, contains detailed descriptions of these
elements and their usage.
The terminal data elements described in Table 10–3 are used to review offline
processing results.
Table 10–3: Review Offline Processing Results—Terminal Data
Terminal Action Codes (TACs) The TACs are three data elements called TAC Denial, TAC Online, and TAC
Default. Like the IACs, each TAC consists of a series of bits, which correspond to
the bits in the Terminal Verification Results (TVR).
● TAC Denial bits set to “1” reflect the TVR conditions for which the transaction is
to be declined offline
● TAC Online “1”bits represent online authorization conditions
● TAC Default “1” bits are the conditions for an offline decline if online processing
is not available
The required TAC settings are defined by Visa in the Visa Integrated Circuit Card
Terminal Specification, Version 1.4.0, Chapter 10.
Terminal Verification Results The TVR is a series of bits, which are set during transaction processing to
(TVR) represent offline processing results.
The terminal data elements described in Table 10–4 are used in cryptogram
processing.
Table 10–4: Request Cryptogram Processing—Terminal Data
Terminal Data Elements The terminal data elements specified in the CDOL1 from the card are included in
the GENERATE APPLICATION CRYPTOGRAM (AC) command.
31 Oct 2001

The terminal sends a GENERATE AC command to the card to request an
application cryptogram. The terminal also indicates in this command if
Combined DDA/AC Generation is to be performed.
The command designates one of the following types of application
cryptograms:
● Transaction Certificate (TC)—For an approval
● Application Authentication Cryptogram (AAC)—For a decline
● Authorization Request Cryptogram (ARQC)—To go online
The command also includes the terminal data objects requested by the card in
the CDOL1.
When the card receives the GENERATE AC command, it proceeds to Card
Action Analysis. The command response is not returned during Terminal
Action Analysis.
10.4 Processing
Terminal Action Analysis processing has two steps:
● The review of offline processing results
● The request for an Application Cryptogram
10.4.1 Review Offline Processing Results

The terminal reviews the results of offline processing to determine whether
the transaction should go online, be approved offline, or be declined offline.
This process uses issuer-defined criteria from the card called IACs and
Visa-defined criteria in the terminal called TACs. The Visa Integrated Circuit
Card Terminal Specification, Chapter 10, Terminal Action Analysis, contains
an example of how IACs and TACs are used with the Terminal Verification
Results (TVR) to determine transaction disposition.
10–4
10.4.2 Request Application Cryptogram

The second phase of Terminal Action Analysis involves requesting an
Application Cryptogram from the card. The outcome from the Review Offline
Processing step determines the type of cryptogram to request:
● Approve offline—TC (Transaction Certificate)
● Go online for authorization—ARQC (Authorization Request Cryptogram)
●
Decline offline—AAC (Application Authentication Cryptogram)
The terminal also indicates in this command if Combined DDA/AC Generation
is to be performed.
31 Oct 2001
10.4.3 Processing Flow

Figure 10–1 shows how Terminal Action Analysis might be performed.
Figure 10–1: Terminal Action Analysis Flow
Card Terminal
Any transaction
conditions which card
or terminal have
set to Decline?
Any Y
transaction
Online capable conditions that the card
N Y
terminal? or terminal have set to
Decline if no
online?
Any
transaction N
conditions which card
N
or terminal have
set for Online
Auth?
Cryptogram type = Cryptogram type = Cryptogram type =

ARQC TC AAC
(Send Online) (Approve) (Decline)
Proceed to Card GENERATE AC

Action Analysis command Request cryptogram
(See Chapter 11) with CDOL1 data from card
10–6

The terminal reads application data from the card. This data includes the
CDOL1 and the IACs.
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. These bit settings are used with the IACs and TACs during
Terminal Action Analysis to determine transaction disposition.

During Card Action Analysis, the card performs additional risk management
to determine whether to override the terminal’s Terminal Action Analysis
decision to approve offline or send online.
31 Oct 2001
Card Action Analysis 11
Card Action Analysis allows issuers to perform velocity checking and other
risk management that is internal to the card. Visa proprietary card risk
management features described in this section include checking:
●
Activity on previous transactions
● New card
●
Velocity counters
11.1 Card Data
11.2 Terminal Data
11.4 Processing
11.5 Flow
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, Card and
Issuer Data Elements Table.
Table 11–1: Card Action Analysis—Card Data
Application Cryptogram A cryptogram returned by the card in the response to the GENERATE
APPLICATION CRYPTOGRAM (AC) command.
● An Application Authentication Cryptogram returned for declines is known as an
AAC
● A Transaction Certificate returned for approvals is known as a TC
● An Authorization Request Cryptogram returned when online processing is
requested is known as an ARQC
Data Requested in Card Risk The terminal provides the data requested by the card in the CDOL1. Refer to the
Management Data Object List Visa Integrated Circuit Card Specification, Appendix E, Cryptogram Versions
(CDOL1) Supported, for a list of data required.
11.2 Terminal Data

No terminal data is used during Card Action Analysis.

The GENERATE APPLICATION CRYPTOGRAM (AC) command is used by
the terminal to request that the card provide a cryptogram indicating the
card’s authorization response. The terminal also indicates in this command
whether Combined DDA/AC Generation is to be performed.
11–2
11.4 Processing
At the end of Terminal Action Analysis, the terminal issues the GENERATE
AC command to the card to request an application cryptogram and to provide
data requested by the card in the CDOL1. This processing is described in
Chapter 10, Terminal Action Analysis.
The GENERATE AC command, which the card receives from the terminal,
contains the Cryptogram Type, which the terminal is requesting. This
Cryptogram Type indicates the terminal’s transaction decision (approve
offline, decline offline, send online).
The GENERATE AC command received from the terminal also indicates if
Combined DDA/AC Generation is to be performed.
11.4.1 Card Risk Management

The card performs the following Card Risk Management checks if supported
by the card and the required data is available:
● Activity on previous transactions:
– Online authorization not completed
– Issuer Authentication failure on last online transaction
– SDA failure on last transaction
– DDA failure on last transaction
– Issuer script processed on last transaction
– PIN Try Limit exceeded on previous transaction
● New card check
● Velocity checks to see whether offline processing limits have been
exceeded for:
– Total consecutive offline transactions
– Total consecutive offline international transactions based on currency
– Total consecutive offline international transactions based on country
– Total cumulative offline transaction amount in designated currency
– Total offline transaction amount in the designated currency and a
designated secondary currency
31 Oct 2001
11.4.2 Card Response Decision

Based on the results of this card risk management, 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–2.
Table 11–2: Card Response to GENERATE AC Command
Card Responds
AAC ARQC TC
Decline — —
Terminal AAC
Requests
Decline Go Online —
ARQC
Decline Go Online Approve

TC
11.4.2.1 Standard Response to GENERATE AC

The card generates a DES-based cryptogram utilizing the data provided by
the terminal and data from the card. Data requirements are detailed in the
Visa Integrated Circuit Card Specification, Appendix E, Cryptogram Versions
Supported. The DES key requirements and the algorithms used in the
cryptogram generation process are detailed in the Visa Integrated Circuit
Card Specification, Appendix D, Authentication Keys and Algorithms.
The card returns this cryptogram to the terminal in the GENERATE AC
response. The Cryptogram Type in this response indicates the card’s decision
for transaction disposition (approve offline, decline offline, send online).
11–4
11.4.2.2 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 in the response to GENERATE AC, the card encrypts the Application
Cryptogram, Cryptogram Information Data and other data with the ICC
Private Key. The card returns the signed data to the terminal in the response
to GENERATE AC.
31 Oct 2001
11.5 Flow
Figure 11–1: Card Action Analysis
Checks previous transaction

Card Terminal
processing: Terminal during Terminal
- Online Auth not completed First GENERATE AC Action Analysis requests a
- Issuer Authen. failed command cryptogram (AAC, ARQC or
- SDA or DDA failed TC) for the first time
- Issuer Script processed
Sets indicators based upon

results
Checks new card & velocity

- Cons. Offline Transactions Uses above results to
- Cons. Offline Txns (Int'l) determine card response
- Cons. Offline Txns (approve, decline, or go
(Int'l—Country) online)
- Cum. Offline Txn. Amount
- Cum. Offline Txn. Amount
(Dual Currency)
Terminal
D Y Requested Decline
(AAC)?
Y
N
Terminal
Card Response = Y requested Go Online
Decline (AAC) (ARQC)?
Terminal requested
approval (TC)
Card
D Y Response = Decline
(AAC)?
GEN AC response = Card Response = Go

Y
Go Online (ARQC) Online (ARQC)?
GEN AC response =
Combined DDA/AC Approve (TC)
Generation?
N
Y D
Create Dynamic
Respond to GENERATE
Signature of ARQC or
TC AC
First GENERATE Terminal proceeds to Online

AC response Processing
11–6

The terminal reads the Card Risk Management Data Object List 1 (CDOL1)
from the card.

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 also performs the following card risk management checks to
determine final transaction disposition:
● Velocity checking for total consecutive offline transactions (Upper Limit)
● New card
● Offline PIN verification not performed
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 should 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 assure
that the response came from the valid issuer. This validation is called Issuer
Authentication.
This chapter describes the card and 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 outside the scope of this document and not
described.
This chapter is organized in the following manner:
12.1 Card Data
12.2 Terminal Data
12.3 Online Request and Response Data
12.4 Commands
12.5 Processing
31 Oct 2001
Online Processing Visa Integrated Circuit Card
12.1 Card Data

The terminal uses the card data described in Table 12–1 during Online
Processing. The Visa Integrated Circuit Card Specification, Appendix A, Card
and Issuer Data Elements Table, contains a detailed description of card data
elements and their usage.
Table 12–1: Online Processing—Card Data
GENERATE APPLICATION This response data includes the following:

CRYPTOGRAM (AC) response ● Cryptogram Type (an Authorization Request Cryptogram (ARQC) if transaction
data
is to be authorized online)
● Application Cryptogram
● Application Transaction Counter (ATC)
● Issuer Application Data
Application Interchange Profile The AIP received during Initiate Application Processing contains a bit that
(AIP) indicates whether the card supports Issuer Authentication.
The card uses the card data described in Table 12–2 during Issuer
Authentication.
Table 12–2: Online Processing Issuer Authentication—Card Data
Authorization Request The cryptogram generated by the card earlier in the transaction. The ARQC and
Cryptogram (ARQC) the Authorization Response Code are the input to the Authorization Response
Cryptogram (ARPC) validation process.
Unique DEA Keys (UDK) The DES keys used for ARPC validation. These are the same keys used to
generate the ARQC.
Card Verification Results (CVR) Contains a bit that is set if Issuer Authentication fails.
Issuer Authentication Failure A bit that is set if Issuer Authentication fails.

Indicator
12–2
12.2 Terminal Data

The terminal data described in Table 12–3 is updated with the Issuer
Authentication status. The Visa Integrated Circuit Card Terminal
Specification, Appendix A, Card and Issuer Data Elements Table, contains a
detailed description of these data elements and their usage.
Table 12–3: Online Processing—Terminal Data
Terminal Verification Results Contains a bit that is set when Issuer Authentication is unsuccessful.
(TVR)
Transaction Status Information Contains a bit that is set when Issuer Authentication is performed.
(TSI)
12.3 Online Request and Response Data

The online authorization request includes the data required for magnetic
stripe transactions as well as additional VSDC data, which is used to validate
the Authorization Request Cryptogram (ARQC) generated by the card. The
VSDC data elements to be transmitted from the terminal are listed in the Visa
Integrated Circuit Card Terminal Specification, Chapter 12, Online
Processing.
The online response may contain the data described in Table 12–4.
Table 12–4: Online Processing—Online Response Data
Issuer Authentication Data Issuer Authentication Data has two components:

●
Authorization Response Cryptogram (ARPC), which is an Issuer-generated
cryptogram to be validated by the card
● Authorization Response Code, which is the response value to be used in the
validation of the ARPC
Issuer Script Contains issuer updates to the card.
31 Oct 2001
12.4 Commands
The following commands are used during Online Processing:
GENERATE APPLICATION CRYPTOGRAM (AC) Command Response
The terminal receives the card’s response to the GENERATE APPLICATION
CRYPTOGRAM (AC) command, which contains the Application Cryptogram.
The GENERATE AC command is sent to the card during Terminal Action
Analysis. The GENERATE AC command may indicate that Combined
DDA/AC Generation be performed.
The card returns the GENERATE AC response at the end of Card Action
Analysis. The response is received by the terminal at the beginning of Online
Processing. The response includes the first Application Cryptogram and the
Cryptogram Type. If the response is an ARQC or a TC and Combined DDA/AC
Generation is performed, the response is a dynamic signature.
EXTERNAL AUTHENTICATE Command
If Issuer Authentication is to be performed, the terminal issues the
EXTERNAL AUTHENTICATE command with the Issuer Authentication
Data requesting that the card validate the Authorization Response
Cryptogram (ARPC), which is included in the command.
The response from the card indicates whether Issuer Authentication passed or
failed.
12–4
12.5 Processing
Standard Online Processing includes processing the online request,
processing the online response, and optionally performing Issuer
Authentication. If Combined DDA/AC Generation is to be performed,
processing includes validation of the dynamic signature.
12.5.1 Online Request

Online request processing differs depending on whether Combined DDA/AC
Generation has been requested.
12.5.1.1 Combined DDA/AC Generation Processing

If Combined DDA/AC Generation indicated in the GENERATE AC command
and the cryptogram returned is an ARQC or a TC, the terminal performs the
following processing:
● The terminal deciphers the dynamic cryptogram using the recovered ICC
Public Key to recover the Application Cryptogram.
● If the hash does not match the terminal indicates in the TVR that
Combined DDA/AC Generation failed and proceeds to Completion.
● If the hash matches, standard online processing is performed.
12.5.1.2 Standard Online Processing

If the card returns an ARQC to the terminal in the GENERATE AC response
and the terminal has the capability to go online, the terminal transmits an
online authorization request message.
If the card does not respond with an ARQC or the terminal is unable to send
the transaction online, the terminal proceeds to the Completion function.
12.5.2 Online Response

After the online request message is successfully transmitted to the issuer, the
terminal receives the online response message, which may include an issuer
script containing updates to the card parameters or a cryptogram, or both, to
be validated using Issuer Authentication to prove that the response came
from the valid issuer.
If the online response contains the Issuer Authentication Data and the card
supports Issuer Authentication, the terminal performs Issuer Authentication.
Otherwise, the terminal proceeds to the Completion function.
31 Oct 2001
12.5.3 Issuer Authentication

The terminal transmits an EXTERNAL AUTHENTICATE command to the
card instructing the card to perform Issuer Authentication. The card validates
the ARPC using the ARQC generated previously by the card, the
Authorization Response Code from the issuer, and the Unique DEA Keys
(UDK) stored in a secret location on the card.
Both the card and terminal record Issuer Authentication results:
● The card sets Issuer Authentication results in the Card Verification
Results (CVR) and the Issuer Authentication Failure Indicator and
returns the results to the terminal in the EXTERNAL AUTHENTICATE
response.
● The terminal sets Issuer Authentication results in the Terminal
Verification Results (TVR) and the Transaction Status Information (TSI)
before proceeding to the Completion function.
12–6
12.5.4 Processing Flow

Figure 12–1 shows the interaction between the card, the terminal, and the
issuer’s host system for Online Processing.
Figure 12–1: Online Processing Flow
Online
Card Terminal Authorization
Systems
(see Chapter 11) A
GENERATE AC Y
Card sets cryptogram AAC (decline
to send online, command cryptogram)
approve offline, or response returned?
Terminal proceeds
decline offline to Completion
N
(see chapter 13)
Combined
DDA/Gen. AC Y
requested?
A N Y Valid Dynamic
Signature?
N ARQC N
returned?
Terminal indicates
in TVR DDA/AC
Y Generation failed
Perform online
Send transaction
Online authorization
online for
Response processing and
authorization
return response
Online
Response
Card performs Issuer

EXTERNAL Y
Authentication, sets IA Issuer Authentication
AUTHENTICATE
results indicators, and to be performed?
command
returns results
EXTERNAL
AUTHENTICATE Terminal sets Issuer
command Auth. results
response indicators N
Completion
(see chapter 13)
31 Oct 2001

The card sets the Cryptogram Type to an ARQC if an online authorization is
to be done.

Completion
During Completion, the card uses Issuer Authentication results and card
parameters to help determine the disposition of the transaction and whether
to reset certain counters and indicators.
If a TC was requested by the card and Combined DDA/AC Generation was
performed and failed the terminal declines the transaction.
If an ARQC was requested by the card and Combined DDA/AC Generation
was performed and failed, an AAC (decline cryptogram) is requested by the
terminal in the final GENERATE AC.
Issuer-to-Card Script Processing
If the online response contains an Issuer Script, these post-issuance updates
are applied.
12–8
Completion 13
The terminal and the card perform Completion to conclude transaction

processing. Completion includes the following actions:
●
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/AC Generation was performed and failed the terminal
processes as follows:
– If an ARQC was requested by the card, the terminal requests an AAC
(decline cryptogram) in the second GENERATE AC.
– If a TC was requested by the card and Combined DDA/AC Generation
was performed and failed the terminal declines the transaction with a
Z1 Response Code.
● 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 results 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. The terminal may perform additional
Completion functions if they do not interfere with the Completion functions
defined in the VIS card and terminal volumes.
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 Application Cryptogram (AC) Command
13.4 Processing
13.5 Flow
13–2
13.1 Card Data

The second GENERATE AC command response, which the card returns to the
terminal, includes the card data elements described in Table 13–1. The Visa
Integrated Circuit Card Specification, Appendix A, Card and Issuer Data
Elements Table, contains a detailed description of card data elements and
their usage.
Table 13–1: GENERATE AC Response
Application Cryptogram (AC) The cryptogram generated by the card.
Application Transaction Counter A count of card transactions.

(ATC)
Cryptogram Information Data Contains indicators for

● The type of cryptogram:
– An Application Authentication Cryptogram (AAC) for a decline
– A Transaction Certificate (TC) for an approval
– An Authorization Request Cryptogram (ARQC) when online processing is
requested (first GENERATE AC only)
● Other status information including Service Not Allowed
Issuer Application Data Includes Visa discretionary data and issuer discretionary data for transmission to
the Issuer, including the CVR.
Card Verification Results (CVR) A Visa proprietary data element containing indicators, which are set based upon
the results of offline processing for current and previous transactions. The CVR is
included in the clearing transaction as “proof” of card processing.
31 Oct 2001
The card uses the internal card data elements described in Table 13–2 during
Completion. Other data elements used are listed in the Visa Integrated Circuit
Card Specification, Chapter 12, Completion.
Table 13–2: Completion—Card Data (Partial List)
Application Default Action A Visa proprietary data element indicating the action a card should take when
(ADA) exception conditions occur.
CDOL2 A list of data objects (tags and lengths) for the terminal to pass to the card with the
second GENERATE AC command.
13.2 Terminal Data

The terminal data elements described in Table 13–3 are used during
Completion. The Visa Integrated Circuit Card Terminal Specification,
Appendix A, Card and Issuer Data Elements Table, contains a detailed
description of these data elements and their usage.
Table 13–3: Completion—Terminal Data
Authorization Response Code Provided to the card to indicate if the transaction is approved or declined and if the
authorization was performed offline or online.
Terminal Verification Results Contains indicators that are set to record offline processing results, such as SDA
(TVR) failure or floor limit exceeded, from a terminal perspective.
13.3 GENERATE Application Cryptogram (AC) Command

The GENERATE APPLICATION CRYPTOGRAM (AC) command is used by
the terminal to request a final Application Cryptogram from the card. It may
indicate that Combined DDA/AC Generation is to be performed.
The GENERATE AC command contains the terminal data elements specified
by the card in the CDOL2, which was received by the terminal during Read
Application Data.
13–4
The GENERATE AC response includes the card transaction counter, the

cryptogram type indicating the card’s authorization decision, the application
cryptogram, and the CVR indicating processing results. Issuer discretionary
data may also be provided.
13.4 Processing
Completion involves three steps:
● The terminal determines the transaction disposition and issues a second
GENERATE AC command to the card if an online authorization was
completed.
● The card determines the final transaction response and resets card
indicators based card parameters and Issuer Authentication status.
● The terminal completes the transaction.
13.4.1 Terminal Determines Transaction Disposition

The terminal processing during Completion varies based upon what has
occurred during previous processing of the transaction:
● At the end of Card Action Analysis, the card may have:
– Requested an offline approval or decline
– Requested an online authorization
● During Online Processing, the online authorization request may have:
– Completed successfully
– Not completed because the terminal did not support online processing
or because an online response was not received.
13.4.1.1 Transaction Authorized Offline

When the card responds to the first GENERATE AC command in Card Action
Analysis with a Transaction Certificate (TC) or an Application Authentication
Cryptogram (AAC), the terminal completes the transaction offline. If a TC was
requested by the card and Combined DDA/AC Generation was performed and
failed, the terminal declines the transaction. The terminal displays a message
indicating the action taken: approved, declined, or service not allowed.
If the terminal requested in the GENERATE AC command that Combined
DDA/AC Generation be performed and an AAC is returned by the card, the
terminal indicates in the TVR that Combined DDA/AC Generation has failed.
31 Oct 2001
If Combined DDA/AC Generation was performed and failed, the terminal

processes as follows:
● If a TC was returned, the terminal declines with a Z1 response code.
●
If an ARQC is returned, the terminal requests an AAC in the second
GENERATE AC command.
13.4.1.2 Online Authorization Completed Successfully

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, the terminal requests an
approval (TC).
● If the issuer has requested a referral, it is recommended that the terminal
request a decline (AAC). However, the terminal may request an approval
(TC) if the issuer has requested a referral.
● If the Authorization Response Code does not indicate approve or refer, the
terminal requests an AAC.
For valid Authorization Response Codes (field 39) for approvals, declines, and
referrals, refer to the V.I.P. System Technical Reference Volume 2, Field and
Code Descriptions.
13.4.1.3 Online Authorization Unable to Complete

If the card requested online processing and the terminal does not support
online processing or the online authorization did not complete, the terminal
uses the Issuer Action Code (IAC)—Default and the Terminal Action Code
(TAC)—Default to determine the transaction disposition. This IAC and TAC
processing is similar to the processing in Terminal Action Analysis described
in Chapter 10, Terminal Action Analysis. If any TVR bits and the
corresponding bit in the IAC or TAC are both “1”, the terminal requests a
decline.
13–6
Based on the results of this processing, the terminal issues the final
GENERATE AC command to the terminal. The Cryptogram Type requested
in the final GENERATE AC command indicates whether the transaction is to
be declined (AAC) or approved (TC). This command also includes an
Authorization Response Code, shown in Table 13–4, which indicates that an
online authorization was not completed.
Table 13–4: Authorization Response Code for Offline Action Taken
Terminal Authorization
Requests Response Code Transaction Disposition
TC Y3 Unable to go online (offline approved)
AAC Z3 Unable to go online (offline declined)
13.4.2 Card Responds to Final GENERATE AC Command

The card uses the Authorization Response Code received from the terminal in
the final GENERATE AC command to determine whether an online
authorization was completed.
● If the Authorization Response Code is one of the offline codes listed in
Table 13–4, the online authorization was unable to complete or the
terminal did not support online processing.
● If the Authorization Response Code is not one of the offline codes, the
online authorization was completed.
13.4.2.1 Online Authorization Completed

When the online authorization completed, the card uses the final GENERATE
AC Cryptogram Type and results from Issuer Authentication to determine the
final transaction disposition:
●
AAC (Decline) Requested
If the terminal requests a decline (AAC) in the final GENERATE AC
command, the card always returns an AAC in the response. Prior to
responding to the terminal with an AAC, the card updates indicators and
counters as indicated in the Visa Integrated Circuit Card Specification,
Chapter 13, Completion.
31 Oct 2001
● TC (Approval) Requested
If the terminal requests an approval (TC) in the final GENERATE AC
command, the card responds with either an approval or a decline response
based on the status of Issuer Authentication processing and card’s Issuer
Authentication options.
The card converts the approval to a decline if either of the following conditions
is true:
● Issuer Authentication failed and the ADA indicates that the transaction
should be declined if Issuer Authentication fails
● Issuer Authentication is mandatory, was not performed, and the ADA
indicates that the transaction should be declined if Issuer Authentication
is mandatory and not performed
If neither of the above conditions is true, the card responds with an approval.
Refer to the Visa Integrated Circuit Card Specification, Chapter 13,
Completion, for details on how indicators and counters are set and reset for
these conditions.
13.4.2.2 Online Authorization Unable to Complete

When the Authorization Response Code in the final GENERATE AC indicates
that online processing was requested but not completed, the card performs
additional card risk management steps prior to responding to the terminal.
These steps are performed whether the terminal has requested an approval or
decline.
● Card Risk Management
The card performs the following optional card risk management checks if
they are supported and the required data elements are present in the
card:
– Velocity Checking for Total Consecutive Transactions (Upper Limit)
This optional check causes the card to respond with a decline (AAC) if
the upper limit for consecutive offline transactions has been exceeded.
– New Card
If the card is a new card and the card’s Application Default Action
(ADA) indicates that a new card transaction should be declined if it
cannot be online authorized, the card responds with a decline (AAC).
– PIN Try Limit Exceeded on Previous Transaction
If the PIN Try Counter is zero and the card’s ADA indicates that a
transaction should be declined if the PIN Try Limit was exceeded on a
previous transaction, the card responds with a decline (AAC).
13–8
● Card Response to Terminal

The card responds to the final GENERATE AC command issued by the
terminal as follows:
– Card Declined Transaction
If the terminal requested an AAC or the card risk management steps
have determined that the card should decline the transaction, the card
updates internal indicators and counters as described in the Visa
Integrated Circuit Card Specification, Chapter 13, Completion, and
responds with an AAC.
– Card Approved Transaction
If the terminal requested a TC and the results of card risk
management indicate that the transaction should be approved, the
card updates internal counters and indicators according to the Visa
Integrated Circuit Card Specification, Chapter 13, Completion, and
responds with a TC.
13.4.3 Terminal Completes Transaction

Upon receipt of the card’s response to the GENERATE AC command, the
terminal processes the Issuer Script, if present (see Chapter 14, Issuer-to-
Card Script Processing).
Final terminal action is determined by the type of cryptogram the terminal
requested and the response from the card in the final GENERATE AC:
● Terminal requested a decline (AAC) in the final GENERATE AC
The terminal completes the transaction and displays a message indicating
that the transaction was declined.
● Terminal requested an approval (TC) in the final GENERATE AC
– If the card responds with a TC, the terminal completes the transaction
and displays a message indicating that the transaction was approved.
– If the card responds with an AAC, the terminal completes the
transaction and displays a message indicating that the transaction
was declined.
■ At an ATM, if an online-approved cash disbursement or account
transfer transaction is declined by the card because of an Issuer
Authentication failure, 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.5 Flow
Figure 13–1: Completion
Card Terminal
Terminal analyzes first
GENERATE AC
response
Set Authorization
Response Code to
Y1 (approve) or
Card returned Z1 (decline) based
N on card response and
ARQC?
results of Combined
DDA/AC Generation if
performed
Transaction Perform Terminal

completed N Action Analysis using
online? IAC & TAC - Default
Set Authorization
Response Code to
Y3 (approval) or
Y
Z3 (decline)
Final
Card receives Final Set Application
GENERATE AC
Generate AC Cryptogram to TC
Command
(approval) or AAC
(decline)
Card may
convert online
Auth Resp.
approval to a
Code = Y3 or
N decline based
Terminal requests AAC
Z3 (Unable to go
on Issuer
online)? or TC in Final
Authentication
GENERATE AC
results
Card performs card risk

Terminal receives
management checks for
Final GENERATE AC
the upper offline limit, new
Card may reset response
card, and PIN Try Limit
exceeded previously counters and
indicators
based upon
Issuer Auth Terminal processes
Card may decline based Issues Script if in
results
upon card risk auth. response
management results
Final A
GENERATE AC
Card responds to Final Response
GENERATE AC with TC Terminal completes
(approve) or AAC transaction
(decline)
13–10

Online Processing
If the card receives an EXTERNAL AUTHENTICATE command from the
terminal, the card performs Issuer Authentication processing and sets
indicators for Issuer Authentication performed and successful or failed. These
indicators are used during Completion by the card in the response decision
and in determining which card counters and indicators should be reset.
31 Oct 2001
Issuer-to-Card Script Processing 14
Issuer-to-Card Script Processing permits issuers to change personalized data

on cards without card 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.
Commands are supported for:
● Updating card parameters
● Blocking or unblocking the application
●
Blocking the card
●
Unblocking the PIN Try Counter
●
Changing the Offline PIN
Issuer-to-Card Script Processing limits credit and fraud exposure by allowing
blocking of overspent and stolen cards. Card parameters can be modified to
correspond to changing cardholder circumstances.
31 Oct 2001
Issuer-to-Card Script Processing Visa Integrated Circuit Card
This chapter is organized in the following manner:

14.1 Script-Related Keys
14.2 Card Data
14.3 Terminal Data
14.4 Online Response Data
14.5 Commands
14.6 Processing
14.7 Processing Flow
14–2
Visa Integrated Circuit Card 14.1 Script-Related Keys
14.1 Script-Related Keys

The recommended secure messaging methods for Issuer-to-Card Script
Processing mentioned in Section 14.6.3 use the following card and
issuer-based keys.
14.1.1 Message Authentication Code Keys

The Message Authentication Code (MAC) keys are used in the generation and
validation of the script command’s MAC. The MAC is a cryptogram included
in script commands that ensures that the command has not been altered
(message integrity) and that the command came from the valid issuer (issuer
authentication). The MACing process uses three keys:
● Master Message Authentication Code Key (MAC MDK) is an
issuer-unique double-length DES key. The MAC MDK is used to generate
the card’s Unique Message Authentication Code Key (MAC UDK) and the
transaction’s MAC Session Key.
● Unique Message Authentication Code Key (MAC UDK) is a double-length
DES key personalized on the card. The MAC UDK is used to generate a
MAC Session Key during the transaction. It is derived from the issuer’s
MAC MDK.
● The MAC Session Key is a transaction-unique double-length DES key
used to generate and validate the script command’s MAC at the time of
transaction.
These MAC keys are required if the Visa recommended method of secure
messaging is supported.
14.1.2 Data Encipherment Keys

The Data Encipherment Keys are used to encipher confidential issuer script
data such as Offline PIN values during the transmission of the script from the
issuer host computer to the card. This encipherment process uses three keys:
● Master Data Encipherment DEA Key (ENC MDK) is an issuer-unique
double-length DES key. The ENC MDK is used to generate the card’s
Unique Data Encipherment DEA Key (ENC UDK) and the transaction’s
Data Encipherment Session Key.
●
Unique Data Encipherment DEA Key (ENC UDK) is a double-length DES
key personalized on the card and used to generate the Data Encipherment
Session Key. The ENC UDK is derived from the ENC MDK.
● Data Encipherment Session Key is a transaction-unique double-length
DES key derived from the ENC MDK and used by the issuer host
computer to encipher confidential data in the issuer script.
31 Oct 2001
These data encipherment keys are required if the Visa recommended method
of secure messaging is supported and the issuer script commands may include
confidential data such as Offline PIN values.
14.2 Card Data

The indicators and counters in the card described in Table 14–1 are used in
processing script commands. The Visa Integrated Circuit Card Specification,
Appendix A, Card and Issuer Data Elements Table, contains a detailed
description of card data elements and their usage.
Table 14–1: Issuer-to-Card Script Processing—Card Data
Application Transaction Counter The ATC is used in the generation of the Message Authentication Code (MAC)
(ATC) and Data Encipherment session keys.
Card Verification Results (CVR) The CVR contains flags related to script processing, which are updated with the
script results.
Issuer Script Command The Issuer Script Command Counter is used to count the Script Update
Counter commands received during a transaction.
Issuer Script Failure Indicator The Issuer Script Failure Indicator is set when Issuer Script processing fails and
remains set until it is reset after a subsequent online transaction.
14–4
14.3 Terminal Data

The terminal data elements described in Table 14–2 are used during Issuer
Script processing. The Visa Integrated Circuit Card Specification, Appendix A,
Card and Issuer Data Elements Table, contains a detailed description of
terminal data elements and their usage.
Table 14–2: Issuer-to-Card Script Processing—Terminal Data
Issuer Script Results The Issuer Script Results contains the results of Issuer Script processing and is
sent to the issuer in a clearing message or other online message.
Terminal Verification Results The TVR contains indicators that are set if Issuer Script processing fails.
(TVR)
Transaction Status Information The TSI contains an indicator that is set if an issuer script is processed.
(TSI)
14.4 Online Response Data

The data elements described in Table 14–3 are included in the issuer script
received in the online response from the issuer.
Table 14–3: Issuer-to-Card Script Processing—Online Response Data
Issuer Script Command The Issuer Script command contains the command transmitted from the issuer,
which is sent to the card.
Issuer Script Identifier The Issuer Script Identifier is a number used to uniquely identify an issuer script.
Issuer Script Template 2 The Issuer Script Template 2 contains proprietary issuer data for transmission to
the card after the final GENERATE AC command.
31 Oct 2001
14.5 Commands
The following script commands for Issuer Script processing are supported:
APPLICATION BLOCK
This command blocks the use of the selected application. If the application is
blocked during the processing of a transaction, the card and terminal continue
to process the transaction through Completion. During any subsequent
application selection, the card does not allow the blocked application to be
available for application selection to perform a financial transaction. The
terminal may select an application that was blocked in order to unblock the
application. However, if this occurs, the card is required to return an
Application Authentication Cryptogram (AAC) in response to a GENERATE
APPLICATION CRYPTOGRAM (AC) command.
APPLICATION UNBLOCK
This command reverses the status of an application that is blocked.
Unblocking of an application occurs only at a special device designated by the
issuer.
CARD BLOCK
The CARD BLOCK command permanently disables all applications on the
card.
PIN CHANGE/UNBLOCK
The PIN CHANGE/UNBLOCK command provides the issuer with the
capability either to unblock the Reference PIN (reset the PIN Try Counter) or
to simultaneously change and unblock the Reference PIN.
PIN changes using PIN CHANGE/UNBLOCK or other methods should only
be performed within a secure environment controlled by the issuer.
14–6
Visa Integrated Circuit Card 14.5 Commands
PUT DATA
The PUT DATA command allows specific primitive data objects in the card to
be updated. In this version of the Visa Integrated Circuit Card Specification,
only the following data elements should be allowed to be updated using Issuer
Script processing:
●
Lower Consecutive Offline
● Upper Consecutive Offline Limit
● Consecutive Transaction Limit (International)
● Consecutive Transaction Limit (International—Country)
● Cumulative Total Transaction Amount Limit
● Cumulative Total Transaction Amount Upper Limit
● Cumulative Total Transaction Amount Limit (Dual Currency)
● Currency Conversion Factor
● VLP Single Transaction Limit
● VLP Funds Limit
If terminal velocity checking is not supported, all of these card data elements,
if present, are stored in proprietary internal files. If terminal velocity checking
is supported, the Lower Consecutive Offline Limit and the Upper Consecutive
Offline Limit are stored in records and accessible to the terminal using the
READ RECORD command.
UPDATE RECORD
The UPDATE RECORD command is used to update a record in a file with the
data provided in the command’s data field.
The UPDATE RECORD command is required to update the PIN Verification
Value (PVV) in the track data on the chip to support a PIN change. It is also
required for updates to the Upper and Lower Consecutive Offline Limits if
Terminal Velocity Checking is supported by the card. Issuer script commands
cannot be used to update the data on the physical magnetic stripe.
31 Oct 2001
14.6 Processing
Issuer-to-Card Script Processing is comprised of issuer scripts, command
processing, and secure messaging.
14.6.1 Issuer Scripts

The Issuer Script is transmitted to the acquirer by the issuer in the response
message. In this version of the Visa Integrated Circuit Card Specification, at
most only one Issuer Script shall be transmitted in the response message. In a
subsequent version, multiple Issuer Scripts may be allowed in a response
message.
Issuer Scripts transmitted in the response message always have tag “72”,
indicating that Issuer Script processing is to be performed after the final
GENERATE AC command. The issuer uses secure messaging in Issuer Script
processing for each command that instructs the card to modify any
information contained in the card.
14.6.2 Command Processing

The recommended Issuer Script commands are used to perform the functions
described earlier in this chapter. The card performs the requested command to
update, reset, change, or alter the data contained on the card only if 1) that
command supports secure messaging and 2) secure messaging was performed
successfully.
Visa requires that some form of issuer authentication be successfully
performed prior to processing an Issuer Script Command. This requirement
may be satisfied by successfully performing secure messaging for that
command since secure messaging is a form of issuer authentication. The
originator of an Issuer Script Command is assumed to be the card issuer. If an
entity other than the issuer originates the commands, the same requirements
apply.
14–8
14.6.3 Secure Messaging

The principle objectives of secure messaging are to ensure data
confidentiality, message integrity, and issuer authentication. Data
confidentiality ensures that secret data remains secret during transmission
from the issuer to the card. Message integrity ensures that commands and
command data are not altered during transmission. Issuer authentication
ensures that the command came from the valid issuer. Message integrity and
issuer authentication are achieved using a MAC. Data confidentiality is
achieved using encipherment of the plaintext command data (if present).
Validation of the MAC and decryption of enciphered data requires the use of
session keys. These session keys are unique for each transaction and
generated as described in Section 14.1 Script-Related Keys, of this chapter.
31 Oct 2001
14.7 Processing Flow

Figure 14–1 illustrates how Issuer-to-Card Script Processing might be
performed.
Figure 14–1: Issuer-to-Card Script Processing
Card Terminal
Terminal completes
Online Processing
and Completion
Issuer Script
present in N
response?
Terminal parses out

Issuer Script
command in Y
sequential order
Card processes
command including Script Terminal sends
performing secure Command command to card
messaging
Y
Response Another
Command Card sets response code shows N command
processing Y error? present?
code for success
successful?
Y
N
Terminal sets Script

Card sets response
Processing Failed in
code to show error
TVR bit
Card returns Another script

command response present?
with response code
Script N
Command
Response
Terminal sets Issuer
Script Processing
Performed in TSI bit
Terminal completes
transaction
processing
14–10

Online Processing
The online response received from the acquirer may contain an issuer script to
be processed during Issuer-to-Card Script Processing.

Card Action Analysis (subsequent transactions)
During Card Action Analysis for the card’s next transactions, the CVR
subfields are set to indicate script results from the previous transaction based
upon the Issuer Script Failure Indicator and Issuer Script Command Counter
stored in the card. The issuer receives this Card Verification Results (CVR)
data in the next clearing record and next online authorization.
Completion (subsequent transactions)
The card resets the Issuer Script Failure Indicator and Issuer Script
Command Counter to “0” after online transactions if any of the following
conditions exist:
● Issuer Authentication was successful
● Issuer Authentication was optional and not performed
● Issuer Authentication was not supported
The Issuer Script Failure Indicator and Issuer Script Command Counter are
not reset if an online authorization is not completed or if the card’s Issuer
Authentication requirements are not satisfied.
31 Oct 2001
Acronyms A
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/00 Visa Public A–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
A–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
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 Organization 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
A–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
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)
A–6
Glossary
This is a glossary of terms used in this specification; it is not intended as a data dictionary.
For descriptions of specific card and issuer 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.
Issuer Authentication
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 Application Version Number, 7–4
Application Version Number (‘9F08’), 7–2
AAC, 10–4 to 10–5, 11–2, 11–4, 11–7, 12–8 to 13–1,
Application Version Number (‘9F09’), 7–3
13–3, 13–5 to 13–9, 14–6
ARPC, 12–2 to 12–4, 12–6
AC. See Application Cryptogram
ARQC, 6–14, 10–4 to 10–5, 11–2, 11–4, 12–2 to 12–6,
ADA. See Application Default Action
12–8 to 13–1, 13–3
ADF. See Application Definition File
ATC, 4–4, 9–2, 9–4 to 9–5, 12–2, 13–3, 14–4
AEF. See Application Elementary Files
ATM, 1–7, 13–9
AFL. See Application File Locator
AUC. See Application Usage Control
AID, 3–2 to 3–3
Authorization Request Cryptogram. See ARQC
AIP. See Application Interchange Profile
Authorization Response Code, 12–2 to 12–3, 12–6,
Amount X, 8–3 13–1, 13–4, 13–6
Amount Y, 8–3 Authorization Response Cryptogram. See ARPC
Amount, Authorized, 9–3 to 9–4 authorization response message, 14–8
Application Authentication Cryptogram. See AAC
APPLICATION BLOCK command, 2–11, 14–6 B
Application Cryptogram, 6–11 to 6–12, 10–4, 11–2, biometrics, 8–1
11–5, 12–2, 12–4 to 12–5, 13–3 to 13–4, 13–6
Application Default Action, 8–4, 8–14, 13–4, 13–8 C
Application Definition File, 3–2 CA Public Key Index. See Certificate Authority Public
Application Effective Date, 7–2, 7–4 Key Index
Application Elementary Files, 3–2, 5–2 candidate list, building the, 3–4
Application Expiration Date, 7–2, 7–5 Card Action Analysis, 2–4, 2–8, 2–10, 6–14, 10–1,
Application File Locator, 4–1 to 4–2, 4–4, 5–2 to 5–3 11–1 to 11–7, 12–4, 12–8, 13–5
Application Identifier. See AID card data, 11–2
Application Interchange Profile, 4–1 to 4–2, 4–4, 8–3, processing, 11–3
8–8, 9–1, 12–2 processing flow, 11–6
Application PAN. See PAN terminal data, 11–2
Application Primary Account Number. See PAN CARD BLOCK command, 2–11, 14–6
Application Selection, 1–7, 2–1, 2–7, 2–9, 3–1 to 3–7, card data
4–4, 4–6, 14–6 for Application Selection, 3–2
card data, 3–2 for Card Action Analysis, 11–2
functions, 3–1 for Completion, 13–4
identifying and selecting the application, 3–4 for Initiate Application Processing, 4–2 to 4–3
processing flow, 3–6 for Issuer-to-Card Script processing, 14–4
terminal data, 3–3 for Online Processing, 12–2
Application Selection Indicator, 1–7, 3–3 for Processing Restrictions, 7–2
Application Transaction Counter. See ATC for Read Application Data, 5–2
APPLICATION UNBLOCK command, 2–11, 8–14, for Terminal Action Analysis, 10–2
14–6 for Terminal Risk Management, 9–2
Application Usage Control, 7–2, 7–4 to 7–5
31 Oct 2001
Draft 12/18/00 Visa Public Index–1
D Visa Integrated Circuit Card
card reader, 8–10 Completion, 2–5, 2–8, 2–10, 12–5 to 12–6,

Card Risk Management, 11–3, 13–8 13–1 to 13–11
Card Risk Management checks, 11–3, 11–7 card data, 13–4
Card Risk Management Data Object List 2. See processing flow, 13–5
CDOL2 terminal data, 13–4
Card Risk Management Data Object List. See CDOL1 transaction flow example, 13–10
card velocity checking. See velocity checking, card Consecutive Transaction Limit (International), 14–7
Card Verification Results. See CVR Consecutive Transaction Limit
Card Verification Value. See CVV (International—Country), 14–7
cardholder confirmation, 3–5 credit, 12–1
cardholder selection, 3–4 to 3–5 credit risk, 14–1
Cardholder Verification, 2–3, 2–7, 2–9, 4–6, Cryptogram Information Data, 6–12, 11–5, 13–3
8–1 to 8–14, 10–7 cryptogram type, 11–3 to 11–4, 12–2, 12–4, 12–8, 13–7
card data, 8–3 cryptogram version 14, 1–8
CVM List Processing, 8–8 Cumulative Total Transaction Amount Limit, 14–7
CVM Processing, 8–10 Cumulative Total Transaction Amount Limit (Dual
processing, 8–8 Currency), 14–7
Cardholder Verification Method List. See CVM List Cumulative Total Transaction Amount Upper Limit,
Cardholder Verification Method. See CVM processing 1–9, 14–7
Cardholder Verification Value. See CVV Currency Conversion Factor, 14–7
CDOL1, 10–2 to 10–4, 11–2 to 11–3, 11–7 CVM Code, 8–3, 8–8
CDOL2, 13–4 CVM Conditions, 8–3
Certificate Authority, 6–3 CVM Entry, 8–8
Certificate Authority Public Key Index, 6–4, CVM List, 1–7 to 1–8, 2–3, 8–1, 8–3, 8–8
6–8 to 6–9, 6–13, 8–5 CVM List processing, 8–3, 8–8
Certificate Serial Number, 6–13 card data, 8–3
CID. See Cryptogram Information Data processing flow, 8–9
Combined DDA/AC Generation, 1–7 to 1–8, 2–2, 2–7, CVM Type, 8–3
2–9, 6–7, 6–11, 6–14, 11–5, 12–4 to 12–5, CVR, 6–16, 8–4, 12–2, 12–6, 13–3, 14–4
12–8 to 13–1, 13–4 to 13–5
online processing, 12–5 D
Combined DDA/AC Generation failure, 6–17, Data Authentication Code (DAC), 1–7
13–5 to 13–6 data confidentiality, 14–9
command support requirements, 2–11 Data encipherment, 14–3
commands Data Encipherment Session Key, 14–3 to 14–4
APPLICATION BLOCK, 14–6 DDA, 2–2, 5–1, 6–1, 6–11 to 6–17
APPLICATION UNBLOCK, 14–6 card data, 6–12
CARD BLOCK, 14–6 processing flow, 6–15
EXTERNAL AUTHENTICATE, 12–4, 13–11 terminal data, 6–11
GENERATE AC, 10–4, 11–2, 12–4, 13–4 DDA failed on last transaction, 11–3
GET CHALLENGE, 8–7 DDA Failure Indicator, 6–12, 6–16
GET DATA, 8–7, 9–4 DDA key relationships, 6–6
GET PROCESSING OPTIONS, 4–3 DDF. See Directory Definition File
INTERNAL AUTHENTICATE, 6–13 DDOL, 6–12
PIN CHANGE/UNBLOCK, 14–6 Dedicated File Name. See DF Name
PUT DATA, 14–7 default CVM, 2–3
READ RECORD, 5–3 Default DDOL, 6–11
UPDATE RECORD, 14–7 DES, 11–4, 14–3
VERIFY, 8–7 DES keys, 11–4, 14–3
Index–2
Visa Integrated Circuit Card E
Directory Definition File, 3–2 Geographic Restrictions, 4–4

Directory File, 3–2 GET CHALLENGE command, 2–11, 8–7, 8–10
Directory Selection Method, 1–7, 3–4 to 3–5 GET DATA command, 2–11, 8–7, 8–10, 9–4 to 9–5
Dynamic Data Authentication Failure Indicator. See GET PROCESSING OPTIONS command, 2–11, 4–1,
DDA Failure Indicator 4–3 to 4–5
Dynamic Data Authentication. See DDA
dynamic signature, 6–11, 6–14, 11–5, 12–4 to 12–5
H
hash, 6–9, 6–13, 12–5
E
EMV, 1–3, 1–6 to 1–7
I
EMV documentation, 1–11 IACs, 8–14, 10–1 to 10–7, 13–6
ENC MDK, 14–3 ICC Dynamic Number, 1–7, 6–12
ENC UDK, 14–3 ICC key data, 8–11
Enciphered PIN Data, 8–6 ICC PIN Encipherment key data, 8–11
Europay, MasterCard, Visa. See EMV ICC PIN Encipherment Private Key, 8–5
Expiration Date. See also Application Expiration Date ICC PK Certificate, 6–3 to 6–5, 6–12 to 6–13
EXTERNAL AUTHENTICATE command, 2–11, 12–4, ICC Private Key, 6–4 to 6–5, 6–11 to 6–14, 11–5
12–6 ICC Public Key, 1–8, 2–2, 6–4 to 6–5, 6–13 to 6–14,
12–5
F ICC Public Key Certificate. See ICC PK Certificate
Fail CVM, 8–11 ICC Public Key Exponent, 6–12
FCI. See File Control Information ICC Public Key Remainder, 6–12
File Control Information, 3–2, 4–2 to 4–3 Initiate Application Processing, 2–2, 2–7, 2–9, 3–7,
floor limits, 9–4 4–1, 8–14
fraud risk, 12–1, 14–1 card data, 4–2 to 4–3
functional overview, 2–1 card processing, 4–4
functional requirements functions, 4–1
card, 2–7 processing flow, 4–5
miscellaneous terminal, 2–10 terminal processing, 4–3 to 4–4
terminal, 2–9 INTERNAL AUTHENTICATE command, 2–11, 6–13
functions ISO documentation, 1–10
Card Action Analysis, 11–1 Issuer Action Codes. See IACs
Cardholder Verification, 8–1 Issuer Application Data, 12–2, 13–3
Completion, 13–1 Issuer Authentication, 2–5, 12–5 to 12–6, 13–1, 13–5,
Issuer-to-Card Script Processing, 14–1 13–7 to 13–8, 14–8 to 14–9
Offline Data Authentication, 6–1 Issuer Authentication Data, 12–3, 12–5
Online Processing, 12–1 Issuer Authentication Failure Indicator, 12–2, 12–6
Processing Restrictions, 7–1 Issuer Authentication Failure on Last Transaction,
11–3
Read Application Data, 5–1
Issuer Country Code, 4–2
Terminal Action Analysis, 10–1
Issuer Country Code “5F28”, 7–2
Terminal Risk Management, 9–1
issuer host, 12–1, 12–7
functions, mandatory and optional, 2–7
Issuer PK Certificate, 6–3, 6–8 to 6–9, 6–13
G Issuer Private Key, 6–4 to 6–5, 6–8
GENERATE AC command, 2–11, 6–14, 6–16, 12–2, Issuer Public Key, 1–8, 2–2, 6–3, 6–9, 6–11, 6–13
12–4 to 12–5, 13–3 to 13–9, 14–6, 14–8 Issuer Public Key Certificate. See Issuer PK Certificate
Terminal Action Analysis, 10–3 to 10–4, Issuer Public Key Component, 6–4
11–2 to 11–5, 11–7 Issuer Public Key data, 8–5
GENERATE APPLICATION CRYPTOGRAM. See Issuer Public Key Exponent, 6–8
GENERATE AC command Issuer Public Key Remainder, 6–4, 6–8
Geographic Indicator, 4–2
31 Oct 2001
Draft 12/18/00 issuer script, 12–3, 12–5, 13–9
Visa Public Index–3

K Visa Integrated Circuit Card
Issuer Script Command Counter, 14–4 N

issuer script commands, 14–5
new card, 9–5, 11–3, 11–7, 13–8
Issuer Script Failure Indicator, 14–4
No CVM Required, 8–11
Issuer Script Identifier, 14–5
Issuer Script Processed on Last Online Transaction, O
11–3
Offline Data Authentication, 2–2, 2–7, 2–9, 4–6,
Issuer Script Results, 14–5
5–2 to 5–3, 6–1 to 6–17, 10–7
Issuer Script Template, 14–5
Offline Enciphered PIN
issuer scripts. See Issuer-to-Card Script processing
card data, 8–5
Issuer-to-Card Script Processing, 2–5, 2–8, 2–10,
CVM processing, 8–10
14–1 to 14–11
optional terminal changes, 1–7
card data, 14–4
processing commands, 8–7
online response data, 14–5
supported CVMs, 8–1
processing, 14–8
Offline PIN processing, card data for, 8–4
processing flow, 14–10
Offline PIN Verification not Performed (PIN Try Limit
terminal data, 14–5
Exceeded), 11–7
K Offline Plaintext PIN, 8–1, 8–7, 8–10
online authorization, 10–1
keys, 11–4, 14–3
Online Authorization Indicator, 1–8 to 1–9
Keys and Certificates, Offline Data Authentication,
6–4 to 6–5 Online Authorization Not Completed (on previous
transaction), 11–3
L Online Card Authentication, 2–4
Last Online Application Transaction Register. See Last Online Card Authentication. See CAM
Online ATC Register online PIN, 8–1, 8–11
Last Online ATC Register, 9–2, 9–4 to 9–5 Online Processing, 2–4, 2–8, 2–10, 4–6, 8–10,
List of AIDs Method, 1–7, 3–4 12–1 to 12–8, 13–5, 13–11, 14–11
Lower Consecutive Offline Limit “9F14”, 9–2, 9–5 card data, 12–2
Lower Consecutive Offline Limit “9F58”, 14–7 commands, 12–4
flow, 12–7
M online response data, 12–3
MAC, 14–3, 14–9 Processing, 12–5
MAC MDK, 14–3 terminal data, 12–3
MAC Session Key, 14–3 to 14–4 online request, 12–5
MAC UDK, 14–3 online response, 12–5
magnetic stripe, 14–7 optional, 1–3
mandatory, 1–3
P
Master Data Encipherment DEA Key. See ENC MDK
Master Message Authentication Code Key. See MAC PAN, 9–2, 9–4
MDK Payment Systems Directory, 3–2
Master Message Authentication Code Session Key. See Payment Systems Environment, 3–2
MAC Session Key PDOL, 3–2 to 3–3, 4–1 to 4–3, 4–6
Maximum Target Percentage to be used for Biased Personal Identification Number. See PIN
Random Selection, 9–3 PIN CHANGE/UNBLOCK command, 2–11, 8–14, 14–6
merchant floor limit. See floor limit checking PIN Pad Secret Key, 8–6, 8–10
Merchant Forced Transaction Online, 9–4 PIN processing flow, 8–12
Message Authentication Code Keys. See MAC keys PIN Try Counter, 8–4, 8–7, 8–10, 13–8, 14–6
Message Authentication Code. See MAC PIN Try Limit, 8–4, 8–7, 11–3, 13–8
message integrity, 14–9 PIN Verification Value. See PVV
Index–4
Visa Integrated Circuit Card R
PIX, 3–2 to 3–3 Session Key Generation, 1–8

PKI. See Certificate Authority Public Key Index SFI. See Short File Identifier
Point of Sale Entry Mode. See POS Entry Mode Short File Identifier, 3–2, 5–2 to 5–3
POS device, 13–9 signature and offline PIN, 8–1, 8–11
post-issuance updates. See also Issuer-to-Card Script signature, cardholder, 13–1
Processing Signature, cryptographic, 6–5
Processing Options Data Object List. See PDOL signature, cryptographic, 6–4
processing overview, 2–1 Signed Dynamic Application Data, 6–11
Processing Restrictions, 2–3, 2–7, 2–9, 7–1, 10–7 Signed Static Application Data, 6–4, 6–8 to 6–9
card data, 7–2 Standard DDA, 2–2, 2–7, 2–9, 6–13 to 6–14
processing, 7–6 Standard Online Processing, 12–5
terminal data, 7–3 Static Data Authentication Failure Indicator. See SDA
Proprietary Application Identifier Extension. See PIX Failure Indicator
PSE. See Payment Systems Environment Static Data Authentication. See SDA
Public Key Index. See Certificate Authority Public Key stolen cards, 8–1, 14–1
Index Subsequent Related Processing
PUT DATA command, 2–12, 14–7 Card Action Analysis, 6–16, 8–14, 10–7, 14–11
PVV, 14–7 Completion, 6–17, 8–14, 11–7, 12–8, 14–11
Issuer-to-Card Script Processing, 8–14, 12–8
R
Online Processing, 6–16, 8–14
Random Transaction Selection, 9–4 Terminal Action Analysis, 6–16, 7–7, 8–14, 9–8
Read Application Data, 2–2, 2–7, 2–9, 4–4, 4–6 to 5–1,
6–16, 7–7, 8–14, 9–8, 10–7, 11–7 T
card data, 5–2 TACs, 8–14, 10–1 to 10–7, 13–6
processing, 5–3 tamper-evident device, 8–10
processing flow, 5–4 Target Percentage to be used for Random Selection,
terminal data, 5–3 9–3
READ RECORD command, 2–12, 3–3 TC, 6–14, 10–4 to 10–5, 11–2, 11–4, 11–7,
receipt, 13–1 12–4 to 12–5, 12–8 to 13–1, 13–3, 13–5 to 13–9
recommended, 1–3 Terminal Action Analysis, 2–4, 2–8, 2–10, 6–14,
Reference PIN, 8–4, 8–10, 14–6 10–1 to 10–7
Registered Application Provider Identifier. See RID card data, 10–2
required, 1–3 processing, 10–4
RID, 3–2 to 3–3, 6–4, 6–8 to 6–9, 6–13, 8–5 processing flow, 10–6
Rivest, Shamir, Adleman. See RSA terminal data, 10–3
RSA, 6–3 Terminal Action Codes. See TACs
Terminal Capabilities, 7–3, 8–6
S Terminal Country Code, 4–3, 7–3
SAD. See Signed Static Application Data terminal data
Script Processing. See Issuer-to-Card Script processing for Application Selection, 3–3
SDA, 2–2, 2–7, 2–9, 5–1, 6–1, 6–8 to 6–17 for Cardholder Verification, 8–6
processing, 6–9 for Completion, 13–4
processing flow, 6–10 for Issuer-to-Card Script Processing, 14–5
SDA failed on last transaction, 11–3 for Online Processing, 12–3
SDA Failure Indicator, 6–8, 6–16 for Processing Restrictions, 7–3
SDA key relationships, 6–5 for Terminal Action Analysis, 10–3
SDA or DDA, determining which to perform Offline for Terminal Risk Management, 9–3
Data Authentication, 6–7 Terminal Exception File, 9–4
SDA Tag List, 1–7 to 1–8 terminal floor limit, 9–3 to 9–4
secure messaging, 14–3 to 14–11 Terminal Floor Limit. See also floor limit checking
31 Oct 2001
Draft 12/18/00
SELECT command, 2–12, 3–3 to 3–5
Visa Public Index–5

U Visa Integrated Circuit Card
Terminal Risk Management, 2–3, 2–8, 2–10, 8–8, VLP Single Transaction Limit, 14–7
9–1 to 9–8, 10–7
card data, 9–2 Y
processing flow, 9–6 Y3 Authorization Response Code, 13–7
terminal data, 9–3
terminal velocity checking, 9–5, 14–7
Z
terminal velocity checking. See velocity checking, Z1 Authorization Response Code, 13–1, 13–6
terminal Z3 Authorization Response Code, 13–7
Terminal Verification Results. See TVR
terminated transactions, 1–3
Threshold Value for Biased Random Selection, 9–3
Transaction Certificate. See TC
Transaction Date, 7–3 to 7–5
transaction flow, sample, 2–6
Transaction Log, 9–3 to 9–4
Transaction PIN, 8–6, 8–10
Transaction Status Information (TSI), 9–3, 12–3, 12–6,
14–5
Transaction Type, 7–3
TSI. See Transaction Status Information
TVR, 6–8 to 6–9, 7–4 to 7–5, 8–6, 8–8, 9–3 to 9–5,
10–3 to 10–4, 12–3, 12–5 to 12–6, 13–4 to 13–6, 14–5
U
UDKs, 12–2, 12–6
UDKs. See Unique DEA Keys
Unique Data Encipherment DEA Key. See ENC UDK
Unique DEA Keys A and B. See UDKs
Unique Message Authentication Code Key. See MAC
UDK
Unpredictable Number, 6–11
UPDATE RECORD command, 2–12, 14–7
Upper Consecutive Offline Limit, 11–7
Upper Consecutive Offline Limit “9F23”, 9–2, 9–5
Upper Consecutive Offline Limit “9F59”, 14–7
V
velocity checking, card, 11–1, 11–3, 11–7, 13–8
velocity checking, terminal, 9–5
VERIFY command, 2–12, 8–7, 8–10
Visa CA Private Key. See Visa Private Key
Visa CA Public Key. See Visa Public Key
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, 2–12
Visa Private Key, 6–3 to 6–4, 6–8
Visa Public Key, 6–3, 6–8 to 6–9, 6–11, 6–13, 8–6
VLP Funds Limit, 14–7
Index–6

Visa Integrated Circuit Card Application Overview

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Visa Integrated Circuit Card Application Overview

Uploaded by

Copyright:

Available Formats

Welcome to

Visa Integrated Circuit

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 5101-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 Mandatory and Optional Functionality . . . . . . . . . . . . . . . . . 2–7

2.2.1 Card Functional Requirements . . . . . . . . . . . . . . . . . . 2–7

2.2.2 Terminal Functional Requirements . . . . . . . . . . . . . . . . 2–9

2.2.3 Command Support Requirements . . . . . . . . . . . . . . . . 2–11

2.3 Visa Low-Value Payment (VLP) Feature . . . . . . . . . . . . . . . . 2–12

2.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 2–12

Chapter 3 • Application Selection

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

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

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

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

3.5.1 Terminal Makes Application Decision . . . . . . . . . . . . . . . 3–4

3.5.2 Cardholder Makes Account Decision . . . . . . . . . . . . . . . 3–5

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

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

3.6 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6

3.7 Subsequent Related Processing . . . . . . . . . . . . . . . . . . . 3–7

Chapter 4 • Initiate Application Processing

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

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

4.4 Terminal Processing . . . . . . . . . . . . . . . . . . . . . . . . 4–3

4.5 Card Processing . . . . . . . . . . . . . . . . . . . . . . . . . 4–4

4.6 Terminal Processing . . . . . . . . . . . . . . . . . . . . . . . . 4–4