ICC EMV Administration

Welcome to Visa Integrated Circuit Card Application OverviewThe 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

Application OverviewVersion 1.4.0

Visa Integrated Circuit Card

Effective: 31 October 2001

Visa International 1998, 1999, 2001 5101-03

Visa Public

Printed on recycled paper.

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.

Draft 12/18/00i31 Oct 2001 Visa Public

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

Contents

Draft 12/18/00

Contents Visa Integrated Circuit CardApplication Overview, Version 1.4.0

ii 31 Oct 2001Visa Public

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

Draft 12/18/00

Visa Integrated Circuit CardApplication Overview, Version 1.4.0

Contents

iii31 Oct 2001 Visa Public

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



Draft 12/18/00


iv 31 Oct 2001Visa Public

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

Draft 12/18/00


Contents

v31 Oct 2001 Visa Public

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

Draft 12/18/00


vi 31 Oct 2001Visa Public

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

Draft 12/18/00


Contents

vii31 Oct 2001 Visa Public

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

Draft 12/18/00


viii 31 Oct 2001Visa Public

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

Draft 12/18/00ix31 Oct 2001 Visa Public

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

Figures

Draft 12/18/00

Figures Visa Integrated Circuit CardApplication Overview, Version 1.4.0

x 31 Oct 2001Visa Public

Draft 12/18/00xi31 Oct 2001 Visa Public

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

Tables

Draft 12/18/00

Tables Visa Integrated Circuit CardApplication Overview, Version 1.4.0

xii 31 Oct 2001Visa Public

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

Draft 12/18/001–131 Oct 2001 Visa Public

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.

Draft 12/18/00

About This Specification Visa Integrated Circuit CardApplication Overview, Version 1.4.0

1–2 31 Oct 2001Visa Public

1.1 AudienceThis 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 UpdateThis 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.

Draft 12/18/00


1.3 Terminology

1–331 Oct 2001 Visa Public

1.3 TerminologyThis 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.

Draft 12/18/00



1.4 Document StructureThis 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.

Draft 12/18/00


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.

Draft 12/18/00



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 SpecificationRevisions 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.

Draft 12/18/00


1.6 Impact Summary


1.6 Impact SummaryThe 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.

Draft 12/18/00



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.

Draft 12/18/00


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.

Draft 12/18/00



1.7 Reference MaterialsThe 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.

Draft 12/18/00


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.

Draft 12/18/00



● 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.

Draft 12/18/00


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.

Available on Visa InSite or through a Visa regional representative: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.

Available on Visa InSite or through a Visa regional representative: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.


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 OverviewThe 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.

Draft 12/18/00

Processing Overview Visa Integrated Circuit CardApplication Overview, Version 1.4.0


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.

Draft 12/18/00


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

Draft 12/18/00



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.

Draft 12/18/00


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.

Draft 12/18/00



Figure 2–1: Sample Transaction Flow

1 - If DDA2 - If Offline Enciphered PIN3 - Optional for Offline PIN4 - If Offline PIN

Mandatoryprocess

Mandatoryprocess w/

optionalsteps

KEY

Optionalprocess

Card Terminal

Initiate ApplicationProcessing

OnlineTransaction?

Application Selection

Read ApplicationData

List of SupportedApplications

Offline DataAuthenticationSDA or DDA

ProcessingRestrictions

CardholderVerification

Terminal RiskManagement

Terminal ActionAnalysis

Issuer Authentication

Online Processing

Completion

Issuer-to-Card ScriptProcessing

SELECTCommand/Response

Supported Functions& Pointers to

Application Data

Provide ApplicationRecords

Generate DynamicCryptogram

Last OnlineApplication

Transaction Counter(ATC) Register

GET PROCESSING OPTIONSCommand/Response

READ RECORDCommands/Responses

INTERNAL AUTHENTICATE 1

Command/Response

PIN Try Counter

N

Y

VERIFY Command/Response4

GET DATACommand/Response

Perform Card ActionAnalysis & Generate

ApplicationCryptogram

GENERATE APPLICATIONCRYPTOGRAM Response

Validate ARPCCryptogram

EXTERNAL AUTHENTICATECommand/Response

Apply Script

Perform Final Check& Generate Final

Cryptogram

Issuer-to-Card ScriptCommands/Responses

GENERATE APPLICATIONCRYPTOGRAM

Command/Response

GENERATE APPLICATIONCRYPTOGRAM Command

GET DATA Command/Response3

GET CHALLENGE Command/Response2Generate Unpred.

Number

Validate PIN

READ RECORDCommand/Response

Draft 12/18/00


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


● Directory Method

● Explicit Selection Method

Mandatory

Optional (EMV)

Mandatory (EMV)

Initiate Application Processing Mandatory (EMV)

Read Application Data Mandatory (EMV)

Offline Data Authentication

● SDA

● Standard DDA

● Combined DDA/AC Generation

Optional (EMV)

Optional (EMV) Conditional—If DDA supported (VIS)

Optional (EMV) Conditional—If Combined DDA/AC Generation supported (VIS)

Optional (EMV)

Processing Restrictions

● Application Version Number

● Application Usage Control

● Effective Date Check

● Expiration Date Check

Mandatory (EMV)

Mandatory (EMV)

Optional (EMV)

Optional (EMV)

Mandatory (EMV)

Cardholder Verification

● Individual CVMs

Optional (EMV) Required (VIS)

Optional (EMV) Required (VIS)

Draft 12/18/00



Terminal Risk Management

● Terminal Exception File

● Merchant Force Online

● Floor Limits

● Transaction Log

● Random Selection

● Velocity Checking

● New Card

Optional (EMV) Mandatory (VIS)

n/a (Card plays no role)





Optional (EMV) Not supported but not precluded (VIS)

Optional (VIS)

Terminal Action Analysis IACs optional (EMV); IACs required (VIS)

Card Action Analysis

● Online/offline decision

● Offline referrals

● Card Risk Management

● Advice Messages

● Application Cryptogram

Mandatory (EMV)

Mandatory (EMV)

Optional (EMV), Not supported (VIS)

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)

Optional (EMV)

Algorithm option provided (EMV)

Multiple algorithm options provided (VIS)

Online Processing

● Online Capability

● Issuer Authentication

Mandatory (EMV)

Optional (EMV)

Completion Mandatory (EMV)

Issuer-to-Card Script Processing

● Secure Messaging

Optional (EMV)

Some form is mandatory if scripts supported (EMV)

Recommended form (VIS)

Table 2–1: Card Functional Requirements (2 of 2)

Function Card Support

Draft 12/18/00




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


● Directory Method

● Explicit Selection Method

● Implicit Selection Method

Mandatory

Optional (EMV)

Mandatory (EMV)

Not used for financial interchange (EMV)

Initiate Application Processing Mandatory (EMV)

Read Application Data Mandatory (EMV)


● SDA

● Standard DDA

● Combined DDA/AC Generation

Conditional—If offline capable (EMV)

Conditional—If offline capable terminal (EMV) or if DDA supported (EMV)

Optional (EMV) Conditional—If DDA/AC Generation supported (VIS)(VIS recommends for offline capable terminals)

Optional (EMV)

Processing Restrictions

● Application Version Number

● Application Usage Control

● Effective Date Checking

● Expiration Date Checking

Mandatory (EMV)

Mandatory (EMV)

Mandatory (EMV)

Mandatory (EMV)

Mandatory (EMV)


● No CVM Required

● Fail CVM Processing

● Other CVMs (Offline PIN, Online PIN, signature, etc.)

Mandatory (EMV) with Operating Regulation exceptions (VIS)

Mandatory (EMV)

Mandatory (EMV)

Optional (EMV) with Operating Regulation exceptions (VIS)

Draft 12/18/00



Terminal Risk Management

● Terminal Exception File

● Merchant Force Online

● Floor Limits

● Transaction Log

● Random Selection

● Velocity Checking

● New Card

Conditional—If merchant controlled terminal (EMV)Some functions do not apply for online-only or offline-only terminals (EMV)

Optional (EMV)

Optional (EMV)

Mandatory (EMV)

Optional (EMV)

Conditional—If both online & offline capable (EMV)

Conditional—If offline capable

Mandatory

Terminal Action Analysis Mandatory (EMV)

Card Action Analysis n/a (card function)

Online Processing

● Online Capability

● Advice Messages

● Issuer Authentication

Optional (EMV and VIS)

Optional (EMV and VIS)

Conditional—If online capable

Completion Mandatory

Issuer-to-Card Script Processing Conditional—If online capable

Miscellaneous Functions

● Cardholder amount validation

● Voice Referrals

● Card initiated referrals

● Merchant forced acceptance

● Prompt for chip read

Recommended (EMV)

Recommended

Not supported (VIS)

Optional (EMV)

Mandatory (EMV)

Table 2–2: Terminal Functional Requirements (2 of 2)

Function Terminal Support

Draft 12/18/00




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 optional. If supported, using APPLICATION BLOCK is recommended (VIS)

Pass through from Issuer mandatory (VIS)

APPLICATION UNBLOCK Application unblocking capability is optional. If supported, using APPLICATION UNBLOCK is recommended (VIS)


CARD BLOCK Card blocking capability is recommended. CARD BLOCK command is one method (VIS)


EXTERNAL AUTHENTICATE Conditional—If Issuer Authentication supported (EMV)

Conditional—If online-capable (EMV)

GENERATE APPLICATION CRYPTOGRAM (AC)

Mandatory (EMV) Mandatory (EMV)

GET CHALLENGE Conditional—If Offline Enciphered PIN supported (EMV)

Conditional—If Offline Enciphered PIN supported (EMV)

GET DATA Optional (EMV)

Mandatory (VIS)

Conditional—If ATM or merchant controlled device (EMV)

GET PROCESSING OPTIONS Mandatory (EMV) Mandatory (EMV)

INTERNAL AUTHENTICATE Conditional—If DDA supported (EMV)

Conditional—If DDA supported (EMV)

PIN CHANGE/UNBLOCK Unblocking PIN—Conditional if Offline PIN supported. Method used may be PIN CHANGE/UNBLOCK (VIS)

PIN Change—Optional, must be in issuer controlled environment (VIS)

Performed at specialissuer-controlled devices

Draft 12/18/00



2.3 Visa Low-Value Payment (VLP) FeatureThe 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.

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 supported (EMV)

Conditional—If Offline PIN supported (EMV)

Table 2–3: Command Support Requirements (2 of 2)

Command Card Support Terminal Support


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

Draft 12/18/00

Application Selection Visa Integrated Circuit CardApplication Overview, Version 1.4.0


3.1 Card DataThe 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)

AEF contains data elements used by the application in processing.

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 (PSE)

The PSE is a DDF named “1PAY.SYS.DDF01”. The directory file designating the structure of the files beneath the PSE is known as the Payment Systems Directory.

Processing Options Data Object List (PDOL)

The PDOL is a list of tags and lengths for terminal data needed by the card. It is 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)

Draft 12/18/00


3.2 Terminal Data


3.2 Terminal DataThe terminal data elements used in Application Selection are listed and described in Table 3–2. For a detailed description of these elements and their usage, refer to the Visa Integrated Circuit Card Terminal Specification, Appendix A, Card and Issuer Data Elements Table.

3.3 CommandsSELECT

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.

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.

Draft 12/18/00



3.4 Building the Candidate ListThere 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 ApplicationIf 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.

Draft 12/18/00


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.

If the Directory Selection Method was used to build the list of applications, the card’s response to the SELECT command may indicate that the application is blocked. If this occurs, and there are more available applications on the list, the terminal should 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.

If the Directory Selection Method was used to build the list of applications, the card’s response to the SELECT command may indicate that the application is blocked. If this occurs, and there are more available applications on the list, the terminal should display “Try Again” and display the list of available applications excluding the rejected applications.

If the cardholder does not select an application, the terminal terminates the transaction.

Draft 12/18/00



3.6 Flow

Figure 3–1: Application Selection

Terminalterminates the

transation

Any mutuallysupported

applications?N

Terminalsupports

confirmation bycardholder?

Applicationsavailable without

confirmation?

Terminalidentifies

highest priorityapplication not

requiringconfirmation

Terminal supports selection

by cardholder?

T

Terminal issuesSELECT commandwith the identified

application

SuccessfulSELECT“9000”?

BTerminal proceeds toInitiate Application

Processing

Y

B

Terminal removes applicationfrom list

N

Terminal checks forcard applications

supported and buildscandidate list

SELECTcommand

Y

N

Y

T

N

N

Y

Y

TerminalCard

Terminaldisplays highest

priorityapplication on

list forconfirmation

Terminaldisplays

applications bypriority and asks

cardholder toselect

Cardholderselected

application?

Cardholderconfirms?

N

Y

Y

N

Card responds with FCI forrequested AID and “9000”(selection successful) or

“6283” (application blocked)or other SW1SW2

SELECTresponse

Draft 12/18/00




3.7 Subsequent Related ProcessingInitiate 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.


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.6 Terminal Processing

4.7 Flow

4.8 Prior Related Processing


Draft 12/18/00

Initiate Application Processing Visa Integrated Circuit CardApplication Overview, Version 1.4.0


4.1 Card DataThe card data elements used in Initiate Application Processing are listed and described in Table 4–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 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 (AIP)

A list that indicates the capability of the card to support specific functions in the 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 List (PDOL)

The PDOL is an optional list of tags and lengths for terminal data requested by the 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.

Draft 12/18/00


4.2 Terminal Data


4.2 Terminal DataThe 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.

4.3 GET PROCESSING OPTIONS CommandThe 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.

4.4 Terminal ProcessingTo 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.

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.

Draft 12/18/00



4.5 Card ProcessingUpon 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.

4.6 Terminal ProcessingThe 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

Draft 12/18/00


4.7 Flow


4.7 Flow

Figure 4–1: Initiate Application Processing Flow

Terminal issues GETPROCESSING

OPTIONS (includesdata requested by card

in PDOL)

Terminal reads PDOLfor terminal data to beprovided to the card

Card SupportsGeographical Restrictions

Check?

Card responds to GETPROCESSINGOPTIONS with

“Conditions of use notsatisfied”

NTerminal Country

Code = Issuer CountryCode?

International TransactionsAllowed?

Card determines whichrecords and files are to be

read by the terminal

Card returns AFLand AIP

N

Y

N

GET PROCESSINGOPTIONScommand

Terminal eliminates thisapplication from the listof available applications

and returns toApplication Selection

(Chapter 3)

N

Card responds to GET PROCESSING

OPTIONS with “Conditionsof use notsatisfied”?

Terminalreceives AFL and AIP

Terminal proceeds to Read Application

Data (Chapter 5)

Y

GET PROCESSINGOPTIONS response

Y

Domestic TransactionsAllowed

Y

Y

N

Card Terminal

Draft 12/18/00



4.8 Prior Related ProcessingApplication Selection

The card supplies the PDOL (if present) to the terminal as part of the FCI provided in response to the SELECT command.

4.9 Subsequent Related ProcessingRead 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.


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.


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 Cardholder Verification.

Online Processing

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 Issuer Authentication.


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



Draft 12/18/00

Read Application Data Visa Integrated Circuit CardApplication Overview, Version 1.4.0


5.1 Card DataA 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.

The terminal uses the card data structures described in Table 5–2 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.

Table 5–2: Read Application Data—Card Data


Application Elementary Files (AEF)

Card data files containing data used for application processing. An AEF consists 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.

Draft 12/18/00


5.2 Terminal Data


5.2 Terminal DataNo terminal data is used in the Read Application Data function.

5.3 READ RECORD CommandThe 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 ProcessingThe 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.

Draft 12/18/00

Read Application Data Visa Integrated Circuit CardApplication Overview, Version 1.4.0


5.5 FlowFigure 5–1 shows how Read Application Data might be performed.

Figure 5–1: Read Application Data Processing Flow

Terminal selects firstentry from AFL

Terminal completesInitiate Application

Processing

Card passes recordto terminal.

Terminal requestsrecord using READRECORD command

Terminalconcatenates datainto SDA input list

READ RECORDcommand

Record read= last record number

in AFL entry?

More AFL entries?

Terminal proceeds toOffline Data

Authentication(see Chapter 6)

Terminal selects nextAFL entry

Y

Y

N

Recordto be used for offline data

authentication?

Y

Requested record inREAD RECORD

response

Card Terminal

N

N

Draft 12/18/00




5.6 Prior Related ProcessingInitiate Application Processing

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

5.7 Subsequent Related ProcessingOffline Data Authentication

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.


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.

Draft 12/18/00

Offline Data Authentication Visa Integrated Circuit CardApplication Overview, Version 1.4.0



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)



Draft 12/18/00




6.1 Keys and CertificatesThe 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.

Draft 12/18/00



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

Draft 12/18/00




The relationship between keys, certificates, and signatures for SDA is shown in Figure 6–1.

Figure 6–1: SDA Key Relationships

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.

Visa CAPrivate Key -

SKCA

Issuer Public

Key - PKI

InitialSetup

Issuer Private

Key - SKI

Visa CAPublic Key -

PKCA

Issuer PKCertificate

(PKI signed w/ SKCA)

Personalizedon each

Card


Signed Applic.

Data (signed)with SKI)

Transaction

ICC CardApplication

ICC CardApplication

Visa CAPublic Key -

PKCA

Terminal

Terminal

- Uses PKCA to recover PKI from Issuer PK Cert.

- Uses PKI to recover

Signed Applic. Data

READ RECORD responsecontaining

Issuer CA PK IndexIssuer PK CertificateSigned Applic. Data

Issuer Certification Authority (Visa) Acquirer

Draft 12/18/00



The relationship between the data and the cryptographic keys for DDA is shown in Figure 6–2.

Figure 6–2: DDA Data—Key Relationships

Visa CAPrivate Key -

SKCA

Issuer Public

Key - PKI

InitialSetup

Issuer Private

Key - SKI

Visa CAPublic Key -

PKCA


(PKI signed w/

SKCA)

Personalizedon

each card


Transaction

Card

Card

Visa CAPublic Key -

PKCA

Terminal

- Uses PKCA to get PKIfrom Issr PK Cert.

- Uses PKI to get PKICCfrom ICC PK Cert.

- Validates static datahash in ICC PK Cert.

ICC Private

Key - SKICC

ICC Public

Key - PKICC

ICC PublicKey Cert

(PKICC signed

w/ SKI)

Card

TerminalINTERNAL AUTHENTICATE* or

GENERATE AC** responsewith Dynamic Signature

- Validates DynamicSignature using PK ICC

- Calculates Dynamic Signature using SK ICC

INTERNAL AUTHENTICATE*or first GENERATE AC**

command

READ RECORD responsewith CA PK Index,

Issuer PK Certificate,& ICC PK Certtificate

Terminal

IssuerCertificate Authority

(Visa)Acquirer

* INTERNAL AUTHENTICATEfcommand for Standard DDA

** GENERATE AC command forCombined DDA/AC Generation

Draft 12/18/00


6.2 Determining Whether to Perform SDA or DDA


6.2 Determining Whether to Perform SDA or DDAOnly 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 Interchange Profile

indicates card support for:

Terminal Supports SDA

Terminal Supports SDA and Standard

DDA

Terminal Supports SDA, Standard DDA,

and Combined DDA/AC Generation

SDA SDA SDA SDA

SDA

Standard DDA

SDA Standard DDA Standard DDA

SDA

Standard DDA

Combined DDA/AC Generation

SDA Standard DDA CombinedDDA/AC Generation

Draft 12/18/00



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 Keys

The Payment System public keys stored in the terminal and used to recover the Issuer PK Certificate from the card, which has been signed, with the Certificate Authority Private Key.

Certificate Authority (CA) Public Key Index (PKI)

Used with the RID to designate which Visa CA Public Key to use for offline data authentication.

Registered Application Identifier (RID)

A portion of the Application Identifier that identifies the Payment System.

Terminal Verification Results (TVR)

Status of processing functions as seen from the terminal perspective.

Table 6–3: Card Data Used in SDA


Certificate Authority Public Key Index (PKI)

Each Visa Public Key used for offline data authentication in SDA is identified by 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 (SAD)

The SAD is a signature enciphered with the Issuer Private Key, which contains a hash of important card data.

Draft 12/18/00


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.

Draft 12/18/00



Figure 6–3: Processing Flow for SDA

Recover Issuer Public Keyfrom Issuer PK Certificateusing Visa CA Public Key

Retrieve Visa CA PublicKey using RID and Public

Key Index

Calculate hash from Staticdata used for signing and

compare to recovered hash

Set SDA failed in the TVR ifany of the above steps are

not successful

Card Terminal

Response to Read Recordcontains Visa CA PublicKey Index, Issuer PublicKey Certificate, and SAD

Use Issuer Public Key torecover a hash of static

application data from theSAD

READ RECORDresponse

Draft 12/18/00




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 Authentication Data Object List (default DDOL)

If the card does not provide a DDOL, the terminal uses a default DDOL containing the tag for the terminal unpredictable number.

Unpredictable Number An unpredictable, transaction-unique number generated by the terminal and sent to the card in the INTERNAL AUTHENTICATE command.

Draft 12/18/00



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.

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–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 Data Object List (DDOL)

List of tags for terminal data objects to be passed to the card in DDA processing.

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.

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.

Draft 12/18/00




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.

Draft 12/18/00



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.

Draft 12/18/00




Figure 6–4: Processing Flow for DDA

Recover Issuer Public Keyfrom Issuer PK Certificateusing Visa CA Public Key

Retrieve Visa CA PublicKey using RID and CA

Public Key Index

Send INTERNALAUTHENTICATE anddynamic data to card

Calculate dynamicsignature using ICC

Private Key

Recover hash and ICCPublic Key from ICC PKCertificate using Issuer

Public Key

Calculate hash from Staticdata used for signing and

compare to recovered hash

Set DDA results in the TVRif DDA fails

INTERNALAUTHENTICATE

command

INTERNAL AUTHENTICATE response with

dynamic signature

Card Terminal

Validate dynamic signatureusing ICC Public Key

Standard DDA Only

Draft 12/18/00



6.5 Prior Related ProcessingRead Application Data

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.

6.6 Subsequent Related ProcessingTerminal 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.


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.

Draft 12/18/00




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.


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



Draft 12/18/00

Processing Restrictions Visa Integrated Circuit CardApplication Overview, Version 1.4.0


7.1 Card DataThe card data elements used in Processing Restrictions are listed and described in Table 7–1. For a detailed description of these elements and their usage, refer to the Visa Integrated Circuit Card Specification, Appendix A, Card and Issuer Data Elements Table.

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)

AUC is an optional data element. This data element indicates any restrictions set 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.

Draft 12/18/00


7.2 Terminal Data


7.2 Terminal DataThe card data elements used in Processing Restrictions are listed and described in Table 7–2. For a detailed description of these elements and their usage, refer to the Visa Integrated Circuit Card Terminal Specification, Appendix A, Card and Issuer Data Elements Table.

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.

Draft 12/18/00



7.3 Application Version NumberThe 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 ControlApplication 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 DateApplication 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.

Draft 12/18/00


7.6 Application Expiration Date


7.6 Application Expiration DateApplication 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.

Draft 12/18/00



Figure 7–1: Processing Restrictions

ApplicationVersion Number forcard and terminal

present?

Y

ApplicationVersion Numbers

Identical?

Terminal sets ICC andterminal have different

application versions bit to“1” in TVR

N

ApplicationUsage Control and

Issuer Country Codepresent?

Do anyrestrictions

apply?Y

Terminal setsrequested service not

allowed for cardproduct bit to “1” in

TVR

Y

NN

ApplicationEffective Date <Current Date?

Terminal sets application not yeteffective bit to “1” in TVRN

Y

ApplicationExpiration Date >

Current Date?N Terminal sets expired aplication

bit to “1” in TVR

Y

Terminal proceeds tocardholder verification

Y

Card Terminal

N

Draft 12/18/00





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.


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.

Draft 12/18/00

Cardholder Verification Visa Integrated Circuit CardApplication Overview, Version 1.4.0


This chapter is separated into the following sections:

8.1 Card Data

8.2 Terminal Data

8.3 Commands

8.4 Processing



Draft 12/18/00


8.1 Card Data


8.1 Card DataThe 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, Card and Issuer Data Elements Table.

Table 8–1: CVM List Processing—Card Data



Contains an indicator showing whether the card supports cardholder verification. This indicator must be set to “1”.

Cardholder Verification Method (CVM) List

A prioritized list of methods of cardholder verification for the card application. A 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 toprocess 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.

Draft 12/18/00



Table 8–2: Offline PIN Processing—Card Data


Application Default Action (ADA)

A data element used by the card to determine what action, if any, to take if offline 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.

Draft 12/18/00


8.1 Card Data


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 Index (PKI)

With the RID, designates the Visa CA Public Key to use to recover the Issuer PK Certificate.

ICC PIN Encipherment or ICC Private Key

Used to decipher the enciphered PIN after it is received at the card. Stored in a secret location on the card.

ICC PIN Encipherment or ICC Public Key (PK) Certificate

Encrypted with the Issuer Private Key. Contains the card’s public key to be used in PIN encipherment.

ICC PIN Encipherment or ICC Public Key Exponent

Used in the algorithm that deciphers the enciphered PIN.

ICC PIN Encipherment or ICC Public Key Remainder

Contains the portion, if necessary, of the public key that does not fit into the public 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 Identifier (RID)

Used by the terminal with the Certificate Authority Public Key Index to identify the Visa CA Public Key to be used to recover the Issuer PK Certificate.

Draft 12/18/00



8.2 Terminal DataThe 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 Identification Number (PIN) Data

Transaction PIN enciphered at the PIN pad for online verification or for offline verification.

Personal Identification Number (PIN) Pad Secret Key

Secret key used by the PIN pad to encipher the entered offline PIN and by the 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.


Indicators are set in the TVR for the following conditions:

● 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 Identification Number (PIN)

Contains data entered by the cardholder for PIN verification.

Visa CA Public Keys Must be present if the terminal supports Offline Enciphered PIN.

Draft 12/18/00


8.3 Commands


8.3 CommandsThe 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.

Draft 12/18/00



8.4 ProcessingCardholder 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.

Draft 12/18/00


8.4 Processing


Figure 8–1: CVM List Processing Flow

Card supportscardholder

verification?

Terminal selects firstCVM in CVM List

Cardprovided CVM

List?

CVM Listconditionsatisfied?

Terminalrecognizes &

supportsCVM?

CVM = No CVMRequired?

CVM = FailCVM?

Y

Y

Terminal sets chipdata missing in TVR

CVM is signature.Terminal prints

receipt w/ signatureline

N

N

YAny more CVM

entries?

Terminal setsunrecognized CVM

code in TVR

CVMCode = go tonext CVM?

NTerminal selects next

CVM in CVM List

B

N

Y

A

N

Y

B

C

A

N

N

Terminal proceeds toTerminal RiskManagement

Terminal sets“cardholder

verification notsuccessful” in TVR

Y

CVM = PIN?

Perform PINProcessing(Figure 8-2)

N

Y

Y

C

N

TerminalCard

Terminal uses defaultCVM according to

Visa OperatingRegulations

Y

D

D

Draft 12/18/00



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.

Draft 12/18/00


8.4 Processing


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.

Draft 12/18/00



The following flow gives an overview of the steps in PIN processing.

Figure 8–2: PIN Processing Flow (1 of 2)

CVM is on l ine oroffline PIN

Prompt for PIN Entry

Is PIN PADoperable?

Terminal proceeds toTerminal RiskManagemen t(Chapter 9)

Perform PINProcessing

PIN entered?

N

Offl ine orOnl ine PIN?

Y

Encipher PIN andinclude in

author izat ion request

Onl inePIN

Offl ine PINProcessing

Issue GET DATAcommand request ing

PIN Try Counter(opt ional step)

PIN TryCounter re turned

and = 0?

Response to GETDATA is “NotSuppor ted ”

GETDATA

command

Per fo rm CVMCode act ion

(see A inFigure 8-1)

Y

Card a l lows GETDATA o f P IN Try

Counter?

N

Y

Type of PIN?

N

Y

Offl ine PIN

N

Onl inePIN Off l ine

PIN

Termina lCard

Response to GETDATA is PIN Try

Counte r

Get Dataresponse

returnfrom A onnext page)





Draft 12/18/00


8.4 Processing


Figure 8–3: PIN Processing Flow (2 of 2)

B

OfflineEnciphered

PIN?

Offline PINProcessing

Issue VERIFYcommand with PIN

Card generatesunpredictable number

PIN TryLimit AlreadyExceeded?

YEntered

PIN = ReferencePIN?

Decrement PIN TryCounter by 1.

PIN Try LimitExceeded?

ADA“If PIN Try Limitexceeded, block

applic” = 1?

Card blocksapplication

Y

GETCHALLENGE

command

Y

VERIFYcommand

w/ PIN

N

Reset PIN TryCounter to PIN Try

Limit

Y

Set VERIFY returncode to Successful

Completion

Y

Set VERIFY returncode to Fail with no

retries remaining

Set VERIFY returncode to Fail withretries remaining

Return VERIFYcommand response

to terminal

VERIFYsuccessful?

VERIFYresponse

Terminal proceeds toTerminal RiskManagement(Chapter 9)

PIN Try LimitExeeded?

N

Return toPIN PromptFigure 8-2

A

N

PerformCVM Code

action

Y

B

GET CHALLENGEresponse

w/ unpred. number

N

N

Encipher PIN usingunpred. number &

ICC PINEncipherment (orICC) Public Key

N(Plaintext

PIN)

Y

Card Terminal

Enciphered PIN?

Decipher PIN usingICC PIN

Encipherment (orICC) Private Key

Y

N

N

Draft 12/18/00



8.5 Prior Related ProcessingInitiate Application Processing

The Application Interchange Profile (AIP), which indicates whether the card supports cardholder verification, is retrieved from the card.

Read Application Data

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.


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.


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



Draft 12/18/00

Terminal Risk Management Visa Integrated Circuit CardApplication Overview, Version 1.4.0


9.1 Card DataThe card data elements used in Terminal Risk Management are listed and described in Table 9–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 9–1: Terminal Risk Management—Card Data


Application Primary Account Number (PAN)

Valid cardholder account number used in terminal exception file checking.

Application Transaction Counter (ATC)

A count of the number of transactions processed by the card since 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.

Draft 12/18/00


9.2 Terminal Data


9.2 Terminal DataThe 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, Appendix A, Card and Issuer Data Elements Table.

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 be used for Biased Random Selection

Value used for random selection of transactions for online processing.

Target Percentage to be used 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.


A series of indicators in which the results of offline processing from a terminal perspective are recorded. It is used to record the results of all terminal risk management checks.

Threshold Value for Biased 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 (TSI)

Indicates the functions performed by the terminal. This data element is not provided in the online authorization and clearing messages but is used by the terminal to indicate that terminal risk management was performed.

Draft 12/18/00



9.3 GET DATA CommandThe 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 FileIf 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 OnlineAt 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 CheckingFloor 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 SelectionTerminals 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.

Draft 12/18/00


9.8 Terminal Velocity Checking


9.8 Terminal Velocity CheckingVelocity 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 CheckingIn 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

Draft 12/18/00



Figure 9–1: Terminal Risk Management Processing Flow (1 of 2)

B

Terminal exceptionfile present?

Y

Card appears onexception file?

Terminal sets card appearson terminal exception file bit

to “1” in TVR

Y

Merchantelected to force

transactiononline?

Y

Terminal sets merchantforced transaction online bit

to “1” in TVR

N

N

Log EntryPresent that

matches currenttransaction?

A

Transaction amount >terminal floor limit?

Amount,authorized + amount in

log > terminalfloor limit?

N

Y

Terminal sets transactionexceeds floor limit bit to “1”

in TVR

Y

Y

N

Terminalrandomly selects

transaction for onlineprocessing?

Terminal sets transactionselected randomly foronline processsing bit

to “1” in TVR

Y

N

Transactionlog present in terminal?

Y

NN

TerminalCard

A

N

Draft 12/18/00


9.9 New Card Checking


Figure 9–2: Terminal Risk Management Processing Flow (2 of 2)

Lower and UpperConsecutive Offline Limits

read by terminal?

Terminal issues GETDATA to obtain ATCand Last Online ATC

Register

Y

Both ATC and LastOnline ATC Register

returned?

Terminal sets ICC DataMissing bit to “1” in TVR

ATC minusLast Online ATC Register

> Lower ConsecutiveOffline Limit?

Y Terminal sets both LowerConsecutive Offline Limit

Exceeded and UpperConsecutive Offline Limit

Exceeded bits to “1” in TVR

Terminal sets LowerConsecutive Offline Limit

Exceeded bit to “1” in TVR

ATCminus Last Online

ATC Register > UpperConsecutive Offline

Limit

Terminal sets UpperConsecutive Offline Limit

Exceeded bit to “1” in TVR

Y

N

B

LastOnline ATC Register

= 0

Y

N

Terminal sets New Cardbit in TVR

Card responds to GETDATA

command with ATC andLast Online ATC Register

Terminal proceeds toTerminal Action Analysis

(Chapter 10)

TerminalCard

Y

GET DATAcommand

GET DATAresponse

N

N

N

Draft 12/18/00




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


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



Draft 12/18/00

Terminal Action Analysis Visa Integrated Circuit CardApplication Overview, Version 1.4.0


10.1 Card DataThe 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.

The card data element shown in Table 10–2 is used in cryptogram processing.

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.

Table 10–2: Request Cryptogram Processing—Card Data


Card Risk Management Data Object List 1 (CDOL1)

The CDOL1 contains the tags and lengths of the terminal data objects that are needed by the card to generate the first application cryptogram and for other processing.

Draft 12/18/00


10.2 Terminal Data


10.2 Terminal DataThe 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.

The terminal data elements described in Table 10–4 are used in cryptogram processing.

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.


The TVR is a series of bits, which are set during transaction processing to represent offline processing results.

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.

Draft 12/18/00



10.3 GENERATE APPLICATION CRYPTOGRAM (AC) CommandThe 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 ProcessingTerminal 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.

Draft 12/18/00


10.4 Processing


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.

Draft 12/18/00



10.4.3 Processing Flow

Figure 10–1 shows how Terminal Action Analysis might be performed.

Figure 10–1: Terminal Action Analysis Flow

Proceed to CardAction Analysis

(See Chapter 11)

Any transactionconditions which card

or terminal haveset to Decline?

Anytransaction

conditions which cardor terminal have

set for OnlineAuth?

Request cryptogram from card

GENERATE ACcommand

with CDOL1 data

Online capableterminal?

Anytransaction

conditions that the cardor terminal have set to

Decline if noonline?

N

Y

Y

N

Y

Y

N

Card Terminal

N

Cryptogram type =AAC

(Decline)

Cryptogram type =TC

(Approve)

Cryptogram type =ARQC

(Send Online)

Draft 12/18/00





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.

10.6 Subsequent Related ProcessingCard Action Analysis

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.


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.3 GENERATE APPLICATION CRYPTOGRAM (AC) Command

11.4 Processing

11.5 Flow



Draft 12/18/00

Card Action Analysis Visa Integrated Circuit CardApplication Overview, Version 1.4.0


11.1 Card DataThe 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.

11.2 Terminal DataNo terminal data is used during Card Action Analysis.

11.3 GENERATE APPLICATION CRYPTOGRAM (AC) CommandThe 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.

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 Management Data Object List (CDOL1)

The terminal provides the data requested by the card in the CDOL1. Refer to the Visa Integrated Circuit Card Specification, Appendix E, Cryptogram Versions Supported, for a list of data required.

Draft 12/18/00


11.4 Processing


11.4 ProcessingAt 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

Draft 12/18/00



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.

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).

Table 11–2: Card Response to GENERATE AC Command

Card Responds

AAC ARQC TC

Terminal Requests

AACDecline — —

ARQCDecline Go Online —

TCDecline Go Online Approve

Draft 12/18/00


11.4 Processing


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.

Draft 12/18/00



11.5 Flow

Figure 11–1: Card Action Analysis

Checks previous transactionprocessing:- Online Auth not completed- Issuer Authen. failed- SDA or DDA failed- Issuer Script processed

Terminal during TerminalAction Analysis requests acryptogram (AAC, ARQC or

TC) for the first time

TerminalRequested Decline

(AAC)?

Sets indicators based uponresults

Card Response =Decline (AAC)

CardResponse = Decline

(AAC)?

Terminal requestedapproval (TC)

N

Card Response = GoOnline (ARQC)?

N

Terminal proceeds to OnlineProcessing

Card Terminal

Checks new card & velocity- Cons. Offline Transactions- Cons. Offline Txns (Int'l)- Cons. Offline Txns (Int'l—Country)- Cum. Offline Txn. Amount- Cum. Offline Txn. Amount (Dual Currency)

Uses above results todetermine card response(approve, decline, or go

online)

GEN AC response =Approve (TC)

Respond to GENERATEAC

Y

D

D

D

First GENERATE AC command

Terminal requested Go Online

N

Y

Combined DDA/ACGeneration?

GEN AC response =Go Online (ARQC)

Y

N

Y

Create DynamicSignature of ARQC or

TC

First GENERATEAC response

Y

Y

N

(ARQC)?

Draft 12/18/00





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

11.7 Subsequent Related ProcessingCompletion

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


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



Draft 12/18/00

Online Processing Visa Integrated Circuit CardApplication Overview, Version 1.4.0


12.1 Card DataThe 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.

The card uses the card data described in Table 12–2 during Issuer Authentication.

Table 12–1: Online Processing—Card Data


GENERATE APPLICATION CRYPTOGRAM (AC) response data

This response data includes the following:

● Cryptogram Type (an Authorization Request Cryptogram (ARQC) if transaction is to be authorized online)

● Application Cryptogram

● Application Transaction Counter (ATC)

● Issuer Application Data


The AIP received during Initiate Application Processing contains a bit that indicates whether the card supports Issuer Authentication.

Table 12–2: Online Processing Issuer Authentication—Card Data


Authorization Request Cryptogram (ARQC)

The cryptogram generated by the card earlier in the transaction. The ARQC and 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 Indicator

A bit that is set if Issuer Authentication fails.

Draft 12/18/00


12.2 Terminal Data


12.2 Terminal DataThe 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.

12.3 Online Request and Response DataThe 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–3: Online Processing—Terminal Data



Contains a bit that is set when Issuer Authentication is unsuccessful.


Contains a bit that is set when Issuer Authentication is performed.

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.

Draft 12/18/00



12.4 CommandsThe 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.

Draft 12/18/00


12.5 Processing


12.5 ProcessingStandard 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.

Draft 12/18/00



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.

Draft 12/18/00


12.5 Processing


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

Send transactiononline for

authorization

Terminal sets IssuerAuth. results

indicators

Card Action Analysis(see Chapter 11)

Card sets cryptogramto send online,

approve offline, ordecline offline

AAC (declinecryptogram)returned?

GENERATE ACcommandresponse

Perform onlineauthorization

processing andreturn response

Issuer Authenticationto be performed?

Card performs IssuerAuthentication, sets IAresults indicators, and

returns results

EXTERNALAUTHENTICATE

command

Y

Terminal proceeds toCompletion

(see chapter 13)

Terminal proceedsto Completion

(see chapter 13)

N

N

Card TerminalOnline

AuthorizationSystems

EXTERNALAUTHENTICATE

commandresponse

OnlineResponse

CombinedDDA/Gen. AC

requested?

Valid DynamicSignature?

Y

Y

Terminal indicatesin TVR DDA/ACGeneration failed

N

OnlineResponse

ARQCreturned?

N

Y

AY

A

N

Draft 12/18/00



12.6 Prior Related ProcessingCard Action Analysis

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

12.7 Subsequent Related ProcessingCompletion

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.


If the online response contains an Issuer Script, these post-issuance updates are applied.


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.

Draft 12/18/00

Completion Visa Integrated Circuit CardApplication Overview, Version 1.4.0


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


Draft 12/18/00


13.1 Card Data


13.1 Card DataThe 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.


A count of card transactions.

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.

Draft 12/18/00



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.

13.2 Terminal DataThe 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.

13.3 GENERATE Application Cryptogram (AC) CommandThe 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.

Table 13–2: Completion—Card Data (Partial List)


Application Default Action (ADA)

A Visa proprietary data element indicating the action a card should take when 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.

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.


Contains indicators that are set to record offline processing results, such as SDA failure or floor limit exceeded, from a terminal perspective.

Draft 12/18/00


13.4 Processing


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 ProcessingCompletion 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.

Draft 12/18/00



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.

Draft 12/18/00


13.4 Processing


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.

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.

Table 13–4: Authorization Response Code for Offline Action Taken

Terminal Requests

Authorization Response Code Transaction Disposition

TC Y3 Unable to go online (offline approved)

AAC Z3 Unable to go online (offline declined)

Draft 12/18/00



● 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).

Draft 12/18/00


13.4 Processing


● 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.

Draft 12/18/00



13.5 Flow

Figure 13–1: Completion

Terminal analyzes firstGENERATE AC

response

Card receives FinalGenerate AC

Transactioncompleted

online?

Set AuthorizationResponse Code to

Y1 (approve) orZ1 (decline) based

on card response andresults of Combined

DDA/AC Generation ifperformed

Perform TerminalAction Analysis usingIAC & TAC - Default

Set AuthorizationResponse Code toY3 (approval) or

Z3 (decline)

N

Y

Set ApplicationCryptogram to TC(approval) or AAC

(decline)

Terminal requests AACor TC in Final

GENERATE AC

Card responds to FinalGENERATE AC with TC

(approve) or AAC(decline)

FinalGENERATE AC

Command

Auth Resp.Code = Y3 or

Z3 (Unable to goonline)?

Card may decline basedupon card risk

management results

Card mayconvert onlineapproval to adecline based

on IssuerAuthentication

results

Card performs card riskmanagement checks for

the upper offline limit, newcard, and PIN Try Limitexceeded previously

Card may resetcounters and

indicatorsbased uponIssuer Auth

results

N

Y

Terminal receivesFinal GENERATE AC

response

FinalGENERATE AC

Response

Terminal processesIssues Script if inauth. response

Terminal completestransaction

Card returnedARQC?

Y

N

A

A

Card Terminal

Draft 12/18/00




13.6 Prior Related ProcessingOnline 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.


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.

Draft 12/18/00

Issuer-to-Card Script Processing Visa Integrated Circuit CardApplication Overview, Version 1.4.0


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



Draft 12/18/00


14.1 Script-Related Keys


14.1 Script-Related KeysThe 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.

Draft 12/18/00



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 DataThe 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



The ATC is used in the generation of the Message Authentication Code (MAC) 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 Counter

The Issuer Script Command Counter is used to count the Script Update 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.

Draft 12/18/00


14.3 Terminal Data


14.3 Terminal DataThe 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.

14.4 Online Response DataThe data elements described in Table 14–3 are included in the issuer script received in the online response from the issuer.

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.


The TVR contains indicators that are set if Issuer Script processing fails.


The TSI contains an indicator that is set if an issuer script is processed.

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.

Draft 12/18/00



14.5 CommandsThe 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.

Draft 12/18/00


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.

Draft 12/18/00



14.6 ProcessingIssuer-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.

Draft 12/18/00


14.6 Processing


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.

Draft 12/18/00



14.7 Processing FlowFigure 14–1 illustrates how Issuer-to-Card Script Processing might be performed.

Figure 14–1: Issuer-to-Card Script Processing

Terminal completesOnline Processingand Completion

Card processescommand includingperforming secure

messaging

Terminal sendscommand to card

Anothercommandpresent?

Terminal completestransactionprocessing

Issuer Scriptpresent inresponse?

Commandprocessingsuccessful?

Terminal sets IssuerScript Processing

Performed in TSI bit

Terminal parses outIssuer Scriptcommand in

sequential order

Terminal sets ScriptProcessing Failed in

TVR bit

Card returnscommand responsewith response code

Y

N

Y

Another scriptpresent?

N

Card sets responsecode to show error

N

Card sets responsecode for successY

Responsecode shows

error?

Y

N

Y

Card Terminal

ScriptCommand

ScriptCommandResponse

N

Draft 12/18/00




14.8 Prior Related ProcessingOnline Processing

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

14.9 Subsequent Related ProcessingCard 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.

Draft 12/18/00A–131 Oct 2001 Visa Public

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

Draft 12/18/00

Acronyms Visa Integrated Circuit CardApplication Overview, Version 1.4.0

A–2 31 Oct 2001Visa Public

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

Acronym Meaning

Draft 12/18/00


Acronyms

A–331 Oct 2001 Visa Public

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

Acronym Meaning

Draft 12/18/00



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

Acronym Meaning

Draft 12/18/00


Acronyms

A–531 Oct 2001 Visa Public

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

Acronym Meaning

Draft 12/18/00



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)

Acronym Meaning

Draft 12/18/00Glossary–131 Oct 2001 Visa Public

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.

Draft 12/18/00

Glossary Visa Integrated Circuit CardApplication Overview, Version 1.4.0

Glossary–2 31 Oct 2001Visa Public

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.

Draft 12/18/00


BASE I Authorization System

Glossary–331 Oct 2001 Visa Public

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.

Draft 12/18/00



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.

Draft 12/18/00


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.

Draft 12/18/00



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.

Draft 12/18/00


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.

Draft 12/18/00



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.

Draft 12/18/00


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.

Draft 12/18/00



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.

Draft 12/18/00


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.

Draft 12/18/00



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.

Draft 12/18/00Index–131 Oct 2001 Visa Public

AAAC, 10–4 to 10–5, 11–2, 11–4, 11–7, 12–8 to 13–1,13–3, 13–5 to 13–9, 14–6

AC. See Application CryptogramADA. See Application Default ActionADF. See Application Definition FileAEF. See Application Elementary FilesAFL. See Application File LocatorAID, 3–2 to 3–3AIP. See Application Interchange ProfileAmount X, 8–3Amount Y, 8–3Amount, Authorized, 9–3 to 9–4Application Authentication Cryptogram. See AACAPPLICATION BLOCK command, 2–11, 14–6Application Cryptogram, 6–11 to 6–12, 10–4, 11–2,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–8Application Definition File, 3–2Application Effective Date, 7–2, 7–4Application Elementary Files, 3–2, 5–2Application Expiration Date, 7–2, 7–5Application File Locator, 4–1 to 4–2, 4–4, 5–2 to 5–3Application Identifier. See AIDApplication Interchange Profile, 4–1 to 4–2, 4–4, 8–3, 8–8, 9–1, 12–2

Application PAN. See PANApplication Primary Account Number. See PANApplication Selection, 1–7, 2–1, 2–7, 2–9, 3–1 to 3–7, 4–4, 4–6, 14–6

card data, 3–2functions, 3–1identifying and selecting the application, 3–4processing flow, 3–6terminal data, 3–3

Application Selection Indicator, 1–7, 3–3Application Transaction Counter. See ATCAPPLICATION UNBLOCK command, 2–11, 8–14,14–6

Application Usage Control, 7–2, 7–4 to 7–5

Application Version Number, 7–4Application Version Number (‘9F08’), 7–2Application Version Number (‘9F09’), 7–3ARPC, 12–2 to 12–4, 12–6ARQC, 6–14, 10–4 to 10–5, 11–2, 11–4, 12–2 to 12–6, 12–8 to 13–1, 13–3

ATC, 4–4, 9–2, 9–4 to 9–5, 12–2, 13–3, 14–4ATM, 1–7, 13–9AUC. See Application Usage ControlAuthorization Request Cryptogram. See ARQCAuthorization Response Code, 12–2 to 12–3, 12–6,13–1, 13–4, 13–6

Authorization Response Cryptogram. See ARPCauthorization response message, 14–8

Bbiometrics, 8–1

CCA Public Key Index. See Certificate Authority Public Key Index

candidate list, building the, 3–4Card Action Analysis, 2–4, 2–8, 2–10, 6–14, 10–1,11–1 to 11–7, 12–4, 12–8, 13–5

card data, 11–2processing, 11–3processing flow, 11–6terminal data, 11–2

CARD BLOCK command, 2–11, 14–6card data

for Application Selection, 3–2for Card Action Analysis, 11–2for Completion, 13–4for Initiate Application Processing, 4–2 to 4–3for Issuer-to-Card Script processing, 14–4for Online Processing, 12–2for Processing Restrictions, 7–2for Read Application Data, 5–2for Terminal Action Analysis, 10–2for Terminal Risk Management, 9–2

Index

Draft 12/18/00

D Visa Integrated Circuit CardApplication Overview, Version 1.4.0

Index–2 31 Oct 2001Visa Public

card reader, 8–10Card Risk Management, 11–3, 13–8Card Risk Management checks, 11–3, 11–7Card Risk Management Data Object List 2. See CDOL2

Card Risk Management Data Object List. See CDOL1card velocity checking. See velocity checking, cardCard Verification Results. See CVRCard Verification Value. See CVVcardholder confirmation, 3–5cardholder selection, 3–4 to 3–5Cardholder Verification, 2–3, 2–7, 2–9, 4–6,8–1 to 8–14, 10–7

card data, 8–3CVM List Processing, 8–8CVM Processing, 8–10processing, 8–8

Cardholder Verification Method List. See CVM ListCardholder Verification Method. See CVM processingCardholder Verification Value. See CVVCDOL1, 10–2 to 10–4, 11–2 to 11–3, 11–7CDOL2, 13–4Certificate Authority, 6–3Certificate Authority Public Key Index, 6–4, 6–8 to 6–9, 6–13, 8–5

Certificate Serial Number, 6–13CID. See Cryptogram Information DataCombined DDA/AC Generation, 1–7 to 1–8, 2–2, 2–7, 2–9, 6–7, 6–11, 6–14, 11–5, 12–4 to 12–5,12–8 to 13–1, 13–4 to 13–5

online processing, 12–5Combined DDA/AC Generation failure, 6–17,13–5 to 13–6

command support requirements, 2–11commands

APPLICATION BLOCK, 14–6APPLICATION UNBLOCK, 14–6CARD BLOCK, 14–6EXTERNAL AUTHENTICATE, 12–4, 13–11GENERATE AC, 10–4, 11–2, 12–4, 13–4GET CHALLENGE, 8–7GET DATA, 8–7, 9–4GET PROCESSING OPTIONS, 4–3INTERNAL AUTHENTICATE, 6–13PIN CHANGE/UNBLOCK, 14–6PUT DATA, 14–7READ RECORD, 5–3UPDATE RECORD, 14–7VERIFY, 8–7

Completion, 2–5, 2–8, 2–10, 12–5 to 12–6,13–1 to 13–11

card data, 13–4processing flow, 13–5terminal data, 13–4transaction flow example, 13–10

Consecutive Transaction Limit (International), 14–7Consecutive Transaction Limit(International—Country), 14–7

credit, 12–1credit risk, 14–1Cryptogram Information Data, 6–12, 11–5, 13–3cryptogram type, 11–3 to 11–4, 12–2, 12–4, 12–8, 13–7cryptogram version 14, 1–8Cumulative Total Transaction Amount Limit, 14–7Cumulative Total Transaction Amount Limit (Dual Currency), 14–7

Cumulative Total Transaction Amount Upper Limit, 1–9, 14–7

Currency Conversion Factor, 14–7CVM Code, 8–3, 8–8CVM Conditions, 8–3CVM Entry, 8–8CVM List, 1–7 to 1–8, 2–3, 8–1, 8–3, 8–8CVM List processing, 8–3, 8–8

card data, 8–3processing flow, 8–9

CVM Type, 8–3CVR, 6–16, 8–4, 12–2, 12–6, 13–3, 14–4

DData Authentication Code (DAC), 1–7data confidentiality, 14–9Data encipherment, 14–3Data Encipherment Session Key, 14–3 to 14–4DDA, 2–2, 5–1, 6–1, 6–11 to 6–17

card data, 6–12processing flow, 6–15terminal data, 6–11

DDA failed on last transaction, 11–3DDA Failure Indicator, 6–12, 6–16DDA key relationships, 6–6DDF. See Directory Definition FileDDOL, 6–12Dedicated File Name. See DF Namedefault CVM, 2–3Default DDOL, 6–11DES, 11–4, 14–3DES keys, 11–4, 14–3

Draft 12/18/00


E

Index–331 Oct 2001 Visa Public

Directory Definition File, 3–2Directory File, 3–2Directory Selection Method, 1–7, 3–4 to 3–5Dynamic Data Authentication Failure Indicator. See DDA Failure Indicator

Dynamic Data Authentication. See DDAdynamic signature, 6–11, 6–14, 11–5, 12–4 to 12–5

EEMV, 1–3, 1–6 to 1–7EMV documentation, 1–11ENC MDK, 14–3ENC UDK, 14–3Enciphered PIN Data, 8–6Europay, MasterCard, Visa. See EMVExpiration Date. See also Application Expiration DateEXTERNAL AUTHENTICATE command, 2–11, 12–4, 12–6

FFail CVM, 8–11FCI. See File Control InformationFile Control Information, 3–2, 4–2 to 4–3floor limits, 9–4fraud risk, 12–1, 14–1functional overview, 2–1functional requirements

card, 2–7miscellaneous terminal, 2–10terminal, 2–9

functionsCard Action Analysis, 11–1Cardholder Verification, 8–1Completion, 13–1Issuer-to-Card Script Processing, 14–1Offline Data Authentication, 6–1Online Processing, 12–1Processing Restrictions, 7–1Read Application Data, 5–1Terminal Action Analysis, 10–1Terminal Risk Management, 9–1

functions, mandatory and optional, 2–7

GGENERATE AC command, 2–11, 6–14, 6–16, 12–2, 12–4 to 12–5, 13–3 to 13–9, 14–6, 14–8

Terminal Action Analysis, 10–3 to 10–4,11–2 to 11–5, 11–7

GENERATE APPLICATION CRYPTOGRAM. See GENERATE AC command

Geographic Indicator, 4–2

Geographic Restrictions, 4–4GET CHALLENGE command, 2–11, 8–7, 8–10GET DATA command, 2–11, 8–7, 8–10, 9–4 to 9–5GET PROCESSING OPTIONS command, 2–11, 4–1, 4–3 to 4–5

Hhash, 6–9, 6–13, 12–5

IIACs, 8–14, 10–1 to 10–7, 13–6ICC Dynamic Number, 1–7, 6–12ICC key data, 8–11ICC PIN Encipherment key data, 8–11ICC PIN Encipherment Private Key, 8–5ICC PK Certificate, 6–3 to 6–5, 6–12 to 6–13ICC Private Key, 6–4 to 6–5, 6–11 to 6–14, 11–5ICC Public Key, 1–8, 2–2, 6–4 to 6–5, 6–13 to 6–14,12–5

ICC Public Key Certificate. See ICC PK CertificateICC Public Key Exponent, 6–12ICC Public Key Remainder, 6–12Initiate Application Processing, 2–2, 2–7, 2–9, 3–7,4–1, 8–14

card data, 4–2 to 4–3card processing, 4–4functions, 4–1processing flow, 4–5terminal processing, 4–3 to 4–4

INTERNAL AUTHENTICATE command, 2–11, 6–13ISO documentation, 1–10Issuer Action Codes. See IACsIssuer Application Data, 12–2, 13–3Issuer Authentication, 2–5, 12–5 to 12–6, 13–1, 13–5, 13–7 to 13–8, 14–8 to 14–9

Issuer Authentication Data, 12–3, 12–5Issuer Authentication Failure Indicator, 12–2, 12–6Issuer Authentication Failure on Last Transaction, 11–3

Issuer Country Code, 4–2Issuer Country Code “5F28”, 7–2issuer host, 12–1, 12–7Issuer PK Certificate, 6–3, 6–8 to 6–9, 6–13Issuer Private Key, 6–4 to 6–5, 6–8Issuer Public Key, 1–8, 2–2, 6–3, 6–9, 6–11, 6–13Issuer Public Key Certificate. See Issuer PK CertificateIssuer Public Key Component, 6–4Issuer Public Key data, 8–5Issuer Public Key Exponent, 6–8Issuer Public Key Remainder, 6–4, 6–8issuer script, 12–3, 12–5, 13–9

Draft 12/18/00

K Visa Integrated Circuit CardApplication Overview, Version 1.4.0


Issuer Script Command Counter, 14–4issuer script commands, 14–5Issuer Script Failure Indicator, 14–4Issuer Script Identifier, 14–5Issuer Script Processed on Last Online Transaction, 11–3

Issuer Script Results, 14–5Issuer Script Template, 14–5issuer scripts. See Issuer-to-Card Script processingIssuer-to-Card Script Processing, 2–5, 2–8, 2–10, 14–1 to 14–11

card data, 14–4online response data, 14–5processing, 14–8processing flow, 14–10terminal data, 14–5

Kkeys, 11–4, 14–3Keys and Certificates, Offline Data Authentication,6–4 to 6–5

LLast Online Application Transaction Register. See Last Online ATC Register

Last Online ATC Register, 9–2, 9–4 to 9–5List of AIDs Method, 1–7, 3–4Lower Consecutive Offline Limit “9F14”, 9–2, 9–5Lower Consecutive Offline Limit “9F58”, 14–7

MMAC, 14–3, 14–9MAC MDK, 14–3MAC Session Key, 14–3 to 14–4MAC UDK, 14–3magnetic stripe, 14–7mandatory, 1–3Master Data Encipherment DEA Key. See ENC MDKMaster Message Authentication Code Key. See MAC MDK

Master Message Authentication Code Session Key. See MAC Session Key

Maximum Target Percentage to be used for Biased Random Selection, 9–3

merchant floor limit. See floor limit checkingMerchant Forced Transaction Online, 9–4Message Authentication Code Keys. See MAC keysMessage Authentication Code. See MACmessage integrity, 14–9

Nnew card, 9–5, 11–3, 11–7, 13–8No CVM Required, 8–11

OOffline Data Authentication, 2–2, 2–7, 2–9, 4–6,5–2 to 5–3, 6–1 to 6–17, 10–7

Offline Enciphered PINcard data, 8–5CVM processing, 8–10optional terminal changes, 1–7processing commands, 8–7supported CVMs, 8–1

Offline PIN processing, card data for, 8–4Offline PIN Verification not Performed (PIN Try Limit Exceeded), 11–7

Offline Plaintext PIN, 8–1, 8–7, 8–10online authorization, 10–1Online Authorization Indicator, 1–8 to 1–9Online Authorization Not Completed (on previous transaction), 11–3

Online Card Authentication, 2–4Online Card Authentication. See CAMonline PIN, 8–1, 8–11Online Processing, 2–4, 2–8, 2–10, 4–6, 8–10,12–1 to 12–8, 13–5, 13–11, 14–11

card data, 12–2commands, 12–4flow, 12–7online response data, 12–3Processing, 12–5terminal data, 12–3

online request, 12–5online response, 12–5optional, 1–3

PPAN, 9–2, 9–4Payment Systems Directory, 3–2Payment Systems Environment, 3–2PDOL, 3–2 to 3–3, 4–1 to 4–3, 4–6Personal Identification Number. See PINPIN CHANGE/UNBLOCK command, 2–11, 8–14, 14–6PIN Pad Secret Key, 8–6, 8–10PIN processing flow, 8–12PIN Try Counter, 8–4, 8–7, 8–10, 13–8, 14–6PIN Try Limit, 8–4, 8–7, 11–3, 13–8PIN Verification Value. See PVV

Draft 12/18/00


R

Index–531 Oct 2001 Visa Public

PIX, 3–2 to 3–3PKI. See Certificate Authority Public Key IndexPoint of Sale Entry Mode. See POS Entry ModePOS device, 13–9post-issuance updates. See also Issuer-to-Card Script Processing

Processing Options Data Object List. See PDOLprocessing overview, 2–1Processing Restrictions, 2–3, 2–7, 2–9, 7–1, 10–7

card data, 7–2processing, 7–6terminal data, 7–3

Proprietary Application Identifier Extension. See PIXPSE. See Payment Systems EnvironmentPublic Key Index. See Certificate Authority Public Key Index

PUT DATA command, 2–12, 14–7PVV, 14–7

RRandom Transaction Selection, 9–4Read 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


READ RECORD command, 2–12, 3–3receipt, 13–1recommended, 1–3Reference PIN, 8–4, 8–10, 14–6Registered Application Provider Identifier. See RIDrequired, 1–3RID, 3–2 to 3–3, 6–4, 6–8 to 6–9, 6–13, 8–5Rivest, Shamir, Adleman. See RSARSA, 6–3

SSAD. See Signed Static Application DataScript Processing. See Issuer-to-Card Script processingSDA, 2–2, 2–7, 2–9, 5–1, 6–1, 6–8 to 6–17

processing, 6–9processing flow, 6–10

SDA failed on last transaction, 11–3SDA Failure Indicator, 6–8, 6–16SDA key relationships, 6–5SDA or DDA, determining which to perform Offline Data Authentication, 6–7

SDA Tag List, 1–7 to 1–8secure messaging, 14–3 to 14–11SELECT command, 2–12, 3–3 to 3–5

Session Key Generation, 1–8SFI. See Short File IdentifierShort File Identifier, 3–2, 5–2 to 5–3signature and offline PIN, 8–1, 8–11signature, cardholder, 13–1Signature, cryptographic, 6–5signature, cryptographic, 6–4Signed Dynamic Application Data, 6–11Signed Static Application Data, 6–4, 6–8 to 6–9Standard DDA, 2–2, 2–7, 2–9, 6–13 to 6–14Standard Online Processing, 12–5Static Data Authentication Failure Indicator. See SDA Failure Indicator

Static Data Authentication. See SDAstolen cards, 8–1, 14–1Subsequent Related Processing

Card Action Analysis, 6–16, 8–14, 10–7, 14–11Completion, 6–17, 8–14, 11–7, 12–8, 14–11Issuer-to-Card Script Processing, 8–14, 12–8Online Processing, 6–16, 8–14Terminal Action Analysis, 6–16, 7–7, 8–14, 9–8

TTACs, 8–14, 10–1 to 10–7, 13–6tamper-evident device, 8–10Target Percentage to be used for Random Selection,9–3

TC, 6–14, 10–4 to 10–5, 11–2, 11–4, 11–7, 12–4 to 12–5, 12–8 to 13–1, 13–3, 13–5 to 13–9

Terminal Action Analysis, 2–4, 2–8, 2–10, 6–14,10–1 to 10–7


Terminal Action Codes. See TACsTerminal Capabilities, 7–3, 8–6Terminal Country Code, 4–3, 7–3terminal data

for Application Selection, 3–3for Cardholder Verification, 8–6for Completion, 13–4for Issuer-to-Card Script Processing, 14–5for Online Processing, 12–3for Processing Restrictions, 7–3for Terminal Action Analysis, 10–3for Terminal Risk Management, 9–3

Terminal Exception File, 9–4terminal floor limit, 9–3 to 9–4Terminal Floor Limit. See also floor limit checking

Draft 12/18/00

U Visa Integrated Circuit CardApplication Overview, Version 1.4.0


Terminal Risk Management, 2–3, 2–8, 2–10, 8–8, 9–1 to 9–8, 10–7

card data, 9–2processing flow, 9–6terminal data, 9–3

terminal velocity checking, 9–5, 14–7terminal velocity checking. See velocity checking, terminal

Terminal Verification Results. See TVRterminated transactions, 1–3Threshold Value for Biased Random Selection, 9–3Transaction Certificate. See TCTransaction Date, 7–3 to 7–5transaction flow, sample, 2–6Transaction Log, 9–3 to 9–4Transaction PIN, 8–6, 8–10Transaction Status Information (TSI), 9–3, 12–3, 12–6, 14–5

Transaction Type, 7–3TSI. See Transaction Status InformationTVR, 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

UUDKs, 12–2, 12–6UDKs. See Unique DEA KeysUnique Data Encipherment DEA Key. See ENC UDKUnique DEA Keys A and B. See UDKsUnique Message Authentication Code Key. See MAC UDK

Unpredictable Number, 6–11UPDATE RECORD command, 2–12, 14–7Upper Consecutive Offline Limit, 11–7Upper Consecutive Offline Limit “9F23”, 9–2, 9–5Upper Consecutive Offline Limit “9F59”, 14–7

Vvelocity checking, card, 11–1, 11–3, 11–7, 13–8velocity checking, terminal, 9–5VERIFY command, 2–12, 8–7, 8–10Visa CA Private Key. See Visa Private KeyVisa CA Public Key. See Visa Public KeyVisa documentation, 1–11Visa Integrated Circuit Card Specification, 1–1

impact summary, 1–7revisions, 1–6update, 1–2

Visa Low-value Payment, 1–7, 1–9, 2–12Visa Private Key, 6–3 to 6–4, 6–8Visa Public Key, 6–3, 6–8 to 6–9, 6–11, 6–13, 8–6VLP Funds Limit, 14–7

VLP Single Transaction Limit, 14–7

YY3 Authorization Response Code, 13–7

ZZ1 Authorization Response Code, 13–1, 13–6Z3 Authorization Response Code, 13–7

ICC EMV Administration

Documents

Transcript of ICC EMV Administration